# std/stl is the root to all evil

This topic is 4297 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Join the freedom fighter and crush the STL library. One step to unreadable compiler errors 1. use std/stl How to write unreadable code == stl headerfiles 1. Write the code using appropriate variable names 2. Use the replace tool, replace all normal variable names to leet variable names that are extremely hard to read and understand. 3. Use leet formatter to format the code into nonsense Why would one do this to me? em i alone out there or are there more who share this anger? I know what ur thinking, RTFM and learn to use stl properly

##### Share on other sites
At risk of sounding cliched, I will interject at this point: RTFM and learn to use STL properly.

Seriously.

It's definitely the single greatest timesaver in my programming, not having to invent a new container class or string everytime I need a feature, never have to worry about debugging it (that is a HUGE bonus, such a weight off your shoulders to be able to count on some code working properly all the time). I mean, for god's sake. You've done one container, you've done them all, and I for one never want to make another linked list except on pain of death [grin]

If you don't like their naming systems, well, that's your problem. All* template code produces very verbose and sometimes almost entirely unreadable errors, you either learn to recognize the problems, or not. I don't know about you, but I find the errors to be perfectly readable, although sometimes it takes a bit of time to get to the actual heart of the problem, which is of course not always the line or error reported. Same with debugging, when I break into STL code, it's fairly readable to me, as long as I glance at the surrounding code first.

*All syntacticly incorrect

But, to each his own. I'm sure you'll have plenty of fun hours, days, weeks even writing your own library for standardized containers and strings and everything else under the sun, not to mention debugging it, and THEN getting people to use it. Only to have it easily outperformed by the STL in all cases. Your choice.

##### Share on other sites
Hmm...

For what it's worth, I've been in your position. There was a time when I strongly resisted the STL - the syntax is pretty darned obtuse when you aren't pretty familiar with Templates, and the whole iterator concept. And STL can also generate some pretty nasty (a.k.a. near unreadable) error messages at times, so I understand your frustration.

However, I will also say this - I'm damned glad I got over my problems with the STL and learned to embrace it. The amount of time and frustration I've saved by using std::map and std::string is well worth the price of admission. (not to mention Vector and List, and the sorting algorithms, and everything else)

Anyhow, at least let me try to make a helpful suggestion. Take a look at _older_ books on C++. "C++ Strategies and Tactics" by Robert Murray for example, has a section where he designs a templated list class and uses the iterator metaphor. The book is from 1993, which if I'm correct is before the STL was a popular, standard part of the language. I was also able to find the book dirt cheap on the Amazon Marketplace (think I paid like \$8 for it). Looking through a book like this will provide some context as to why the containers are designed as they are.

Another helpful book might be Advanced C++ Programming styles and Idioms, by Coplien. He only dedicates like two pages to iterators in general, but the whole book is full of rational explainations for design patters which normally seem obtuse/overkill.

Oh yeah, and don't forget Scott Meyer's venerable "Effective STL". 8-)

Anyhow, good luck! Try not to give up, learning the STL is well worth the effort.

##### Share on other sites
Quote:
 Original post by LeadornJoin the freedom fighter and crush the STL library.

No.
Quote:
 One step to unreadable compiler errors1. use std/stl

There was a time when you couldn't understand C++. Was that because C++ is unreadable, or because you hadn't learnt to understand it? If you need stabalisers for your SC++L bike, try STLFilt. Newer compilers also tend to do better with template errors.
Quote:
 How to write unreadable code == stl headerfiles1. Write the code using appropriate variable names2. Use the replace tool, replace all normal variable names to leet variable names that are extremely hard to read and understand.3. Use leet formatter to format the code into nonsenseWhy would one do this to me? em i alone out there or are there more who share this anger?

How to write code that you can guarantee won't conflict with the users code == stl headerfiles. They use "leet variable names" because those variable names are reserved by the standard for use by standard library implementors. Imagine if you #defined the symbol DATA and your standard library implementation use the same symbol in a header. Could cause problems, no?

