Downsides to the C++ STL?

craybob queries: "I'm a developer for a small software group that will soon migrate from using Rouge Wave to using the C++ STL. I just left the week-long Software Developers 2002 conference, where I heard the great minds in software tell us all of the best ways to take full advantage of the STL. (I just wanted to give a quick thanks to Stephen Dewhurst and Scott Meyers) From this I came away with the feeling that this is the Holy Grail of C++. I'm sure these guys are right and that it is great, but the truth is that I'm a skeptic, so what are the downsides to the STL?"

Comments

STL downsides

[Hawke]

The header files you want to read to find out the API's are practically illegable. You'll probally want to get a book or other such better documentation.

Depending on your compilier, you might end up with excessive binary-code bloat, as three different copies of "list" are created for list<foo*> , list<bar*>, and list<fred*> instead of using a single specilization for all three.

I don't know how well the inheritance issues are nailed down, but I've never been tempted to make a class inherit from a container, I just have classes have containers.

That said, I like STL and highly suggest using it. Never write a linked-list again.

Re:STL downsides

[ComputerSlicer23]

Yes it is, in fact it is a commonly known optimization to override an allocator. Lots of written material mentions it if you take the time to readup on it. Write a custom allocator, you know the third option to all of the STL containers? Bjarne in fact says that is the whole reason why it was added was specifically so people could get very fine control over memory allocation. Nearly everything about the STL and all of the templated types in C++ is to give you completely control over the performance/size parameters of the code. Bjarne knew nobody would use it otherwise.

They got control to control both placement and the memory allocation routines. The default allocation calls malloc, writing your own can commonly speed up code an order of magnitude.

That was in Design and Evolution of C++, if you want to know how to write an allocation check out boost.org, and Jossutis's book. Several people linked to the book above.

<flame> Remember: Just because you didn't know how to do it doesn't make it impossible. </flame>

Sorry about the flame, but people who don't know enough about C++ and then say it is fundamentally flawed in ways that it was specifically designed to accomadate aggrevate me very much. It isn't you're particular situation (heck you might have done this before allocators got standardized). Just so many people are ignorant of the facts and then blame C++ because it does the right thing 95% of the time and gives them control of the other 5% to override it.

And yes I own a copy of the ISO C++ standard. I am that much of a C++ geek.

Re:Lots of overhead.

[Hawke]

there is a lot of overhead with using the STL. Virtual function and things of that like can make your code bigger and slower.

STL doesn't normally use virtual functions, unless some of the comparison functions or functor objects do. The main cause of bloat (in my experience) is the lack of provided specializations, and the huge symbol names generated by name mangling.

(Fer fun, create a map< foo, map<bar, map<fred, qux> > >, and run "nm" on the generated .o file. I had a problem with blowing up the size limits on the default Solaris linker with stunts like that)

Not many drawbacks

[emarkp]

I've been happily using STL for about 3 years now. The biggest drawbacks (IMO) are:

• Kitchen sink syndrome: There are a lot of features in STL, and to use some of them you need functors, etc. Sometimes it's just easier to read if you use a normal for loop instead of using for_each, etc.
• verbose type syntax: When you use the containers, like (say) std::vector, you have to declare your iterators as:

  std::vector<int>::iterator i;

  If you change to a std::list container, you'll have to change your declarations. Of course, you can mitigate that by using typedefs, and then you only have to change the typedef, but it can still get a bit wordy.
• unexpected results: Understand the difference between remove() and erase() in the containers.

The benefits of using STL are wonderful. If you write your custom containers/streams/etc. using the STL interface, you can seamlessly use the algorithms portion of the library.

I recommend reading the first part of Generic Programming and the STL. It'll help you undestand the thinking behind the design.

Re:Not many drawbacks

[tardibear]

higher C++ gurus told me that using all of the std namespace would bloat my code unnecessarily

Get new gurus. Putting using namespace std; into your program (especially in a header file) is regarded by some as poor style but it certainly won't "bloat your code".

Re:Lots of overhead.

[nonya]

Standard Tamplate Library. It is a standard C++ library that provides containers and generic algorithms. The power of the STL comes from abstracting the concept of a sequence - the algorithms work on linked lists, c arrays, vectors - anything that provides iterators. For example, the following function will return the sum of all the elements in a sequence (off the top of my head, did really compile this):

template
double sumOf(TIter start,TIter end){
double result=0.0;
for(TIter curElement=start;
curElement!=end;
++curElement){
result+=*curElement;
}
return result;
};

too much time

[0WaitState]

The biggest drawback of STL is finding something to do with all the extra time you'll have. Just think--you won't spend days debugging somebody's insanely API'ed String implementation he developed when wired to the gills on Jolt.

You won't spend discouraged hours in meetings while ego-driven idiots argue over whose pet collection class hierarchy better suits the hypothetical abstractions of the project. You won't waste precious energy trying to reverse-engineer someone else's pattern building-blocks because now you immediately recognize STL method signatures.

STL reduces job security for programmers who rely on obscure implementation. Some may see that as a drawback. IMHO, good code is maintainable code, and STL usage in any project is a quantum jump towards maintainability. Remember, the "maintainer" will probably be yourself revisiting the code six weeks after that all-nighter.

We recently changed from RW to STL

[AndSoitGoes]

I manage a team that changed over our code base from RW to STL. The main driving force was that STL would be supported going forward were as we were using an unsupport version of RW on an unsupport platform.

The change over did induce some bugs as expected.

Code bloat, unreadable errors and other template issues are the same for STL as they are for RW so you shouldn't see any downside for items that are caused by templates.

In general RW had a fuller API set so you might find things that were easy in RW aren't quite so easy in STL. We generally wrote a wrapper function that added the RW functionality we lost then unit tested the wrapper fairly throughly.

One thing to watch out for in RW the sentinal position is at the begining of the collection and in STL it is at the end.

You do have to choose which STL to use. We are using the SGI version but will switch to the SCO/unixware native verion soon.

Get a good book I recommend "STL from the ground up" by schiltz.

mostly downsides

[j09824]

I think the STL has mostly downsides:

• The STL makes no guarantees that it checks for errors (bounds checking, using a pointer into the wrong collection, etc.), and it is designed in such a way that error checking is quite costly. (Note that there have been a couple of attempts at making a safe STL; see here; it is unacceptable that this isn't part of the standard and isn't used by default).
• It's hard to predict whether any particular data structure or algorithm is going to be fast. Sure, it makes asymptotic guarantees, but everybody does that; it's the constants that matter.
• The library is too complex for most needs, and you can't easily just use "a little bit" of it. If you want to write efficient code using STL, you have to understand it pretty well.
• STL's complex semantics also make thread safety hard to guarantee.

The STL wasn't adopted because the committee liked it tremendously, it was adopted by default: it was the only serious proposal for collection classes for C++ that the committee had, and C++ needed collection classes in order to pass as a standard. I think what C++ should have gotten was a simple template array class, list class, and hash table class, with excellent error checking. IMO, STL has greatly damaged the C++ language.

How can you live with the C++ STL? Your best bet is to pick a small, simple subset of concrete STL datatypes and operations (vector, stack, and map) and stick to those in your interfaces and most of your code. You can implement your own, safe and efficient versions of those for development and internal use and use the standard STL versions when you ship library code. Forget about iterators: they are a mess to debug. And use the STL algorithms only if you don't care about performance.

Note that I have nothing against generic programming: generic programming is an old and well-established idea (and predates Stepanov and Lee by many years). C++ is just not a good language to push it to the extremes that STL pushes it.

Re:STL Downsides?

[lkaos]

1. It uses templates. I know the name implies this but I can't stand the way C++ implements templates. Templates are created at compile-time which removes any advantages of generics in the first place.

As compared to what language??? C++ templates are one of the best features of the language. Yes, they are a different concept, but embrace it, change is good.

I have no idea what you are talking about regarding templates being created at compile-time as being a bad thing. That's what generic programming is all about!!! Its the compiler generating classes so that you don't have to. It has to be done at compile time. I'd love to hear an example of a language that implements some kind of generic stuff at runtime.

2. While it may reduce developer time, it doesn't reduce code bloat. Templates are huge wasters of memory. This is because C++ creates a brand new class for *each* type of the template you use. So if memory consumption is an issue for you (like it is with me) then stay away.

Having additional classes only uses more memory at compile time. It makes absolutely no difference at runtime. The executable size increases only because of debug information. Stripping out the debug info will dramatically reduce executable size.

3. Template are *not* portable. Each compilier has varying support for templates. Yes the *new* compiliers support *most* of the STL but if a developer wants to get to those older models on the shelves... stay away.

ANSI C is *not* portable either for the most part. Remember, C++ is a young language with a young standard. Of course its not as portable as C, but its still more portable than any other solution (MFC, RougeWave, etc).

4. Using templates is verbose especially when you decide to throw inheritence in there. Template may look cool but they can get complicated really quickly (i.e. using the STL map template while inheriting from it)

YOU SHOULD NEVER INHERENT FROM AN STL CONTAINER. Period. There is no good reason to do this. If your design calls for it, then you have a bad design. Besides, STL containers do not have to have virtual destructors so you are introducing potential memory leaks if you inherent from them (this was made part of the standard on purpose).

5. Fragile Base Class. This is a C++ problem but it very much applies to the STL. If you build anything upon the STL and they add a virtual function... good-bye binary compatibility.

The STL does not have virtual functions. Nothing to worry about there. Remember, STL is standardized so there is no need to worry about stuff like that.

I fight extremely hard to not use the STL as there are other well-tested non-templated implementations of what the STL has.

For instance??? You are doing yourself an extreme disservice by avoiding STL.

Re:Lots of overhead.