The formatting I have never had a problem with. It may be different to my standards, but it's usually consistent.
Quote:
 I know what ur thinking, RTFM and learn to use stl properly

Σnigma

##### Share on other sites
Quote:
 One step to unreadable compiler errors1. use std/stl

Wrong. That problem is not caused by the std library.

It is caused by two other things:
• Your compiler produces obscure error messages when you make a mistake whilst using templates - not just the std lib - anything that uses templates.
• You equate long compiler errors with unreadable compiler errors. They just tend to take a bit of getting used to.

Quote:

You aren't supposed to look at them - program to the interface, not the implementation.

##### Share on other sites
Quote:
 Original post by LeadornJoin the freedom fighter and crush the STL library.

I refuse. I join the empire. Crush the rebels!!! Their inexperience leads them to the evils of repeating. Repeating their own efforts, for their code is not reusable, repeating the efforts of others, for they reinvent the wheel a million fold, and repeating the mistakes of the past in their quest to make things themselves, instead of attempting to understand what their eventual destination will become anyways - if they continue to learn for a million years, at least.

Where you see unreadable error messages, I see an opportunity to learn, or failing that, cheating. Where you see unreadable header files, I see an opportunity to learn, at a bare minimum from the mistakes of others.

##### Share on other sites
Quote:
 Original post by LeadornJoin the freedom fighter and crush the STL library.

Create your own implementations of std::string (char arrays) and std::vector (dynamically resizable arrays) - and once you're done debugging them, tell me what you think of the standard library. Then procede to recreate anything else that might be useful (hint - take a look at the other containers, algorithms, and much more).

However, if you want to crush std::vector<bool>, you have my full support. [wink]

Quote:
 One step to unreadable compiler errors1. use std/stl
You've got a point there.

Quote:
 I know what ur thinking, RTFM and learn to use stl properly

# RTFM

##### Share on other sites
If you have a problem with the C++ standard library then you have a problem with C++ not with the library and the problem is

either

• or:

• You genuinely have a problem with C++ the language, it's not (generally) the library that is at fault. In which case find another language.

It's as simple as that.

##### Share on other sites
Quote:
 Original post by Will FHowever, if you want to crush std::vector, you have my full support. [wink]

Just crush the allowances in the standard for it to behave totally different from any other std::vector< T >.

##### Share on other sites
Okay, I just have to stick my neck out on this one... *prepares flame-retardant suit*

I _fully_ agree with the OP. STL is horrid, it's ugly... it's like a red-headed step-child. :)

I come from a background of around seven years developing games on consoles where code must be designed for performance and a small memory footprint. This is definitely something STL is not. Code must be kept simple, and reasonably easy to understand. I can't look at code that uses STL and figure out what someone is trying to do in just a few minutes because someone overloaded every single C++ operator to mean what he thought it should mean. Concatenate strings? That's what strcat is for! (although a good game engine would already have its own cut-down libc implementation anyway)

I look at some of the STL headers and my eyes just glaze over. When I look at a header file, I should see a cleanly laid out function list (or class of some sort) of what a module should do, not some madness that looks like a C++ run-on-sentence. Header files are the second-best documentation, after all.

I have no problems with understanding STL, though. I can read STL code if I have to, and I know how to use templates and operator overloading -- but I simply choose not to.

My opinion is that STL (and boost, and lots of other libraries out there) lead to overly-bloated code. Has anyone who ever _really_ uses STL ever looked at the disassembly of what goes on in there? Blame the CPU because it's too slow? No, no... programmers have gotten lazy and would rather leave the dirty work to someone else rather than build their own routines. Reinventing the wheel? Even so, someone who builds his own routines will _learn_ a lot while doing it. I'm all for it. And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.

*steps off soap box*

Let's try not get into too big of a flame war here, okay? :)