[jason_watkins]

Ok, glad you acknowledge that STL has nothing to do with virtuals.

So yes, let's say you have a templated class and instantiate it for 15 different type specalizations. What's the memory overhead of this? Not much.

On top of that, if you really do have 15 differen things, how are you going to shave off that overhead using a different mechanism? Will you create 15 seperate classes intead? That's even MORE overhead than the templating. Will you create one class with a type = field? Use comparision in all functions that relate to the class with seperate paths where needed for each of the 15 different cases?

I hope you're starting to see that if you *really* have 15 seperate things, you pay that overhead no matter if you're dealing with ansi c using templates.

These are criticisms that are parroted over and over without much understanding of what's going on. Please don't perpetuate ignorance. Go test it yourself, see the results.

Experience with STL on multiplatform

[Tiger]

Unless there was a specific requirement and good reason for it, I wouldn't write C++ without STL nowadays. We've been using it for the last 2+ years on about 6 different unix platforms (mostly gcc2.95 over that time) and NT (using VC6.)

In that time we' ve seen a lot of improvement as native compilers for HP, and possibly IBM are catching up and threaten to replace gcc for builds on those systems.

VC6 is a real catch.. their STL implementation is only borderline usable. The solution to this was to introduce stlport into the mix, at least for our win32 builds.

Some issues we've had:
- verbose syntax (once your finger macros catch up, it's okay)
- EXTREMELY verbose compile error statements - especially when using a sufficiently complex STL object (vector of strings, or something) and doing something like attempting to use a const iter in a non-const way produces monstrosities like:

passing `const string' as `this' argument of `class basic_string,__default_alloc_template > & basic_string,__default_alloc_template >::operator =(const basic_string,__default_alloc_template > &)' discards qualifiers

(and that's a simple one.)

- Bugs on various platforms, including the lovely uselessness of VC6 STL
- Difficulty of examining data in debuggers - ddd+gdb gets a right ugly mess
- Memory High-water-marks: Some things don't really free the memory you want them to free, just hold onto it for next time. We've discovered this when we create stupidly-large temporary maps, and then delete them.
- Various little gotchas like the dangers of using remove() algorithms, being aware what map's operator[] does, etc.
- Inconsistencies between std::string and the rest of the STL

But to try and be less negative:
- STL has made handling data within a C++ program much more pleasant. For us, STL is fast and efficient, and has probably saved us many programmer-months in the debugging and development time required to use traditional C/C++ data structures. Plus, once you get into the mindset used by STL, it gets more and more powerful every time you read another part of the documentation.

STL strengths and weaknesses

[eddeye]

Two words: Effective STL (ISBN 0-201-74962-9)

This book does an excellent job of covering the strengths, weaknesses, and pitfalls of using the STL.

Among the STL's (and C++ standard library's) deficiencies are lack of generalized functors, hash containers, smart pointers (the only type included, auto_ptr, is not very useful), and thread libraries. All these and more are addressed by third-party libraries such as Boost (boost.org) and Loki.

All these features are under consideration for inclusion in the next C++ Standard (C++ 0x) being worked on now. The Boost libraries in particular are strong candidates for inclusion in the next Standard; if not, something very close to them should be in there.

Re:Not all compilers support it, god-awful comp er

[PuntaConejo]

>The fact that no compilers support all of STL is admitted by Stroustrop (sp?).

Hmm. Perhaps you are refering to his remark
that no C++ compiler supports the export keyword?
This keyword is not necessary to use the STL,
and at least one commerical compiler now implements it.

Or perhaps you are refering to his remark that not all compilers support member templates and partial specialization. Perhaps true at the time he wrote the book, but no longer true. GCC and many others do support them. MSVC 6.0 does not.

it's butt ugly and impossible to maintain

[small_dick]

the syntax and readability are so horrible that it took several computer scientists years to decide exactly how butt ugly and unreadable to make it.

STL is not, in any way, shape, or form, a step forward for programmers.

people can write stuff with it that is totally incomprehensible to anyone who is not party to their school of programming style -- but this is true of C and C++ in general.

I don't know what the solution to programming's difficult problems with reliability, reusability and maintainability, but I think Java has done a lot more to improve the state of the art in programming models, especially WRT these problems, than the STL.

Re:Well..

[DCram]

Laugh..every reply is a good one. And one that I know already. I said it was sumthing stupid that I do not that I didnt know it was stupid :)

actually I dont create the NULLSTR = ""; very often. Here at work one of the "managers" thought it read better so we use it. Code review goes easier when you dont have to fight the same pitched battle every time.

The STL, by a longtime user

[Animats]

The STL is a reasonably good collection library. I wasn't initially too happy with the iterator paradigm. The idea of generalizing pointer arithmetic, the most error-prone feature of C, seemed a terrible idea. But it's worked out moderately well, and STLport can be compiled with iterator checking, which is very useful.