##### Share on other sites
Quote:
Original post by MaulingMonkey
Quote:
 Original post by Will FHowever, if you want to crush std::vector, you have my full support. [wink]

Just crush the allowances in the standard for it to behave totally different from any other std::vector< T >.

The standard comittee will do this for you :)

Quote:
 Discussed at Lillehammer. General agreement that we should deprecate vector and introduce this functionality under a different name, e.g. bit_vector

##### Share on other sites
Quote:
 Original post by bpointOkay, I just have to stick my neck out on this one... *prepares flame-retardant suit*

If you'll stick your neck out, I'll take a whack. I'll try and keep the flames low, so you end soft-boiled, not hard-boiled. :-)

Quote:
 I come from a background of around seven years developing games on consoles where code must be designed for performance and a small memory footprint. This is definitely something STL is not.

Is the overhead of std::vector really that onerous? I guess if you're developing VCS titles... :-)

Quote:
 Code must be kept simple, and reasonably easy to understand. I can't look at code that uses STL and figure out what someone is trying to do in just a few minutes because someone overloaded every single C++ operator to mean what he thought it should mean.

What operator overloading in STL? Overloading the brackets "[]" for array access is confusing to you in a map? Last I looked, none of the containers overloaded any of the arithmetic operators. If you're referring to the operator overloading in iostreams, I'd point at that, although part of the standard library, they are not a part of STL.

Quote:
 Concatenate strings? That's what strcat is for! (although a good game engine would already have its own cut-down libc implementation anyway)

You rewrite strcat? I wish I had such generous milestone schedules! :-)

Quote:
 I look at some of the STL headers and my eyes just glaze over. When I look at a header file, I should see a cleanly laid out function list (or class of some sort) of what a module should do, not some madness that looks like a C++ run-on-sentence. Header files are the second-best documentation, after all.

Here's some source from an STL implementations shipped with a popular compiler:

		// TEMPLATE FUNCTION for_eachtemplate<class _InIt,	class _Fn1> inline	_Fn1 for_each(_InIt _First, _InIt _Last, _Fn1 _Func)	{	// perform function for each element	_DEBUG_RANGE(_First, _Last);	_DEBUG_POINTER(_Func);	_CHECKED_BASE_TYPE(_InIt) _ChkFirst(_CHECKED_BASE(_First));	_CHECKED_BASE_TYPE(_InIt) _ChkLast(_CHECKED_BASE(_Last));	for (; _ChkFirst != _ChkLast; ++_ChkFirst)		_Func(*_ChkFirst);	return (_Func);	}

Before you complain that I've committed copyright infringement, its fair use to copy small portions of copyrighted material when its used for educational or critical purposes.

Is it really that confusing to you? I guess its a lot of lines for a for loop. Must of the lines are obviously for debugging. I'm all for debugging to help me find errors. Maybe I'm just strange that way. :-)

[quote]
My opinion is that STL (and boost, and lots of other libraries out there) lead to overly-bloated code. Has anyone who ever _really_ uses STL ever looked at the disassembly of what goes on in there? Blame the CPU because it's too slow? No, no... programmers have gotten lazy and would rather leave the dirty work to someone else rather than build their own routines. Reinventing the wheel? Even so, someone who builds his own routines will _learn_ a lot while doing it. I'm all for it.

Why should I look at every assembly language instruction in my program? I haven't done that since I used to write every line of code in assembly. Even then, I haven't known every single instruction run since I've had to deal with OS calls since the 16-bit days.

Do you not make operating system calls in order to know exactly what's going on? Do you write your own file I/O routines that directly tap hardware?

Although I'm not a firm believer in the "we can do it slow for now and optimize it at the end", STL fits that paradigm. I don't know anybody who has used it complain that it ended up being something they needed to optimize out. Even if it ends up being something you do need to speed up, with its well-developed concepts, you can always write your own specialized container if it becomes necessary. As long as you model the concepts, it's an easy drop-in.