In practice, the big problem with the STL is that Microsoft doesn't like it. It's one of those standards that Microsoft doesn't control, yet is so widely used that they can't ignore it. So they support it, but badly. (OpenGL gets similar treatment. So does C++ itself. Microsoft prefers their own dialect of C++, which is not fully compatible with the ISO standard.)

The STL doesn't help too much with the big problem of C and C++ programming: keeping track of who owns what. auto_ptr and the STL don't play well together. That's a lack, and it's not easily fixed. There have been three iterations of auto_ptr semantics, all of which have some painful problem. See "comp.std.c++" for discussions on this subject.

Downsides

[Ken Treis]

Others have already pitched the positives, so here are a few of the negatives. There are a couple of things that I see as real problems with the STL. Having just gone through a small-scale STL development project, I've come away with a really bad taste in my mouth. Here's why.

With the STL, C++ has finally aquired a part of what Smalltalk and Java have always had: a library of base classes. With these sorts of capabilities, you tend to start thinking about your system in more object-oriented terms. This is a good thing in itself, but C++ just doesn't go there with the ease that other languages do.

For example, the OO notion of polymorphism goes completely against C++'s strong typing (and C++ is even more finicky in its type checking than C is). In a true OO system, I don't care what kind of object I have in my hands, I just care that it does a certain thing. This is where late-bound OO languages like Smalltalk and Objective C shine.

Also, as your project progresses and you factor your code into neat little objects, file-based source code navigation becomes a real bear. IDEs like Source Navigator can help with this, but you still have to do double-entry bookkeeping for your prototypes and function declarations.

Why didn't we see these problems before the STL? Because we never tried to use C++ as much more than a superset of C. With the STL, we had the opportunity to build things that were more like our other OO systems, so we did. And that's where we started to get bogged down.

One other thing: We had more discussions about coding style in a few weeks of STL coding than we ever had in our non-STL C++ coding. Perhaps that was because more of us were involved in the project. But I think that, at the heart of it, the STL gives some people a feeling that C++ code can has a chance of being "elegant", and there is a real tendency to push yourself to try to achieve it. Without the STL, we all just knew that C++ was bubble gum and bailing wire. It happened to get the job done for us, and we didn't bicker about style.

Perhaps your situation is different, but if I had to make the call, I'd say your time might be better spent learning something else.

Re:Partial List

[Viking Coder]

My assertion is that people change their mind. If you have an API that you can live with, you can always change your mind as to how the back-end works, and all you have to change (hopefully!) is the class that you're working on. Encapsulation is your friend.

Also, I hate that people will free-form type functors, in the middle of their code. People end up with multiple functors that all do the same thing. The "method" paradigm is far better, that the algorithm and data are coupled. It makes it far easier to organize your code, far easier to make global changes and manage your code, and reduce bugs!

If you didn't wrap the str* functions in a class, then it cost you a lot of effort to switch your code to std::string. If you DID wrap the str* functions in a class, it was probably pretty painless. (Other than something like sprintf - a major pain in the butt to get working in STL, in my opinion.) I don't think it's responsible to think that you'll ALWAYS code in STL, from now until the end of time. Didn't you think that, at one point, about the str* functions?

Another thing I dislike - many, many languages support OO methodoligy, which makes porting code from one language to another pretty easy. Templates are not easy to port to another language. And they really don't buy you that much, in your end-user code. They're great for quickly developing something, and potentially making it more portable, but if you encapsulate all of the functions (ie METHODS), you can always change your mind, and your client code becomes more portable, too. (As in, porting to another language, if you need to.)

It's always easier to make a change in one place than in a thousand places. Encapsulation makes that possible - but unfortunately the only way to encapsulate something is to wrap it in another API.

I'm not proposing to wrap it because your developers don't like it. Of course they should know it, and they should like the good parts, too. But having everyone re-invent the way to do case-insensitive comparisons is insane. Those kinds of decisions should be encapsulated in one location. If you know a better way than writing an API wrapper, I'd love to hear about it.

And I'm not saying you should make myVector<myString>, I'm talking more about things like myStringVector. Application data should not DEPEND on the STL for its interface. Just because the STL is a useful API, don't think it's the Holy Grail. Too many people just LOVE to code Is-A relationships, when a Has-A relationship is better in every measurable sense.

That's my argument. I could be wrong. =)

In my experience...

[Anonymous Coward]

When things are working as designed, the STL can save you a LOT of headaches. But when something goes haywire, are you going to be able to debug the problem in the function named:
___erase__t7rb_tree5Zt4pair2Z6stringZ6stri ngZt4pai r2ZCt4pair2Z6stringZ6stringZ7mapelemZt9select1st1Z t4pair2ZCt4pair2Z6stringZ6stringZ7mapelemZt4less1Z t4pair2Z6stringZ6stringZ5allocPt14__rb_tree_node1Z t4pair2ZCt4pair2Z6stringZ6stringZ7mapelem

This is how many STL function names will get reported, if you don't have a really good C++ name demangler (and yes, this is an example from a project I'm working on). Note that the problem might not be in anything in the STL, but a memory corruption could easily flatten something being managed by STL code.

Some aspects of the STL can be overly constraining. I find it very unnatural to have to specify one and only one comparison operation that dictates the sort order of a vector. In C, if you want to sort things differently, you can hand a new function pointer to qsort(), but with the STL, you're kind of out of luck. How would you go about writing a (thread safe) program that allows the user to sort something according to run-time criteria?

Some things simply cannot be managed appropriately by STL containers. For example, never try to use vector<auto_ptr<string>>. The semantics of the copy constructor of an auto_ptr are not compatible with the requirements of an object to be contained by an STL container (specifically, the copy constructor has side effects).

Re:One Downside

[Anonymous Coward]

Yes, thank you for pointing this out.

I think it needs to be said: As a high-level language, C and it's derivatives barely fit the definition. C has always been called "high-level assembly", and it's absolutely true. C is -great- for low-level work...but why in God's name are we pretending it is a competant high-level language? It is NOT on the same level as the languages you mention. In fact, it is not even on the same level as Pascal.

The nice thing about Python, Ruby, et al is that you DON'T need to know the full ins and outs of the language to be able to use them effectively.