Quote:
 And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.

That's a categorically false assertion. If the author(s) of the code know more about the topic than I do, they'll almost certainly write better code. If I write a sorting routine based on a bubble sort, I've almost certainly erred in not using the quicksort available in the STL. When I look at what Stepanov has designed, I'm quite impressed. I'm willing to bet its more reusable than what you've written. I'm not trying to insult you. It's more reusable than anything I've written. I'm sure there's plenty of STL users who agree with that position.

##### Share on other sites
I know I should resist, but I have no willpower.

This post is not intended to be a personal flame against you, but rather a argument for the fact that your current opinion of the STL and code reuse in general is based on knowledge that may have been valid seven years ago, but certainly is not now.

Quote:
 I come from a background of around seven years developing games on consoles where code must be designed for performance and a small memory footprint. This is definitely something STL is not. Code must be kept simple, and reasonably easy to understand.

The STL is quite efficient in the general case, and provides a means (such as custom allocators) for you to tailor its behavior to your needs. One of the benefits of the STL is that it is standard, and thus commonly understood (except by naysayerswho refuse to learn it or embrace it based on "facts" that are out of date). Not having to re-learn the ins and outs of somebody's custom container library for every new project drastically increases ones productivity.

If, in a specific situation, you've determined that a given (properly used) STL container is the bottleneck in a (properly designed) algorithim, and you've exhausted all the possible steps for customizing the behavior the STL in that case, then you have suitable grounds for considering a custom implementation. Until then, you are probably just making more work for yourself and for new programmers who need to learn your codebase.

Quote:
 I can't look at code that uses STL and figure out what someone is trying to do in just a few minutes because someone overloaded every single C++ operator to mean what he thought it should mean. Concatenate strings? That's what strcat is for!

Are you sure you are reading STL code and not boost::spirit code? The STL doesn't really have any over-the-top overloads of any operators (other than maybe the bitshift operator overloads for streams). This statement just reveals your limited C and/or C++ centered thinking: most other languages provide an overload of operator+ for string concatenation natively. I don't see this as a particularly counter-intuitive use of operator+, either.

The STL is not particularly complicated, and it's well documented. If you can't understand what somebody's intent is in a given piece of STL-heavy code, that probably just means you don't have enough exposure or experience to those aspects of the STL.

And please don't tell me you are advocating the use of C-style strings and strcat and its kin in favor of std::string (when writing C++ code). That's just masochistic and smacks of "not-built-here" syndrome.

Quote:
 My opinion is that STL (and boost, and lots of other libraries out there) lead to overly-bloated code. Has anyone who ever _really_ uses STL ever looked at the disassembly of what goes on in there?

Many people have, including myself, and I was not shocked by anything I found. Modern compilers are very good at avoiding code bloat due to template usage.

Quote:
 No, no... programmers have gotten lazy and would rather leave the dirty work to someone else rather than build their own routines. Reinventing the wheel? Even so, someone who builds his own routines will _learn_ a lot while doing it. I'm all for it. And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.

This is just crazy. Re-inventing the wheel for non-educational purposes is a waste of time and money. Re-inventing the wheel in production code is just asking for more bug reports and less happy users. Assuming that something you have written is better only because you wrote it is naive and arrogant.

These are exactly the ideological beliefs that plague the game development industry - "not built here," "performance above all else," and in general being locked into a single worldview and refusing to accept change (N) until the rest of the world has already accepted change (N + 2).

Learn to love the STL. Hell, learn to love a language other than C++, too - maybe even a crazy non-imperative one! You will be amazed at the time and effort you save.

##### Share on other sites
Quote:
 Original post by bpointOkay, I just have to stick my neck out on this one... *prepares flame-retardant suit*I _fully_ agree with the OP. STL is horrid, it's ugly... it's like a red-headed step-child. :)