And of course, there are the security issues of C (that aren't present in other languages)...

Re:One Downside

[Rorschach1]

Very true... I learned C originally in DOS and it worked fine there, but I haven't touched it much in recent years. I just recently started an embedded project, and decided I didn't have the patience to use assembly, so I jumped into the world of embedded C for the first time. It's a hell of a lot easier than assembly, stays quite tight with a bit of care (sprintf used up 80% of my available program space), and after dealing with a system having only 192 bytes of RAM and no OS I've got a much better appreciation of how the whole thing works. Stuff that seems like a major limitation after working in other high-level languages suddenly makes sense when you're coding on bare metal.

Re:One Downside

[YOND R BOY]

C++ depresses me. I feel like the whole world is jumping on some buzzword bandwagon. Personally I dont understand... C++ makes it easier to produce bloatware (which is apparently rewarded in the M$ world) and it has the added disadvantage of objects. Hey, at least its not Java which forces OOP on you instead of giving you an option. I can't really talk about the STL (partly because I have never used it and partly because it would depress me) but from the coders I do know who have used it, it is a sad sad mechanism for making your code slower and harder to debug and your executables larger

Downsides

[Frobnicator]

This is a longer post and has taken a while. Someone might have already said this, so please don't mod me as 'redundant'.

If you are a good computer scientist there are no real downsides. If you are just hacking a system together and don't understand how the datatypes and algorithms work, and you don't have time or care to read the manuals, you will be in trouble using the STL.

I have used several versions of the STL on several compilers and OS's, and find that as a whole, the STL has few downsides, **IF YOU READ AND UNDERSTAND WHAT IS GOING ON** If you don't understand the basics, it becomes a nightmare to debug. On the flip side, if you understand what is going on you can get very fast code at low development cost.

Developers need to understand that certain operations invalidate iterators, and things like that. (That is the most common error that I see.) When you get an error in STL code, usually it shows up not as a single error but as a huge list of errors as it propogates through the template library -- but it is just one coding error. You might consider those as downsides, but they are typical in computer programming.

A lot of people listed 'bugs', slow learning rate, and other problems, but in my experience the STL is easy to use if you consider the two aspects the STL covers -- data types and algorithms. I have seen other programmers struggle because they cannot separate the two. They think that string types should have string algorithms in the class, or sets have the set operations, and so on. The STL is an attempt to keep the two apart. It is easy to write new data classes that use the STL by implementing the few functions needed for all the algorithms, and it is easy to write new algorithms that use any STL object because they all implement the same small set of functions.

One example -- It is easy to change the allocation method (swap portions of ram to disk) simply by writing a new allocator. A co-worker insisted that the STL wouldn't work outside of RAM, but a simple allocator class allowed everything to work on disk for huge data stores. The co-worker had spent years working on implementing a few slgorithms and data types on his own. The STL with a simple, custom allocator worked faster than his code, and took much less time to develop. Poor guy -- I really felt sorry for him.

There are some problems with specific older compilers, but most are fixed. The older Metrowerks compiler didn't allow traits, the older Microsoft compiler didn't allow several kinds of nested types (use the service packs to fix them) and their debug info is terrible in VC6, GCC used to generate very bad STL code (it still has some quirks). The glitches are mostly fixed now. New, GOOD compilers will take longer to compile (downside) but will often generate either smaller code or significantly faster code (big benifit). I have seen cases where the executable doubled in size (the code bloat that people talk about), but the runtime decreased signficantly (not usually mentioned), and the code became much more readable. Since most of us (except embedded systems people) don't need to worry about size, the tradeoffs are acceptable.

Another benefit/downside is that if you use optimizing compilers that know about the STL, you can do really incredible things. For example, if you are using a valarray (value array) type to perform operations, you can get massive speedups. I use the Intel Optimizing complier for x86 chips, and it uses MMX, SSE, and SSE2 optimizations to perform many loop, array, and STL operations. It is cool to see huge sections of code the the compiler message "foo@bar@PARAM@Z has been selected for automatic CPU dispatch", and reading the generated code shows that it uses the MMX or XMM registers, depending on the CPU type, or use the slow, loop based values on 486/Pentium chips. A bad compiler would probably just go to the worst case, the slow loop -- so get a good compiler.

Itanium chips could do extremely well on many of the STL algorithms. (I have wondered if the Intel Optimizing compiler for Itanium would do massivly parallel ops with valarray classes. Does anyone have experience there?) Other parallel chips can benifit in this way as well, IF THE COMPILER IS SMART ENOUGH TO DO IT. The downside is that you have to know how things work and why. If the compiler doesn't do the optimization, perhaps another algorithm would work better in that case.

Re:* is faster than C (??)

[leshert]

The most well-known example is using the sort algorithm instead of C's qsort. Because all the comparisons are templatized, and you never end up casting anything to void*, all the comparisons are inlined, and sort shames qsort.

When I tried it last, I didn't get the 6x difference some people claim, but it was about 2.5x faster.

Speaking from experience...

[jschmerge]

Like any other technology, the STL has several upsides and downsides. Since I didn't see many negative comments, I'm going to address some of the problems I've encountered using the STL.

My experience has been primarily writing and porting code in the UNIX environment, so keep in mind that I am fairly ignorant of the state of things in the Microsoft world.

The most obvious downside to using the STL is that the generated object code ends up being rather large. This is primarily due to the inlining of member functions of templated classes. While most developers don't really care about this type of thing, it does become a rather significant concern in the embedded world.

Another rather large problem with the STL is that some pieces of the library interface are rather inconsistent with each other. Some of the container classes throw exceptions, others don't. You may not think of this as a serious problem, but consider the following:

• An uncaught exception results in a core dump
• A Standards compliant version of the STL must throw exceptions (it's part of the standard)
• Usually exception handling is a feature neglected during the design of a large system's architecture, primarily due to people's lack of experience with C++
• Wily-Nily exception handling results in a very messy architecture

Steering ourselves away from exceptions for a couple of minutes, let's tackle the subject of inheritance... First the STL container class don't get along very well with class hierarchies; what I mean by that is that the following is a mistake:

class Base
{
...
};

class Derived : public Base
{
...
};

Base b;
Derived d;
std::vector<Base> v;

v.push_back(b);
v.push_back(d);

The rational as to why you can find in Scott Meyer's book Effective C++ . The short explanation is that an array of classes can not be properly treated polymorphically. I highly recommend that book to anyone looking to either write C++ or designing a program that will be implemented with C++.

Another issue that can crop up and bite you is that of memory management. The auto_ptr helps a lot with this one, but you must be careful with any non-intrinsic datatype that you store in an STL containers.

A couple other random things to consider:

• The string class that is almost part of the STL should be avoided. It is extremely inefficient to use, does not implement reference counting, and will generally cause many more problems than it is worth.
• Several assemblers (most notably older versions of Solaris's) have problems with the extremely long function names that get generated by the mangling process.
• Learn the functions/functors provided in <algorithm>
• Life can be a lot simpler if you make a habit of qualifying STL functions with their namespace (i.e. prefixing names with 'std::' instead of relying on the global 'using std;' directive).
• A compiler that supports the export keyword may help bring code size down.
• Remember that there is no compiler in existence that actually implements the C++ standard correctly... Being proactive in this regard can sometimes save a lot of agravation if a time comes that you need to port your application to new platforms.
• While the STL is extremely efficient at generic algorithms, hand-written code generally is leaner and faster.
• If working as part of a large team, take the time to educate people on how to use the STL, so the code doesn't seem foriegn to them.
• Always pass containers by reference or const-reference.

The STL is a fantastic programming tool if used correctly, however there is a steep learning curve and quite a few gotcha's. I hope some of my thoughts help.

Re:* is faster than C (??)

[Garen]

Some stats? Just by knowing how much more well-defined C++'s type-system is compared to C is enough to get an intuitive sense that there will be cases where C++ will out-perform it. As for a specific example, type-based alias analysis is one that seems to have been getting attention lately. C++'s templates, are probably the most remarkable example, as they can permit optimizations beyond the ability of current Fortran compilers.

Both of them are so fast already though that comparing them for the most part isn't all that interesting. Awhile back, Alexander Stepanov created the Abstraction Penalty benchmark to test the effect of using abstraction features in C++ like the STL. Over the past several years I've noticed that the penalty is usually close to nothing, if not sometimes less than -- indicating a speedup.

Re:* is faster than C (??)

[Anonymous Brave Guy]

I think the key point here is that you can write an efficient, generic sort algorithm in C++ using templates. The closest equivalent in C, short of hand-coding a specialised version every time you use it, requires an indirection via a pointer at the least. Thus C++ does indeed provide a more powerful and probably faster way to solve this particular class of problems.

Lisp: the Meta-Programming Shangra-Language

[SimHacker]

The Meta-Programming Shangra-Language for which you yearn has been around for many years, and it's called Lisp.

Check out the Common Lisp Macro System, which is deeply explored in Paul Graham's free downloadable book On Lisp.

On Lisp is a deep, wonderful, mind-expanding book, originally published by Prentice Hall. It's earned five stars on Amazon. The book is out of print, but fortunately thanks to Paul Graham and Alan Apt of Prentice Hall, you can now download On Lisp for free !

-Don

====

On Lisp

Synopsis: Written by a Lisp expert, this is the most comprehensive tutorial on the advanced features of Lisp for experienced programmers. It shows how to program in the bottom-up style that is ideal for Lisp programming, and includes a unique, practical collection of Lisp programming techniques that shows how to take advantage of the language's design for highly efficient programming in a wide variety of (non-AI) applications.

KEY TOPICS: Contains comprehensive presentations of key Lisp features: functions, macros, symbols and interning, variables, scope and lexical closures; object-oriented programming, data structures, and Lisp style. For experienced Lisp programmers.

TOC:

1. The Extensible Language.
2. Functions.
3. Functional Programming.
4. Utility Functions.
5. Returning Functions.
6. Functions as Representation.
7. Macros.
8. When to Use Macros.
9. Variable Capture.
10. Other Macro Pitfalls.
11. Classic Macros.
12. Generalized Variables.
13. Computation at Compile-Time.
14. Anaphoric Macros.
15. Macros Returning Functions.
16. Macro-Defining Macros.
17. Read Macros.
18. Destructuring.
19. A Query Compiler.
20. Continuations.
21. Multiple Processes.
22. Nondeterminism.
23. Parsing with ATNs.
24. Prolog.
25. Object-Oriented Lisp.
Appendix: Packages.
Notes.
Index.

From The Publisher: Starting in the 1980s, Lisp began to be used in several large systems, including Emacs, Autocad, and Interleaf. On Lisp explains the reasons behind Lisp's growing popularity as a mainstream programming language. On Lisp is a comprehensive study of advanced Lisp techniques, with bottom-up programming as the unifying theme. It gives the first complete description of macros and macro applications. The book also covers important subjects related to bottom-up programming, including functional programming, rapid prototyping, interactive development, and embedded languages. The final chapter takes a deeper look at object-oriented programming than previous Lisp books, showing the step-by-step construction of a working model of the Common Lisp Object System (CLOS). As well as an indispensable reference, On Lisp is a source of software. Its examples form a library of functions and macros that readers will be able to use in their own Lisp programs.

====

Re:* is faster than C (??)

[Skapare]

If you hand code a new implementation every time you need to do sorting in C, then you are doing programming the wrong way. Ever heard of re-usable code? And if you limit you scope to the libraries that come with the languages, you're missing the potential. Look at PERL, for example. What comes with the language pales in comparison to all the cool stuff you can find online. And those things are used to promote the benefits of PERL.

I do note your focus on the indirection the stock qsort in the C library uses. Sure, it slows things down a bit. I guess I can count you in the group who says that Java and C# are completely worthless because of the much slower speed they operate? :-) Execution speed isn't everything all the time. Sometimes it is, but not all the time. And often, for cases where one might use qsort, there are often better ways to organize thing, anyway. If you have a huge array in memory that you need to sort, perhaps the design is all wrong in the first place.

Re:Yes Virginia, there are decent languages

[aebrain]

Someone hit me with a clue-by-four if I'm talking out of my arse or if not, tell me what decent compiled languages exist out there =)

No, you're not talking anally, it's a good question.Try Ada-95, or one of its proper subsets if you want embedded systems.

Rather than give lots of religious arguments, unverified opinions and hot air, here's some resources and quotes:

From Crosstalk (March 2002) :

There is now compelling evidence that development methods that focus on bug prevention rather than bug detection can both raise quality and save time and money. A recent, large avionics project reported a four-fold productivity and 10-fold quality improvement by adopting such methods. A key ingredient of correctness by construction is the use of unambiguous programming languages that allow rigorous analysis very early in the development process.

SPARK code was found to have only 10 percent of the residual errors of full Ada; Ada was found to have only 10 percent of the residual errors of code written in C. This is an interesting counter to those who maintain that choice of programming language does not matter, and that critical code can be written correctly in any language: The claim may be true in principle but clearly is not commonly achieved in practice. (emphasis added by me)

Parenthetically, I get a little miffed when I see so much unsupported balderdash being purveyed in Ye Greatte Language Warres. Try looking at the experiments people, you know, data, numbers etc? The Scientific method? But I digress, back to the stuff useful to you.

Another Crosstalk article, proving fairly conclusively that a working Ada programs's easier to write than a working C program, at least in some problem domains (high performance, real-time).

Ada for C and C++ programmers shows you how to do what you want, if you know C.

The LRM - Language Reference Manual, ISO-8652 (yes, it's an ISO standard). This version is the one with annotations.

Oh yes, there's an open-source compiler, GNAT available for free download. Like GCC, it's industrial-strength.

Finally, I'll echo my own experiences with the C++ STL: namely, that implementations differ markedly, portability is not a possibility, and performing surgery deep in their bowels is like unravelling rancid spaghetti. But YMMV I guess. Code Warrior 7 and MVC++5 were not compatible for anything other than trivial examples.

stl = big powerful juju

[technoCon]

i've used STL and i love and have hated it. you do it right, and walla, all kinds of jizzy things are easy. OR make some teeny mistake and you get 5 lines of extremely dense and unhelpful error messages.

I've found that the STL learning curve is steep at the outset. BUT if you've got some teammates who can help you along, good: get a copy of the Effective STL books and _Modern C++ Design_, and take a peek at the boost library.

Once i started reading _Modern C++ Design_ and I started grokking "generic programming" better, funky games with templates, and the mindset of library designers, i mean GOOD library designers, woah! suddenly i got to understand *why* i'd see those 5 lines of unhelpful error/warning messages.

When i taught C/C++, one of the least PC things I say is that the compiler issuing error/warning messages is like a girl saying "no when she means yes." The compiler will say one thing when it means another thing. Thus the ugly error messages. The coolest things in boost/loki/STL are done in spite of the language/compiler, thus when you get off track, you'll see goofball error messages because of those workarounds.

Recently, we had a program that was running slowly. But a key data structure doing a linear search of a big array was done in STL. We changed 5 lines and suddenly a different more efficient search algorithm went in and walla, we saw a big speedup. if we had NOT used STL, we would have gone 'oh shoot, we picked the wrong data structure.' Just changing a vector to a multimap did all that.

Flush from this success, we tackled another problem that was jsut perfectly solved by a functor object. Heck, i couldn't even spell functor 6 months ago, and i've been hacking C/C++ since 1984 and I think that getting into STL has opened up a whole new set of paradigms that every C/C++ programmer should have.

In the old C days, i was a total weasel with the preprocessor, and that became wicked under C++. With templates, generic programming, and all those STL paradigms, you're exercizing the C-front parts of the C++ compiler, which may explain why I like STL weaselology.

If you're unwilling to learn STL and climb that learning curve, pick up VB and wrastle with getting the right VBX/OCX components installed, OR sell your soul to the Dark Lord and use .NET components, C# and/or "managed C++."

Or you could do Java. but i don't know how to do "generic programming" in Java.

STL Error Decrpyter

[ElJefe]

For those of you complaining about the huge error messages that the STL can sometimes cause, you might want to try this:
http://www.bdsoft.com/tools/stlfilt.html

I haven't tried it because I haven't done anything with the STL in a while, but it seems pretty nifty. It's basically a Perl script that you can use to decipher the error messages into something useful. There's even instructions on how to make it work with VC++.

This article has a better description and an example, in which a 20-line error message is reduced to plain English.

Not OO, on purpose

[sohp]

If you chose to use C++ for its object-oriented abilities, you may be surprised to know that Alexander Stepanov (the inventor of STL) himself said he never uses what he calls "inheritance, virtuals - OO gook" of C++, and says, "I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people."

This may or may not be of any importance in your choice of language features and development practices.

Re:C++ is a horrible OBJECT language.

[muchandr]

The C++ kitchen sink approach to OO just plain sucks, but I find the newfangled generative stuff intriguing. Back in school we tended to settle on a more manageable subset of C++ functionality. You really don't have to use every obscure feature and than it becomes better. You can also write perfectly fine object code in plain C, using structs and function pointers. In fact, the most beautiful OO design I've seen in a real program is that of the Freetype library, written in C. For embedded folks, C++ is usually a non-option. On many small platforms, you'd be happy if your C compiler is working as advertised.

I don't follow the problem you have with compiler flags. Even if you compile parts of your code with different flags, you can surely still link them together?

Some downsides

[Anonymous Coward]

We used STL in a large project and ended up rewriting all parts that used STL because of two problems: One is that a lot of STL implementations - specifically the one that comes with g++ aren't thread safe. Supposedly stlport is thread-safe, but then their iostreams library isn't (but g++'s iostream library is - so you _can_ get it to work). Secondly, it is a pain to debug. Write your own template-based lists, hash-tables etc. and slash your time spent debugging by an order of magnitude. If you use STL and you're like me, most of your bugs will be related to data-structures that you use STL for, and that is exactly when you don't want to wade through the complexities of your STL implementation.

Just my 2 cents.