It has it's problems. Think you can do better?

Quote:
 I come from a background of around seven years developing games on consoles where code must be designed for performance and a small memory footprint. This is definitely something STL is not.

You're right. Instead, the STL is flexible - so you can pass in a custom allocator for a small memory footprint, or make a tradeoff there for allocation performance speed. You get to decide instead of being forced into a single implementation scheme - I fail to see how that's a bad thing.

Quote:
 Code must be kept simple, and reasonably easy to understand. I can't look at code that uses STL and figure out what someone is trying to do in just a few minutes because someone overloaded every single C++ operator to mean what he thought it should mean. Concatenate strings? That's what strcat is for!

Yeah - because we should really be using a function that deals with arbitrary buffers of totally unknown size that will end up overwriting random bits of memory should our buffer be to slow. You want verbose? Use std::string::append. You're not forced to use the operators. Of course, the fact that most people tend to choose to use the operators tends to hint that they are in fact rather easy to recall, and fairly intuitive.

Quote:
 I look at some of the STL headers and my eyes just glaze over. When I look at a header file, I should see a cleanly laid out function list (or class of some sort) of what a module should do, not some madness that looks like a C++ run-on-sentence. Header files are the second-best documentation, after all.

So now we're attacking the STL implementors intead of the STL itself. I'll admit they don't write the cleanest of code. But you know what? Headers are only the second-best. I'd suggest you'd use the first-best - in this case, Traditional Documentation.

Quote:
 My opinion is that STL (and boost, and lots of other libraries out there) lead to overly-bloated code. Has anyone who ever _really_ uses STL ever looked at the disassembly of what goes on in there?

Yes.

Quote:
 Blame the CPU because it's too slow?

No, because usually if the compiler isn't ancient, it's not.

Quote:
 No, no... programmers have gotten lazy and would rather leave the dirty work to someone else rather than build their own routines.

Yeah. You're right here - I'd rather let the writers of the bloody compiler, who know what optimizations their specific compiler does and does not do, and which hand-coded ones it can take advantage of, write code specifically tailored to get the best performance in that environment, than attempt to do this myself for N different platforms at the same time.

Quote:
 Reinventing the wheel? Even so, someone who builds his own routines will _learn_ a lot while doing it.

Eventually. But it will hardly be the most efficient way.

Quote:
 I'm all for it. And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.

Entirely disagree, unless you plan on coding in a cave all by your lonesome until the end of your days. The moment you step outside the sheltered life of code focused for nobody but you, suddenly, other people will need to interact with your code. Would you rather interact with it using the STL, or would you rather be forced to learn yet another person's container set which is completely incompatible with the containers used in this other module you wanted to use to do most of your work? Suddenly, your quest to reinvent the wheel leaves you with a triangle, a hexagon, and a tank tread. Now build me a racecar with them. The deadline is tomorrow.

At least if you had two tank treads, you'd have a base with which you could test out the engine. As is, you'll be forced to start making new wheels, just to test out the rest. This is most likely a waste of effort if you don't know what kind of terrain this race is going to be over...

##### Share on other sites
I have a few things to say about it.
First of all, if you don't like the syntax, then write a wrapper class.
You should write a wrapper class anyway, because if you want to change the implemntation of your data objects, you could do it more easly this way.
However, I myself dont use std much. I don't see what is the problem to write a linked list?
You can make all kind of special variations to the list which std won't give you.
Plus, you write it once and you can use it for all the following projects.
I assume that if I will need to use something more complex like a binary tree with flips, I don't remember whats the name. Then I would probabbly write a wrapper calss and in the implementation I will use something like std.
The only thing I used from std was string I believe, and maybe also stringstream and such.

##### Share on other sites
Quote:
 I don't see what is the problem to write a linked list?

Because yours will probably be less efficient, more buggy, and require other people who interact with your code to learn the ins and outs of your implementation, which is probably not as well documentated as std::list.

Quote:
 You can make all kind of special variations to the list which std won't give you.

Such as?

##### Share on other sites
Quote:
 I come from a background of around seven years developing games on consoles where code must be designed for performance and a small memory footprint. This is definitely something STL is not.

Well, that's one way of looking at it. Another way of looking at it is that STL code is either performant, or small in memory, or in some cases both. I have only ever seen a few people actually profiled their hand-rolled code against the STL, and I've never seen any significant performance boost. On the other hand I have seen many bugs and errors, which you just don't get in the STL.

We're quite happy to use STL in our console games and it does the job just nicely, thanks.

Quote:
 Code must be kept simple, and reasonably easy to understand.

Anyone with sufficient experience in C++ can look at STL code and know exactly what it does, because it's used everywhere. Your hand-rolled code that your company uses? Yeah, YOU know it, but when you hire someone new and they write something like linkedListAdd and you have to explain that no, they really needed to use linkedListAddToEnd, and there's casts of void*'s everywhere... is that really easier to understand?

Quote:
 Concatenate strings? That's what strcat is for!

I really hope you're not using strcat for something as important as a console game, which is emphatically not allowed to crash! strncat maybe, strcat_s quite possibly, but please god not strcat in anything critical! I put it to you, it is both faster and more secure to write this:

DoSomethingToFile( folder + "\\" + filename );    // using a string

...than it is to write this...

char path[MAX_PATH];strncpy( path, folder, MAX_PATH - 1 );strncat( path, "\\", MAX_PATH - 1 );strncat( path, filename, MAX_PATH - 1 );DoSomethingToFile( path );    // using a char*

...particularly remembering all the -1's which I nearly did myself before subnmitting.

(Alright, it's still not 100% secure as written. If folder or filename are sufficiently large, the string might fail to resize, and the program will crash - and I'm not checking for exceptions (apart from anything else the overhead of exceptions precludes their use in most games). However, this is substantially LESS likely than a buffer overflow of a mere 260 characters. Furthermore, if the worst comes to the worst, I will know if the string memory allocation fails because it will crash instantly, which hopefully will happen during QA rather than after release (checking player input for validity is therefore still necessary, of course). If str(n)cat writes off the end of a buffer, there are no clues, just strange behaviour and possibly crashes in a completely unrelated part of the program. Good luck hunting THAT down during crunch - yeah, I've been there, and didn't enjoy it.)

##### Share on other sites
STL, oh my STL..
Someone said that we should rewrite STL in our projects.
I tend to reinvent the wheel to learn.
I always do that.
But I never did use a list except std::list.. It is not ever that I actually create a linked list to actually use it, but to learn.

In short, if you want to learn, reinvent then put into garbage. Use what the professionals have already created.

##### Share on other sites
Wow, this is getting into another round of pointless C++ vs. C flameage.

Maybe we can take a step back and look at it like this. I understand bpoint as saying STL is not good in all cases (viz. time-critical code); everyone is jumping on him as if he'd said "it should never be used and ideally banned from existence". Is the former interpretation so hard to accept?

Quote:
 And please don't tell me you are advocating the use of C-style strings and strcat and its kin in favor of std::string (when writing C++ code). That's just masochistic and smacks of "not-built-here" syndrome.

There can be very valid reasons to do. When working under constraint that NO locks must be taken, std::string won't cut it. Yes, could use allocator that basically doles out a PATH_MAX-char buffer, but IMO strcpy_s is simpler in this case.

Quote:
Quote:
 Blame the CPU because it's too slow?

No, because usually if the compiler isn't ancient, it's not.

Then the challenge in your field of work is obviously not optimization. Which is fine, but not to say there is no need to do so.

Quote:
Quote:
 You can make all kind of special variations to the list which std won't give you.

Such as?

Such as reducing memory overhead from (4+4)*num_objects to log2(max_objects)*num_objects. In certain applications, a doubly-linked list can be had with one pointer (by storing prev XOR next); the pointer can be reduced to a few bits if allocator guarantees all nodes are consecutive.

##### Share on other sites
Yes, errors spawned by C++ templates [and by extension the Standard Library] are lengthy, and fairly unaesthetic. That's the price you pay for their use, and interpretting them does get easier.

If you're not making use of C++ templates, I would question your choice of development languages. Template goodness is one of the few advantages C++ still holds over newer rivals.

##### Share on other sites
I think we have the classic case of a kid who can program hello world by himself or cut and paste NEHE code and now he thinks he is the shit.

##### Share on other sites
Quote:
 Such as reducing memory overhead from (4+4)*num_objects to log2(max_objects)*num_objects. In certain applications, a doubly-linked list can be had with one pointer (by storing prev XOR next); the pointer can be reduced to a few bits if allocator guarantees all nodes are consecutive.

Both this, and your rebuttal to my comment about std::string and strcat(), are valid situations where the STL's customization capabilities probably don't fit that specific situation ideally. My "such as" comment wasn't intended as "there is no such case" but rather to illicit a reply from C_Modest_God as to what situations he thought he needed that the STL couldn't provide (he may have had a specific one in mind that the STL could actually do; perhaps he just doesn't know about it?)

Quote:
 I understand bpoint as saying STL is not good in all cases (viz. time-critical code); everyone is jumping on him as if he'd said "it should never be used and ideally banned from existence". Is the former interpretation so hard to accept?

The former interpretation isn't hard to accept at all, but everything I got (and the others that replied, it would seem) from bpoint's post indicated to me that he was advocating that it should never be used.

##### Share on other sites
Quote:
 Original post by Anonymous PosterI think we have the classic case of a kid who can program hello world by himself or cut and paste NEHE code and now he thinks he is the shit.

or a crusty old C programmer that won't accept change. If you want to keep using C go ahead, it is better for some things like old consoles and robotics. However there's no excuse for still using strcat on any modern hardware. Either continue using C or switch to C++, but please don't use some horride mix of both combined.

##### Share on other sites
I just wanted to add one quick thing about the use of exceptions. (it was mentioned above somewhere) as being slow. There is hardly any overhead when using exceptions if the exception was not actually thrown. An basically, if you code thrown an exception something is going on that shouldn't be in which case an extra few milliseconds isn't going to kill you.

Obviously, this does imply that the author of the exception based code needs to understand exceptions and not use them in silly places which could easily result in slow code.

Moral of the story: Exceptions are a great help and something that your c++ programming is going to stereotype into something that slows down the app. That, however, would be an ignorant statement to make.

None of my comments are intended to me personal attacks, just wanted to expose that exceptions are good, use them!

##### Share on other sites
Quote:
 Original post by Jan WassenbergWow, this is getting into another round of pointless C++ vs. C flameage.Maybe we can take a step back and look at it like this. I understand bpoint as saying STL is not good in all cases (viz. time-critical code); everyone is jumping on him as if he'd said "it should never be used and ideally banned from existence". Is the former interpretation so hard to accept?

Actually, yes, it is.

Quote:
 Original post by bpointI _fully_ agree with the OP. STL is horrid, it's ugly... it's like a red-headed step-child. :)

He goes on in such a fashion never once stating any sort of qualifing remark about the STL having a place - only on and on about the shortcommings it has, and how unsafe C solutions are apparently superior - again, with no qualifing remarks about when or where, nevermind why or with what drawbacks.

Yes down-to-the-metal has it's places, No "places" is not a synonym for "everywhere". Considering his use of broad language:

Quote:
 And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.

I cannot interpret his ramblings as anything less than blatently misleading. He does not say "better than the STL in the innermost loop of your render function". He does not say "better than the STL when you're shuffling elements around alot". He says plain, flat out better.

##### Share on other sites

This topic is 4297 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.