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?"

One Downside

[jsonic]

but the truth is that I'm a skeptic, so what are the downsides to the STL?

It's written in C++? :)

Re:One Downside

[ajs]

Yes, biting your leg off is much better than putting it into a crusher. Much cleaner.

However, I suggest using a real high-level language if you want one (Perl, Python, Smalltalk, Ruby, etc) or going low-level if you want that and programming in C.

C++ and it's less abhorent, bastard child, Java are the ultimate examples of what C isn't good at.

I'm not trolling here. C++ simply isn't a good language design. It has all the power of C and twice the rope for hanging yourself. The complexity, contradictions and requirement that users understand every aspect of the language in order to program are high on my "why you shouldn't" list.

Java has only some of C's problems while being totally platform-antisocial (platform neutral would imply that it plays nicely with all platforms which is patently untrue). I will say that Java has one of the best object models of any language out there, but 1) that will change when Perl6 hits the streets and 2) it's somewhat overshadowed by the failure of the Java libraries to live up to the promise.

er... "horseshit"

[IBitOBear]

You were trolling here...

There is a need for a continum of tools. The fact you are part of the "everyone" who seems to think that a language must be all things to all people is, well, kind of a poor reflection on you not the language.

There are PLENTY of things that C++ isn't "the best choice" for. Primary among those are the projects where you just want to slap something together safely.

The fact that I wouldn't let most people near an industrial band-saw doesn't somehow invalidate the existence and purpose of that device. Yes, people who don't know, or don't care, to learn how to use equipment properly should be laughed at when they get themselves hurt. People who decide to go SCUBA diving withtout training and get themselves killed also deserve what they get.

People who jump into C or C++ without the necessary foundation in "real"(tm) (8-) programming will hemmorage memory and dump core and generally make all sorts of messes. Shame on them and pitty to their employers and all that.

Still, a skilled craftsman with C/C++ can and do make better, faster, and more effective code than an equally skilled craftsman using the safety-net filled scriptirrific languages.

Why do you think Perl and Python are written in C/C++?

[rant]
And to diverge into a rant some, Python is a screwup waiting to happen. Friends don't let friends use whitespace as a control structure. I officially consign anybody who advocates using Python for real work to RPG hell for the rest of eternity. replacing the two characters "{" and "}" with the one character ":" and needing to worry about counting spaces/tabs is no bargan. Yes there are editors that will help you but now your language is dependent on your editor and code that reads identically on paper may do different things in the computer. How dumb is that?

Anybody who recomends Python over C++ because C++ is a "bad" language but Python is a "good" one knows nothing about language theory (spoken or computer languages)
[/rant]

Re:er... "horseshit"

[IBitOBear]

Why it is a well-designed language:

(Summary first) Everything was put in or left out for a reason and that reason (per thing) is documented if you take the time to look. Since it will be impossible in this forum to address the entirity of the issue I will stick to the elementes you named. Specifically the four casting operators (actually there are five) and the constructor invocation as a sixth "cast", which you incorrectly classify as an ambiguity.

First you must consider the base language construct of the unconditional cast.

struct A { ... };
struct B { ... };

A * ptr_to_A = new A();
B * ptr_to_B = (B*)A;

In the base language "C" the above is legal, will compile just fine, and is totaly wrong. This program would likely fail catostrophically. This is the generic version of an actual problem we (at my company) just found in a comercial "C" product.

The thing is, the C-style cast has some core functionality that is occasionally indespensible. (The discussion of when and how this is indespensible is ommited as whole chapters of books cover this topic.)

More importantly the C-style cast is a "gloves off" operation. When the programmer performs this basic operations it is with the understanding that if it is wrong it is to be done anyway. Complaining about its existence is like compalining to a surgon that a scalpel is dangerous because it could cut something...

The four "lesser casts" (my term) are "gloves on" operations. The programmer, in using the spesific casts is describing a desireable transformation on the data and the compiler and/or runtime checks the viability of the operations to ensure that they are completely legal.

Consider first a language that will do silent uncasted transformations (C++ will do these in some spesific and well defined cases which I will get back to later)

if you have "let SomeString = SomeInt" and the language allows this as a transformation (see awk, possibly Perl etc) it will "just do it." but the "it" is only vaguely defined. It is worse if "let SomeInt = SomeString" where there is no obvious guarantee that "SomeString" contains a useful representation of a candidate integer.

Ok, so we can agree that the transformation of a datum from one intrinsic type to another is problematic. Composite types make this a composite problem. Now back to the casts...

All the casts represent expressions in the true sense. The opperations are transformative just as unary minus or square_root are transformative. The original object and representation are unchanged but the address or constantness or the "invariant" are manipulated. And like any expression there may be temporary objects involved. Listed from most-checked and safe to least, the compile-time resolvable casts are:

const_cast(existing_object) => the existing_object may only vary from the new_type by the addition or removal [usually removal] of the constantness.

static_cast(existing_object) => the existing_object must have a defined pathway to becomming an object of the new_type. Usually this is done by one of two methods. The most common transforms the address of the object into the address of the part of the object that is of the new_type. The second method creates a temporary object of the new_type using the relevant information from the existing_object.

reintrepret_cast(existing_object) => almost always a transition from pointer-to-existing_object to pointer-to-void or vice versa. The reintrepret cast is used to release the expression from the constraints of the invariant of an object. Usually in order to pass the object through some external interface (e.g. passing it to the OS etc).

Notice that these three casts each have a spesific guarantee of function for form. To take the safe root through a transformation you sometimes need to use two casts together. Most commonly you will un-constant-ize something and then static cast it if you are doing these kinds of casts in a way that requires composition. I'll skip the example for now. The important thing is that you can, once you know how to use your tools, know in turn exactly the transformations that your existing_object or reference or pointer there-to will undergo.

There is no uncertanty in the three compile_time casts.

The fourth "limited cast" is:

dynamic_cast(existing_object)

This one is trickeir as it has an implicit "if" statement within it at compile time and another "if" statement in it at runtime.

IF new_type is an obvious part of existing_object the dynamic_cast is identical to the static_cast and you should have used that. The compiler will use that static_cast in place of the dynamic_cast because it knwos you are being dumb. 8-)

IF however new_type is not clearly in existing_object(s) ancestory (this is the "else" of the above case) then the compiler generates code to deal wiht the cast at runtime instead of compile time.

At runtime, IF the new_type object that is "part of" the "whole_object" that existing_object might also just be "part of" then the whole thing goes off without a hitch and the expression works. If the request is impossible then either a zero is returned (remember "transformative expression" 8-) or an exception is thrown. (the causes and cases are again ommited, go read the book).

SO BACK TO THE CORE QUESTION: Why is the above a "good language design"?

Answer: Because an unconditional cast "(new_type)existing_object" could do any combination of the above, but the above only happen explicitly if you use them explicitly.

Hua?

Well, in the first three you *ALWAYS* get a thing of the type new_type so there is no testing to be done. The compiler will not let the activity go wrong. You don't have to test anything in the code, the compiler makes you a warrent.

The fourth, more dangerous and occasionally indispenseable and often quite desireable, cast needs support code.

In a lesser language, I would either have to inclde the support code for every cast *OR* "work without a net".

In C++ I can code to the spesific requirements.

A language that lets the programmer code to the spesific requrements without having to put in lots of dead code just to be safe is "well designed".

Some languages "seem" to be better designed because they put in the general case safety-net for you, but languages that generate "general case" code "for you" arn't well designed. The fact that some environments/compilers then try to take the safety-net code back out durring optimization etc are arguable. The work for the slapdash at the cost of allowing the programmer to express himself explicitly. When the programmer isn't really in charge of the code that is generally a "bad design" where effeciency is a factor. But for the people who need this net or don't know how to work without it, this kind of code is "good".

But I digress.

So what about the so-called "ambiguities" over constructor invocation as a casting operation.

First, construction of a new object isn't, strictly speaking, a cast operation. It is "so like a cast operation" that in practical terms the two operations are considered synonymous.

In actual fact, construction is construction. Casting is casting. Construction is the building of a new object using the information from zero or more old objects. Casting is the reconsideration of an existing object "in place".

The confustion arrises because a sloppy thinker often cannot separate the classification of an object from the application of the value of that object.

In the expression "A = B;" A is being transformed. In the special case "A_Type A = B;" the transformation of "starts from nothing". The construction of paramter objects durring fuction call is the latter case.

The language allows us to define the transformation of A with respect to many types. If we create a transformation of A based on a B then this is obvious. Sometimes things are not that simple.

The programmer is allowd to make a chain of transformations implicit in ther code space because the language design allows for one "free and silent" step to be added. That is, if B can become X and X may be used to transform A, then B will transform A by way of a temporary X.

The user is spesifically warned that this feature must be used wiht due dilligence. In particular if there is more than one possible X intermediary the compiler will pick the "best" one. The rules for finding this "best X" are explicit (there are exactly four such rules).

Additionally, under no circumstances will B => Y => X => A considered.

If there is more than one "X" and they score the same on the "betsness" scale the compiler will demand the programmer clean up his mess. Many less-well designed languages will silently pick one wihtout a peep, which one may change from compile to compile. This would be an inferior design because any "X" may have larger-scale implications.

The educated user is capible of making the transformations work seamlessly.

The educated user is capible of explicitly disallowing some transformations by use of the keyword "explicit".

The uneducated user is going to make a mess if he fails to understand and use the feature.

There is absolutely no ambiguity.

The fact of the matter is that a poor design will net poor code. Some languages will glop out corrective code for the programmer. Where the programmer is willing to pay this expense, and the application can afford this expense the issue is a giant "don't care".

Where the cost should not be paid, the "looser" languages don't give the programmer the ability to remove these expenses. To that end these "looser" languages have an intrinsic limit to their functionality.

Every language does actually.

However proficency in the tighter (and more demanding) language translates directly into the skillset needed for a looser language. The converse isn't true.

There is an old aphorisim: "If all you have is a hammer every problem looks like a nail." The secret obverse is "the more tools you have the easier it is to find the right tool for the job."

Think nailgun. Heavy, dangerous, effective as hell. If you are competent to use one, it will serve you well. If you never learned to use anthing more invasive than wood-glue then don't pelase-god try to use the nailgun.

The fact that you are uncomfortable using a nailgun doesn't intrinisicly mean the nailgun is poorly designed.

It's a poor craftsman that blames the tools.

Re:er... "horseshit"

[ajs]

And I quote:

"Everything was put in or left out for a reason and that reason (per thing) is documented if you take the time to look" [...] "In the base language "C" the above is legal, will compile just fine, and is totaly wrong."

Not every C++ devotee suffers from this sort of viewpoint, but many do, so I'd like to address it first. The idea that everything exists in a language for a well-defined, unique reason is hardly a defense of the language DESIGN. Yes, there are four casting operators because the designers felt that each was justified. In a truely high-level language you would only need one, and it would rely on the nature of the data to "do the right thing. In a truely low-level language you would need only one and it would do what you told it to, even if it was the wrong thing.

C does not attempt to prevent the problem that you cite above. C++ doesn't either, it just gives you a way, assuming you understand the language completely to ask the compiler to make it harder. This adds many layers of complexity and provides you with the situation where the vast majority of C++ programmers continue to use the C-style cast.

"The thing is, the C-style cast has some core functionality that is occasionally indespensible. (The discussion of when and how this is indespensible is ommited as whole chapters of books cover this topic.)"

Shouldn't your language be simple enough that those books aren't necessary, just to explain a core feature? Shouldn't your compiler either do the work of resolving your complex relationships or get the heck out of your way?

I look at any large-scale C++ project and I see something that Perl has classically suffered from too: there's more than one way to do it, and no one agrees on which way that is. In Perl, it's considered a strength because the language is so forgiving that it resolves many of the problems created this way (Python by contrast allows you to do things exactly the way Guido wants you to, and that too can work well). C++ however, does not give you any sort of assistance in resolving these problems, and differing views on which language is being used can be catastrophic.

This is, in fact, one of the reasons that Effective C++ and More Effective C++ should be required reading for every member of any C++ project. It's not that you'll get good ideas, but the fact that those books teach a certain dialect of C++, and gently bludgen the reader into accepting that that dialect *is* C++. The STL also does this by formalizing a dialect of C++ into a library that insinuates itself into your code (I never saw people using functors until STL became wide-spread, and then people felt they had to use them).

C also requires that you adopt some common usage, but the advantage there is that C is so painfully simple that it is hard to adopt a dialect that is wildly out of step with other programmers (I've seen people use cpp to prove me wrong here, and all I can say is cpp is perhaps the worst idea to ever grace a language).

C++ is a very good accedemic exploration of the value of C as a high-level language. It's ultimately a poor choice for real-world programming, but that may not have been an obvious conclusion if Mr. Stroustrup had not been so bold. I don't question the genius of the ideas behind the language, just the danger of using it on a daily basis.

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

[divbyzero]

By [at least one logical] definition, a high level language is one that uses constructs which do not map directly to those supported by the hardware on which it is running.

C is considered [by many] to be a low level language because it only uses constructs which are available on the majority of modern hardware platforms. However, C relies heavily on the construct of accessing the heap. On a purely stack-based machine which has no heap (some embedded systems, for example), you would have to emulate a heap in terms of stacks. C would therefore be a high level language on that platform, while Forth, a language based around the use of stacks, would be low level.

Sometimes the situation is reversed ... people design the hardware to match the constructs used by a particular language. This was so in the case of the old Lisp Machines [lisp.org], or Sun's picoJava [sun.com] chips.

Few languages these days are strictly interpreted, as in parsing each line of source code just before executing it. Many are compiled into an intermediate form, sometimes called bytecode. This bytecode, in turn, may or may not be a high level language for a particular machine, depending on how closely its constructs match the underlying hardware ones.

Even in a purely compiled language without an explicit "bytecode" stage, the further the language's constructs are from those of the hardware, the more instructions it will take to process each statement.

In short, there are plenty of high level languages which can compile to native code. But this does not mean they will run as fast as carefully crafted assembly!

Re:hey! lay off Java

[ajs]

You said:

Wow - I really hope you don't actually consider Perl to be a suitable alternative to Java, it is a scripting language for crying out loud (and an incredibly ugly one IMHO), I can't believe that whatever magic fairy-dust they plan to sprinkle on Perl6 will change this much.

First, define "scirpting language". When the term was coined it refered to syntax-heavy, grammar-light "languages" like bourne shell whose basic purpose was to collect commands into a re-executable, sequential file.

Perl has never been such. It is a general purpose programming language used for such varied tasks as image manipulation, scientific computing, database management, and an army of other tasks. Its "standard library" is perhaps the largest such in the industry. Have a look at the official module list [cpan.org] on CPAN [cpan.org].

Perl may be used as a "toy language" by many, but do not assume that that makes it a toy.

Perl6 is a re-design from the ground up, which is in many respects to Perl5 what Perl was to scripting languages. It introduces a real object model that takes the lessons learned and best practices from Perl5's very loose "roll your own" object model. It also retains all of Perl's power while focusing on the problem of creating a back-end that can be efficiently compiled or executed as byte code in Perl's own virtual machine ("Parrot", as it's known).

If you've ignored Perl because it looks scary, go back and try it again. You will be suprised. Very.

As an experienced Java developer, I have never really felt disappointed by the Java libraries (with the sole exception of the lack of support for asynchronous networking until 1.4) - what exactly is your beef with them?

Go look at that module list. Think about what it means to be able to think "hey, i'd like to..." and find that it's in the standard library! Now imagine how those of us who program in truly high-level languages like Python, Perl, Ruby, etc must feel when we have to "step down" to commercial languages whose standard libraries are controled by committe.

Re:One Downside

[statusbar]

Aha, but destructors do so much more than manage MEMORY. They manage the releasing of RESOURCES. Memory is just one resource. Once you get the hang of Resource Aquisition Is Initialization (RAII) things go a lot better.

That being said, nowadays my favourite thing to use a c++ compiler for is to implement a library of optimized code and connect it to a scripting language interpreter. Then write the main program logic flow in a nice simple small dynamic language!

www.lua.org

--jeff++

Re:One Downside

[rjh]

I've been using C++ since 1989. I'm still learning more about C++ today.

It always amazes me at how people who acknowledge they don't know C++/STL (as you said, "I have never used it") know so much more about it than those of us who've been using it since the mid-90s, and who still discover more neat things about it on a continuing basis.

That said: C++ makes it easier to produce bloatware.

Two answers:

• Yeah, so?
  
  Name me one advance in computer science that doesn't also carry with it the possibility of using the advance stupidly. Yes, if you deliberately do stupid things with C++, you'll get code bloat. But if you make the language impossible to do stupid things in, you'll also make it impossible to do clever hacks in the language. If I want a language like that, I'll use Java, thanks.
  
  
• Have you seen what that `bloat' does?
  
  Most of the time when people blame code bloat they're really blaming templates. Tell you what: look at the vector template and find out just how brilliantly sweet it is. Now hand-code it in C, such that it gives you the exact same level of sweetness, speed, and safety. Dollars to donuts says your C code is more bloated.

... and it has the added disadvantage of objects.

Spoken like someone who never made it past the introduction of Stroustrup's The C++ Programming Language. Repeat after me: C++ is not an object-oriented language. C++ never was an object-oriented language. C++ never will be an object-oriented language. C++ supports OOP, but that doesn't make it an OOPL. C++ is, more precisely, a multiparadigm language. You want generic programming? C++ has the tools. You want functional programming? C++ has the tools (awkwardly, but they're there). You want OOP? C++ has the tools. You want procedural/imperative programming? C++ has the tools.

Whatever you want, C++ has the tools.

Hey, at least its not Java which forces OOP on you instead of giving you an option

My harsh words about Java (above) were, as I hope the Java community will understand, meant as a gentle jab from one diehard C++ hacker--not as a misinformed flame like you're spewing here. Of course Java gives you an option. If you don't want OOP, don't use Java. Use Ada95 or Python instead, both of which support non-OOP paradigms and which can compile down to Java bytecodes. Java, like Smalltalk, is a purely OO language. Saying that Java sucks because it forces you to write OO code is... well, really foolish. Java doesn't force you to write OO code; you force yourself to write OO code by committing to Java as a platform. Java is a tool in the toolbox. A hammer doesn't force you to treat everything like a nail; but if you choose to pick up the hammer, the only person to blame is you if you needed to pick up the screwdriver instead.

I can't really talk about the STL

... Why not? Your utter ignorance didn't stop you from talking about C++ or Java.

... but from the coders I do know who have used it

... And are these coders competent craftsmen, skilled in the ways of the STL? Or are they incompetent two-bit fly-by-nighters?

it is a sad sad mechanism for making your code slower and harder to debug and your executables larger

Bullshit. Look at the following code:

/* C version: sorting random 1M-element array */

int compare(const void* first, const void *second)
{
int *x = (int*) first;
int *y = (int*) second;
return x < y;
}

int main(void)
{
int array[1048576];
qsort(array, 1048576, sizeof(int), compare);
return 0;
}

// C++ version

int main(void)
{
int array[1048576];
sort(array, array+ 1048576);
return 0;
}


[rjhansen@numbers cpp]$ time ./c_version

real 0m1.034s
user 0m0.960s
sys 0m0.070s

[rjhansen@numbers cpp]$ time ./cpp_version

real 0m0.719s
user 0m0.720s
sys 0m0.010s


... Want to repeat that bit again about how STL causes your code to run slower and be harder to debug?

Implementation is not so 'standard'

[Anonymous Coward]

For one, any vendor can provide his or her implementation, which can lead to some amount of uncertainty in terms of performance..

Drawbacks

[EEBaum]

On the whole, the STL is fantastic. The only drawback I've found is a lack of standardization across implementations. Specifically, if you want to remove an item from a vector/map/list, and keep iterating through it afterwards, the end result is somewhat unpredictable.

Re:Drawbacks (portable remove)

[IBitOBear]

Actually, like with most things, you have to understand the reasons and methodologies. In the cases where you are using the linked-list-like structures (e.g. not vector) you are warrented several things:

1) any iterator will remain valid if it is untouched.

2) any iterator not directly involved in an erase will remain valid across the erase.

3) any iterator directly involved in an erase will be erased and so invalid (therefore MyList.erase(cur++) is always illegal)

4) the only value that an iterator can legally have that isn't a valid member of MyContainer is MyContainer.end()

The only/best not remove_if (e.g. NOT using the built in algorithms etc.) version of the remove on condition requires two iterators. That is:

class something {...};
// This typedef is your friend
typdef std::set SomethingSet;

void remove_matching(SomethingSet & MyContainer, something & value)
{
SomethingSet::iterator cursor = MyContainer.begin();
SomerhingSet::iterator del_mark = MyContainer.end();
while (cursor != MyContainer.end()) {
// test for delete
if (*cursor == value) del_mark = cursor;
// Advance Cursor so it will remain valid
++cursor;
if (del_mark != MyContainer.end()) {
// do the erase
MyContainer.erase(del_mark);
// "re-zero" the mark
del_mark = MyContainer.end()
}
}

The above "seems" ugly but will execute in linear time and very efficently. It's uglyness though, is why the STL contains standard algorithms. Once you know how to write a function object correctly (and providing there is no prohibitive cost to copying your quanta) then the below which looks uglier:

MyContainer.erase(remove_if(MyContainer.begin(), My Container.end(),predicate_function_object(value)), MyContainer.end());

actually makes a heck of a lot of sense and optimizes down to something incredibly dense (8-) and effective.

Re:Drawbacks

[leshert]

We're in STL-land now, boys and girls.

"Algorithm" has a specific meaning: to wit, it's a functor that performs a specific job in a function-like manner, which can replace a hand-written loop. They're all defined in the <algorithm> header file. For example, instead of:


for( list<Widget>iterator i = lw.begin(); i != lw.end(); ++i){
i->redraw();
}


You're supposed to write:


for_each(lw.begin(), lw.end(), mem_fun_ref(&Widget::redraw));


I withhold judgement on whether the second is truly better than the first...

So many standards to choose from

[Anonymous Coward]

The current "problem" with STL implementations is the surprisingly wide variety of interpretations of the STL. If you are doing cross platform development you will run into incompatabilities. On the other hand if you are a single platform/compiler/STL shop then that should not be a concern at all. Be sure to have some Performance benchmark test programs though.

Pitfall 1 : Lousy implementations/compilers

[adamwright]

Such as the one that shipped with VC6. It's much better in VC.net, but VC's was bug riddled and slow as hell. I can't first hand comment on many others (though I hear SGI's is good) - But do your research before adopting an implementation.

Re:Pitfall 1 : Lousy implementations/compilers

[Henry V .009]

You can simply drop in the STLport version. It works great with VC6. Of course I've heard VC NET ships with a much better compiler and library

Re:

[account_deleted]

Comment removed based on user account deletion

buggy implementations.

[rebelcool]

all the various implementations of the STL i've used have had different bugs in them. Granted, you need to be doing some pretty advanced things with it, but thats what its there for.

And have you seen the actual code for the STL? Ugh. It demonstrates just how bad and obscure C++ syntax can be.

Debugging is the downside

[baxissimo]

Your comment points to what I think is THE major downside to STL: debugging.

If something's not compiling that you think should, you end up wading through the mile-long error messages. If it does compile but doesn't work right, you're going to find yourself in the debugger trying to step through some of that crazy obscure STL C++ code to try to figure out what the heck is going wrong. Neither is much fun.

But when it does compile and run correctly STL is pretty nice!

I'm looking forward to somebody starting over some day and coming up with a language that supports generic programming as well as C++, but which doesn't have the terrible syntax of C++ templates. It must be possible.

Basically people have realized that templates can can be used to create programs that run at compile time to do some very clever optimizations (template meta-programming is what they call it see http://www.boost.org for one implementation. Blitz++ is the big example use of the stuff that everyone points too). But the code to make this stuff happen is ATROCIOUS!

Yeh, you can make a template meta-program to calculate factorials at compile-time. Great! That sort of thing can come in handy. You can even write template meta-code that basically generates code at compile time. That's cool too! But the code to do it looks NOTHING at all like the equivalent run-time code. Why does it have to be that way? Why does compile-time code have to look SO different from run-time code, at at the same time look SO horrific?

I think what is needed is a new language that will put compile-time and run-time code on equal footing. It would be great if they had the same syntax. Then you could just, say, change one line to turn some run-time code into compile-time code (only when there's no dependence on run-time data, naturally). But it doesn't necessarily make sense to put all the run-time efficiency restrictions on the compile-time language. Dynamic function lookup by strings is a pretty big run-time hit, for example, but you wouldn't care as much if it were used for compile-time function lookup.

In general, the meta-programs seem work a lot more like functional languages -- so fine, I'd be willing to settle for at least a clean syntax for the compile-time language, say something Lisp-like, even if it looks different from the run time language. ANYTHING, as long as the syntax is clean and readable, would be better than the current situation of trying to do meta-programming in C++.

I think the situation C++ is in today with respect to generic programming and meta-programming is a lot like where C was when OOP started to become big. People realized that, yeh, C can do OOP, but it doesn't really support it. C allows OOP, but it offers nothing really to facilitate its use. I think Stroustrup makes that argument in his C++ book. So Stroustrup created C++ as a language that would support OOP, not just allow it.

Well folks, now we've got this handy meta-programming stuff, and yeh you can do it in C++, but it is not pretty. It's downright painful. Writing it is hard. Debugging it is hard. Testing it is hard. Reading it a week after you write it is even hard. Sounds to me like it's time for some new language stud to come and save us.

Error messages can be made readable

[fitzsimj]

Check out BD Software's free message decryptor: "Freeware with Source Code, supporting: Comeau C++, g++, VC++6, VC++7 (Visual Studio.NET) and Metrowerks CodeWarrior"

www.bdsoft.com/tools/stlfilt.html [bdsoft.com]

The messages are still a bit odd until you browse the class which triggered the error, but it shortens them down to a readable, meaningful length.

I'm a fairly recent STL convert and I find this tool utterly invaluable. I love STL because it provides a true standard for many of the structures and algorithms that are core to any project. I'll never have to deal with another crackpot programmer's homegrown, poorly commented dynamically-sizing array class again.

AFAICT, Very Little

[4of12]

I think STL is great.

About the only downside I've seen are old compilers bloating up the executable sizes if you use it a lot. I believe that's largely becoming an issue of the past, though.

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.

Not supported in C++.Net (??)

[Ars-Fartsica]

Maybe someone can confirm this, but the latest .Net SDK does not seem to provide support for the STL.

Otherwise, the STL is an excellent set of libraries to move the OO paradigm towards parameterized types.

Of course like the rest of C++, you pay a price in comprehension...this language exposes everthing to you and you will pay a price in development and comprehension time.

The STL is not OO

[Anonymous Brave Guy]

Just wanted to point out that the STL is not, in any way, an OO system. It uses classes, but that's as close as it gets. There's no use of inheritance, polymorphism (in the usual OO sense) or any other "typical OO" features.

Not all compilers support it, god-awful comp errs

[Avumede]

The fact that no compilers support all of STL is admitted by Stroustrop (sp?). However, in practice, most of it indeed works as advertised. You shouldn't have much problem.

But the real bear is the compilation error messages, which can be pages long, and ultimately completely unreadable. This is due to template expansion, especially with STL classes (most of them) that take a large number of arguments, most of which have default values already.

Also, as with all templates in C++, there is code bloat. But it is a tradeoff between having more code or having better type checking. You have to decide what is right for you.

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

[Mike Connell]

Just for the non C++ programmers, here's a (real) example of those STL template errors.

readply.cpp:109: conversion from `_List_iterator<list<basic_string<c
har,string_ch ar_traits<char>,__default_alloc _template<true,0> >,allo
cator<basic_string<char,string_char_traits &l t;char>,__default_alloc_tem
plate<true,0> > > >,const list<basic_string<char,string_char_traits&lt ;
char>,__default_alloc_template<true,0> >,allocator<basic_string<char
,string_cha r_traits<char>,__default_alloc_template<t rue,0> > > > &,c
onst list<basic_string<char,string_char_traits&lt ; har>,__default_alloc
_template<true,0> >,allocator<basic_string<char,string_char _traits<c
har>,__default_alloc_template<true,0> > > > *>' to non-scalar type `
list<basic_string<char,string_char_traits&lt ; har>,__default_alloc_temp
late<true,0> >,allocator<basic_string<char,string_char _traits<char>,
__default_alloc_template<true,0> > > >' requested

Not many

[Xentax]

In terms of usability, the STL is great. I've been told that it's not the be-all and end-all as far as performance goes, but it can handle most applications, even situations where there IS a performance requirement as long as it's not an especially stringent one.

We developed a call-routing application for Solaris in C++ using ACE and the STL, and were able to meet a fairly hefty performance goal.

The biggest downsides on the STL that we encountered were a few compile issues in terms of integrating ACE into the build (not a big deal), and the larger one of somewhat poor documentation of the STL itself. We used the MSDN STL documentation, and while Microsoft's implementation may agree with that API spec, Solaris' certainly didn't. See the signature of the map::delete method for an interesting example.

Both the Solaris (actually SGI) and RogueWave implemementations DO NOT match the documented interface, even though Rogue Wave's documentation says it does! So make sure your intended usage is actually supported by the implementation of the STL that you're using.

Xentax

Re:Not many

[Xentax]

Oh, one other thing:

Pay attention to which operations are expensive for the various data structures (map vs. list vs. vector, etc.).

The fact that the operations' syntax for each of these is standardized is a double edged sword -- it makes for clean code and syntax, but it can mask poor-performing operations. Consider iterating over a map vs. over a list, for example.

So, consider carefully what operations you perform on various structures, and (of course), profile where/when appropriate. Looking at the actual implementation of the STL you choose can go a long way in revealing such troublespots, if that's an option (SGI's implementation is pretty easy to get ahold of).

Xentax

Re:About maps...

[J.Random Hacker]

I know this thread should really be dead, but I have to respond. I'm not confused at all. I know in great detail what I'm talking about. Here's the scoop:

Hash tables have *amortized* constant time lookup, but worst case behaviour is linear. There are two basic approaches to hash table construction, and they degrade in slightly different ways.

Open coded hash tables use (something like) a vector of cells indexed by the hash value. If there is a collision, you rehash (compute a new and different hash) or scan for an open cell and use that. In either case, you keep going till you find something. This leads to linear scan on a nearly full table. Maintaining these requires the rehashing process you describe.

Bucket hash tables used a list in each cell. You hash to the cell, then scan the list. In this case, an over-full hash-table has long lists to scan. Again, linear in the worst case.

In both cases, we're assuming a good hash function. One easy way to get poor performance out of a hash table is to have a poorly performing hash function.

Now, with respect to the STL, the issue for the designers was, in fact, worst case performance; not expected case performance. Call it a design guideline if you will, but that is what they used as a criterion.

So, as I said in my earlier post, Hash tables were not in the standard because they have poor *WORST CASE* performance. Never-the-less, the good folks at SGI have produced several high-quality hash table implementations that are STL compatable (so have I, for that matter). At some future time, I expect that those hash tables will be added to the STL because they are quite useful, when used properly.

There are several good works on the topic. Knuth's "Art..." being the seminal work on complexity. He covers both types of hash tables in detail in volume 3. I also recall a paper by Stepanov discussing both the ideas behind the STL and the tradeoffs. It's fairly old -- circa 1990 or so IIRC.

Re:Not many

[jkujawa]

We used the MSDN STL documentation, and while Microsoft's implementation may agree with that API spec, Solaris' certainly didn't. See the signature of the map::delete method for an interesting example.

SGI's STL documentation is excellent. I always have a browser window open to it while I'm coding. And, as it's the basis of the STL in g++'s libstdc++, it's quite accurate. SGI's STL is actually used by a number of platforms, and works pretty well.

One think to watch out for is that the string class isn't thread-safe under linux.

http://www.sgi.com/tech/stl/ [sgi.com]

I also recommend Scot Meyers' "Effective STL".

Well..

[DCram]

The thing that always bites me in the ass is the string class.

string foo = NULL;

This always gets me, segfault.

I do a..

string foo = "";
where I define ""; as NULLSTR in some header.

I dont know if this is a real problem or no its just that i have the habbit of initializing stuff to NULL.
My bad style.

STL downsides

[Todd Knarr]

The big downside is executable code bloat if your compiler isn't good at optimizing away unneeded generated template code. The STL is almost entirely template-based. You could also call it a downside that you need a fairly current compiler because the STL makes heavy use of recently-introduced template features that even moderately old compiler versions won't understand.

You also get a certain amount of lock-in, where stuff that deals with STL-using modules also tends to need to use STL to pass the right containers around, but you can deal with that in wrapper layers and IMHO the gains make the little extra work worth it.

the STL is imporperly named

[dutky]

The biggest downside of the Standard Template Library is that it isn't very standard. The support for templating, across a range of compilers, just isn't very consistant, which makes using the STL in a portable manner almost impossible. Aside from that, the STL is, to my mind, just another giant complex wart on top the mind-numbing complexity that is ANSI C++ itself.

As with OOP itself, generic programming is a Really Good Idea but its implementation in C++ leave something to be desired for simplicity and accessability. Due to C++'s dominance in the marketplace, the STL will likely be with us for many years, but this is far from a desirable circumstance.

Re:the STL is imporperly named

[ivan256]

As with OOP itself, generic programming is a Really Good Idea(TM)

Be careful. It's generalizations like this that end up in the hands of managers and can lead to Really Bad Software(TM). There are plenty of cases where a small generalized solution is more apropriate. THere is no golden paradigm for software development.

Re:the STL is imporperly named

[SLOGEN]

> The biggest downside of the Standard Template
> Library is that it isn't very standard.

No, but the C++ Standard Library is in ISO14882 ("Programming Languages -- C++"), and it "superceeds" and embraces the old STL. Unfortunatly most people (and tutorials) still refer to either the STL definitions or use the term STL about the standard library.

> The support for templating, across a range of
> compilers, just isn't very consistant, which
> makes using the STL in a portable manner
> almost impossible.

Depends on what you use. Normally, it's not the containers themselves. that makes trouble, it's the functors and the algorithmic versions of operators (i.e. std::less and such), which most programmers don't use for the first few months.

BTW: GCC-3 has EXCELLENT template-YOUR_FEATURE_HERE support as well as standard library support.

> Aside from that, the STL is, to my mind, just
> another giant complex wart on top the
> mind-numbing complexity that is ANSI C++ itself.

C++ is complex because of the possibilities it offers... well, and it's heritage. To the untrained even the simplest tasks are compilcated... think how long it took to understand (not just learn) multiplication :)

> As with OOP itself, generic programming is a

Hmmm.... I consider generic programming perpendicular to OOP (this is a nice analogy when explaining why using GP from OOP sometimes requires "multi-dimensional" programming... if you understand?)

> Really Good Idea(TM) but its implementation in
> C++leave something to be desired for simplicity
> ans accessability.

Agreed, as well as consistence in compile-time versus runtime versions of syntax.

> Due to C++'s dominance in the marketplace, the
> STL will likely be with us for many years, but
> this is far from a desirable circumstance.

The Standard library (not STL) is the best thing that happened to C++ for years. I doubt it could have been done cleaner and more flexible in C++?

I would like to see optional garbage collection (with fitting restrictions to legal programs) introduced into C++. That's the no. 1 thing holding back (advanced/modern) OOP in C++.

--
Helge

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

[Viking Coder]

#define private public

The one macro you'll ever need. Heh.

Cross-platform compatibility is a pain

[catslaugh]

The STL is very effective. Most of the problems I've had with it involved cross-platform compatibility (as I tend to develop code that has to run on a variety of platforms). Depending on your various STL versions and compiler versions, you can have to deal with the vagaries of the presence or lack thereof of namespaces, the availability of default template arguments (which has led me to typedefs like typedef map<RWCString, RWCString, less<RWCString>, allocator> NVPairMap;), and some real headaches figuring out how to get the #includes just right to deal with the way that Microsoft has two different versions of the iostream headers in MSVC.

Overall, I consider the STL well worth your while to learn and use.

Check out "Effective STL" by Myers

[lkaos]

The last book in Myers effective triology goes into a great number of details about the pitfalls of STL

One thing to be wary of (as many have pointed out) is the different implementations of STL. GCC pre-3.x is pretty non-standard (although not necessarily bad). MSVC pre-6.x is absolutely horrendous (from what I gather, this is more of a legal issue than MS's fault).

Some of the wackiest things though IMHO are:

- Never use vector! It's a horrible specialization and is not even a container. Very, very bad.

- Allocators are for the most part evil. Be very wary of them.

BTW: There is a book Efficient C++ that says a lot of bad things about STL. This book absolutely sucks and is full of nothing but crap. While the examples aren't forged, they are examples of how not to use STL. Unfortunately, the book presents non-STL solutions that aren't even as fast as the proper STL solution. Long and the short of it is, make sure you (and your developers) are very familiar with STL and be aware of bad information about it.

Re:Check out "Effective STL" by Myers

[jkujawa]

I believe what you mean is never use vector<bitset>, which breaks certain semantics.
vector is the most useful container in the STL, and is the basis for the STL string class.

Re:Check out "Effective STL" by Myers

[lkaos]

Quick summary of the story.

The C++ commitee thought that a proxy class could be used to emulate a primative data type. They didn't know how to do this, but they believed someone would figure it out. To encourage this, they forced vector<bool> to be specialized to return a proxy object and to store the bits internally as a bitset (which is more efficent since it uses 1 bit per element instead of 1 byte).

Problem is that proxy classes cannot emulate primative types and the experiment failed. As it is, the vector bool class is still part of the standard and currently violates the rules for the behavior of a container class. (Namely that &v[0] is invalid).

Failed experiment that somehow made its way into the standard.

vector - vector<bool>

[lkaos]

Stupid HTML

Where the linkage? :-(

[NOT-2-QUICK]

For it being the 'holy grail' in software development, it seems like the poster could have dug up some sort of linkage for those not hip with exactly what STL truly is all about...

For the ill-informed, please see the following links concern the C++ Standard Template Library (STL):

*** Mumit's STL Newbie guide [wisc.edu]

*** Standard Template Library Online Reference Home Page [rpi.edu]

*** Another Informational Link [msoe.edu]

There, I feel much better.... and hopefully you do, as well!!!

Partial List

[Viking Coder]

Before you listen to any of us, go out and buy "Effective STL" by Scott Meyers, and probably "The C++ Standard Template Library" by Nicolai M. Josuttis.

Now, I don't want to get off on a rant here, but in my personal opinion, the worst thing about STL is their string support. It's great, because it's standardized, but that's about the only thing going for it, from a programmer's perspective. (Yes, it's highly optimized, but the API isn't very rich. I like rich APIs!) In other words, build your own string class, and give it a Has-A relationship to the STL string.

Also, I hate that Containers change paradigms on you, some places you can use integer indecies, sometimes you have to use iterators - and in my opinion, the line isn't very clearly drawn.

Also, the methods are written along the lines of, "if it's not optimal, you have to write the code yourself." I'm sorry - that sucks. Sometimes I need to remove an element from a Vector. Maybe I should be using another Container. Or maybe the API should allow it, but make it clear in the documentation that it's not efficient. I vote for the latter.

Get used to having your objects copied. STL Containers work by copying your objects. It's a different way of thinking for a lot of people. It has rammifications that are kind of hard to grasp, at first, if you're not used to it.

Don't use Containers of AutoPtr's! It won't work right! (Read "Effective STL" for an explanation.)

In my opinion, everyone should wrap every third-party library they use with an API that they can live with. STL is no exception. You might even expose every single member function, but you have the freedom to expand your API if you want. If you can't afford a stack push, then you probably shouldn't be using STL in the first place.

If you end up really liking STL, take a look at Boost. Some parts of Boost are really cool and well written.

Really, I think the best advice I can give is this : get to really know an API before you start to use it. Because, if you try to just use the parts of an API that you know and like, you're going to make horrible mistakes. Invest the time to get to know the library well enough to use it the right way. STL is no exception.

Of course, that's just my opinion, I could be wrong.

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. =)

Enterprise issues with STL

[MobyDisk]

I am an avid user of STL, and I have worked on many projects, large and small, that make use of it.

Advantages of STL:
- Standardized, comes with every C++ compiler
- Fast
- Generalized (excellent use of templates)
- Many different implementations freely and commercially available.
- Source code available.

Disadvantages of STL:
- Large executable file sizes
- Incompatibilities between implementations
- Complex to debug

STL is a very fast and powerful library. Ignore those who say "it uses virtuals, and is in C++, therfore it is slow" because none of them have ever used it. (C++ is in fact faster than C if coded properly, and STL is coded properly) Often, a good structure is much faster than using arrays, even if they have less overhead.

Unfortunately, STL's use of templates and inlines can inflate the size of your code in exchange for raw speed. This can vary very much depending on your compiler. MSVC adds 200k or more just for the priveledge of using strings! Using STLport still requires that you link in the old 200k libraries ON TOP of STLPort!

I do not recommend using STL on small projects where compiled file size is an issue. For anything else, go for it.

* is faster than C (??)

[Ars-Fartsica]

Every time someone trumps up the merits of their language, they always mention that it is (potentially) faster than C. This has been uttered so many times that I don't know why anyone uses C at all, it clearly has terrible performance (according to all the language advocates).

I'm calling your bluff. Give me some stats for example programs.

Re:* is faster than C (??)

[Paul Komarek]

I thought you might be interested in some counterexamples. I don't think Intercal or Befunge advocates have ever claimed those languages were faster than C. In fact, I don't think they claimed Intercal or Befunge was better than any other language.

-Paul Komarek

One example

[Anonymous Brave Guy]

Compare just about any use of C's qsort with C++'s std::sort. The fact that the latter is implemented as a template means that any specialised comparison functions can be inlined and optimised right in the sort algorithm, unlike the mandatory level of indirected required by qsort's call-via-pointer approach. I don't have any timings handy to give entirely objective evidence, but I've certainly done rough-and-ready timings on several compilers, and all the recent ones had std::sort way ahead. A quick glance at the generated assembler confirms the theory above.

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.

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.

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.

Embedded Platform Issues

[omnirealm]

I am on a research team that is developing a Bluetooth financial transaction system. One of the members of our team wrote an XML parser using STL components. When it came time to compile the XML parser using the embedded tools for a PDA, we found that Microsoft had not implemented the STL in the libraries they provide in Windows CE. We had to switch all our string processing to use Windows components like CString (which, admittedly, has more features that the STL's string). The moral of the story? Using STL may affect your portability, especially in the embedded systems arena.

Re:Embedded Platform Issues

[Jherico]

Using STL may affect your portability, especially in the embedded systems arena.

That's the stupidest thing I've heard all day. You switched from std::string to the MFC CString and you say that STL isn't portable? You don't need MFC's handholding. You go out and find one of the many copies of the STL that's freely available out there and you compile it yourself. You don't switch to something thats even LESS portable.

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.

Vendor specific

[Zathrus]

The biggest downside of the STL is when it doesn't work.

Sure, the standard is >3 years old now, but a lot of compiler vendors are still working out bugs with either the STL, their compiler, or their linker still.

Under AIX, we've run into relatively few problems with the STL itself, but the linker is pretty bad. Between it and the compiler compiles take forever (which is why I've been surfing /. more recently), and the executables are freaking huge.

This is, obviously, an AIX-specific problem. And it's pretty much an old story - every vendor has their own quirks with the compiler and/or linker.

Beyond that -- I've found a few things missing in the STL that would be really nice to have.

First, the only smart pointer is std::auto_ptr. It's pretty useless, since you can't use it in a collection, and you can't have more than one thing pointing at an object/memory block at once. This can be worked around though, since there are libraries that have better smart pointers. Check out Loki [aw.com] or Boost [boost.org] for two.

Second, there's no way to automagically ignore case on a std::string, or to upper/lower case it easily. Yes, I know, you can muck around with traits, but that's a PITA and renders your string uncopyable to other strings easily. Yes, I also know that you can use a transform() to do it. But this still isn't as nice as myString.lower().

Third, there's no date or datetime classes. You have to fall back on C time functions for them. I haven't looked for a good C++ library to handle date/time, but I'm sure there's one out there.

Fourth, there's no regular expression matching on strings. We use PCRE [pcre.org] with a C++ wrapper and it works fine for what we need though.

Both 2 and 3 are due largely to internationalization issues... in the case of 2 there's a lot of languages in which upper and lower case are non-sensical. And after having thought about the i18n issues regarding dates, I don't blame the standardization committee a bit for running away screaming from them (what date range? which calendar? how do you change between calendars? what about date weirdness with some calendars (like the missing days in the Gregorian calendar)? etc).

I used RogueWave prior to this job, so I tried to think of some of the things I was used to in RW and weren't in the STL. By and large I prefer the STL though. The container classes in particular are a lot more sane than RW's.

Advice from an STL battle-scarred veteran

[MagikSlinger]

First off: Why must you use STL? STL can be handy, but it can also be a terrible pitfall to the unwary. If your code is working and there is no compelling reason to re-write it, then don't/

Secondly: Be very, very careful about using pointers to dynamically allocated objects. If you are copying pointers around, you could very easily get into a dangling reference. A smart-pointer template (which SHOULD have been part of the STL) is a handy thing to have.

Third: Take the time to learn the Zen of STL. You must understand the rationale and mental model of the STL to get the most out of it. It doesn't take long (a week at worst).

Fourth: Get a good C++ and STL implementation. If you don't, you could wind up with compile errors that will drive you insane. <Sounds like the voice of experience, MagikSlinger!>

Fifth: Use STL sparingly. Don't go hogwild creating types made up of a dozen composited templates. When you get a run-time error or compile error, it becomes next to impossible to decipher what happened. Do not go more than two levels deep in an STL definition. map<string,MyClass> is OK, map<string,map<pair<T,X>,list< vector<int>>> is a very, very bad idea...

Sixth: Use the simplest datatype to achieve your goal. Don't resort to multimap, etc. with fancy indexing/hashing schemes unless you prove emperically that it will speed something up a lot. Not a little bit, but a lot.

Good luck, and have fun!

Why do a wholesale switch?

[cfulmer]

I hope you're not talking about re-writing existing code to use STL instead of the equivilent C++ libraries. That sounds like a great way to introduce insideous bugs in your code. If it ain't broke, don't fix it.

In our development team, we have people who prefer RW, others who prefer the STL and others who are agnostic. In general, we've had a very good experience getting them to work together. Sure, it tends to lead to larger executables, but that's not a particularly big issue for us.

One thing that I haven't seen others talk about is that the two do not necessarily perform equivilent functions. The STL provides a bunch of templates, and RogueWave provides a bunch of useful classes, some of which are templates. RWTime, for example, has no equivilent in the STL.

Also, if you want to use other RW libraries (such as their threading stuff), then you're going to need to use some of the base RW stuff anyway.

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 [horstmann.com]; 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.

It is hard to learn well

[Henry V .009]

You've read Meyer's book, which is a good start. You probably also want to check out Josuttis.

The STL is really as good as could be expected. Better even. There are problems. Some problems stem from the fact that it had to be approved by the standards committee. There was a lot of opposition to adding something that big to C++, so the size was cut down. Certain things are missing. (Heaps, general binders, good smart pointers) but versions are provided by many implementations. Check out CGI for one. They will also be added to the next version of the standard, along with a few other nifty things (As always check out boost.org for much of that stuff). The allocators are broken in my opinion. Using (different) customized allocators prevents interactions between your containers.

The biggest problem is its complexity. Like any C++ feature, understanding the STL is not enough. You need to understand how it interacts with other parts of C++. When you use the STL, you are using a rocket launcher instead of a BB-gun, shooting yourself in the foot can be much worse.

All in all the STL is god's gift to programmers. It really is. I can't imagine not having it to program anything serious with. I work everyday with AI and Image Processing algorithms -- stuff where performance really counts, mind you -- and I couldn't live without the STL. I barely use pointers anymore.

To sum it up, C++ with the STL is the only language that meshes (not always prettily) performance computing with high level concepts. It is a truly beautiful technology.

Object Lifetime Management

[Waffle Iron]

The STL helps greatly to manage the scope and lifetimes objects vs. roll-your-own C datastructures and algorithms. However, once you put together a complex system it can still bite you if you're not extremely careful. STL data structures allow you to push C++ to a very high level of abstraction, but you should never forget that you're still using a relatively low-level language.

You have to pay very close attention to where you are storing pointers or iterators, and to when the things they reference are freed or moved. It is very easy to misuse the automatic constructors and destructors in C++, especially if you don't understand exactly what the STL is doing "under the hood" for each operation you perform with it.

"Smart pointers" help, but they have their own bugs and quirks, too. (I once did "bidirectional" smart pointers that were pretty idiotproof; all ends of each multiway link were aware of each other, but this had a lot of overhead.)

You can minimize this risk to some extent by designing the code to pass around auto-constructed copies of data instead of references or pointers, but this will tend to impact performance, sometimes so much so that Java would be faster.

Multi-threaded apps are even harder to get correct, since STL is not generally threadsafe.

Oh yeah, looking at the mangled names when you debug your code will drive you insane.

Nevertheless, IMHO, the STL is still the best thing about C++ and is just about the only reason I would use it instead of C. (Either one, though, is a last resort. I tend to develop and test all code in something like Python, and port portions to other languages only as needed.)

Debugging templates is hell

[IvyMike]

Trying to locate a bug in a program that makes heavy use of templates, and specifically STL templates, can be infuriating. Besides having your data stored in a obscure data format that's difficult to view through normal debugging commands, you've also got type names that can be hundreds of characters long. The Sun Workshop debugger used to actually SEGV on some of those long names; apparently a buffer in the debugger overflowed. (This problem was fixed a few years ago).

Hiding the implementation of complex data structures makes for easier coding, but makes life hell when you're trying to vivisect a live process. At my work, we do use STL, but in small, measured doses.

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 [stlport.com] 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.

Traps for the Unwary

[Greyfox]

The biggest downside is that it's easy for an innocent array index operator ([...]) can do Strange Things. Things like creating object instances which will then immediately be destroyed after a test is made. This can make a serious dent in the speed of your code. Most of the good STL books you can get from your favorite bookstore cover the ins and outs of these pitfalls pretty well.

Folks complain about code bloat due to template usage but I think it's a reasonable trade-off for type safety. Especially if you were going to create all those classes one way or another anyway. By the by, for some really sick template usage, check out Andre Alexandrescu's "Modern C++ Design."

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.

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.

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 [stlport.org] 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.

STL is only as good as you...

[jvl001]

I've been using the STL extensively in a multiplatform environment for the past 5 years, and I heartily recommend it. It certainly beats rolling your own, and execution speed is typically not an issue. Most of the pitfalls mentioned here are common to C++ in general. They can be summarized as follows:

Learn who owns what. Learn how to handle pointers and references in an intelligent manner. Garbage collection is neat but is no substitute for good programming.

Read Those Fine Manuals. See SGI STL Tech Pages [sgi.com] for a good online STL reference. Pay particular attention to stated efficiencies. You can use an iterator to loop through any container, but not all containers are created equal.

Get a good compiler. Template and inline code bloat can be minimized by selecting a decent compiler and flags.

You can use things like for_each, but remember you can also use a standard for with iterators.

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.

/. is a skewed sample

[LoveMe2Times]

I just wanted to point out that asking about something like the STL here on /. will not give you much breadth of opinions on the matter. When it comes to programming and software development, /. has a high concentration of scripting language users for web site backends and administrative tasks, and a relatively small number of "application" developers. There are also a disproportionate number of systems programmers. From reading /., you might get the impression that C++ is not very widely used. While this is true in the Open Source world where there are many *many* more viable options, commercial software development is still pretty dominated by C++ with Java seeing use in some sectors. So what's the takehome message here? Even given /. bias, you're still getting a pretty positive response to STL. Anyway, here are a few things you should know:

1) Get STLPort. [stlport.org] Use STLPort. STLPort addresses many, many, STL issues. They add extra nice classes like hash tables. STLPort is thread safe. STLPort has nice extra debugging features. STLPort has readable code. STLPort is PORTABLE (thus the name!). OpenOffice uses STLPort, in case you're still dubious.

2) Get a couple of STL books. There aren't any really good ones (IMHO), but it's handy to have a printed reference with some examples.

3) You wanted downsides, so here's one. You will have to learn STL. Not the library, but the techniques--the API is easy. You have to write your own C++ classes well to take really good advantage of STL. The way you leverage the STL for absurd productivity is through generic programming and STL's pluggable component architecture. Still, though, even you all you ever use is map, string, and streams (or some other subset), you'll probably become a convert.

4) STL will keep getting better to use. Other people have mentioned it, but look at Boost [boost.org] for some ideas about where STL is headed. Also, the compiler people are aware of and are working on the error message and debugging problems. Both VC++.Net and gcc 3.x are making progress here.

Performance & size tests, c, gcc & stlport

[james_northrup]

I have been held to the java grindstone for 7 years and growing steadily despondant wishing I were back designing swift running systems of elegant templates... so this weekend I sat down for a personal STL refresher.

g++ is just what i needed for a fun and relaxing weekend of random hacks.

I was goofing off with a trivial c++ hack that provides a base64 iostream iterator. I've heard for a while about the relative bloat and performance hits on the IO side of c++ and wanted a peek for myself.. what I found was halting.. 50x performance increase from a simple C hack, all of it IO. Well, not to be defeated so easily, I plugged in STLPort with its spiffy optimized IO and gave a whirl. What resulted was not 1:1 with C but reasonably in the realm of hand tunable for IO buffering thereafter... this was after all, code that reads and writes a byte at a time vs. a c program that uses buffers...

the relative results of this effort were as follows: test were conducted streaming 1 meg of data to >dev/null on an athlon 1800xp under debian sid dist.

buildtimesize

gnu uuencode, from gnu sharutils, compiled c code. ~0.12 seconds/meg binary 9k

base64.h: using g++-3.0.4 -O6 -static
~3.5 seconds
binary size 895k

base64.h: using g++-3.0.4 -O6 (shared)
~4.8 seconds
binary size 6k

base64.h: using g++ and stlport -O6
~0.45 seconds
binary size 10k&7k, static and shared.

Solving C++ template code bloat with Squeeze++

[brdsutte]

Code bloat need not be a problem of using templates. If you look at

http://www.elis.rug.ac.be/~brdsutte/squeeze++

you can see that we are able to reduce the code size of real-life programs (e.g. LyX) using a lot of templates by 60%. This is done by compacting the programs after they are linked, applying aggressive whole-program optimization and code abstraction techniques. There is a specific manuscript on the page as well, on how to reduce the code bloat coming from the use of templates. An important technique is whole-procedure reuse: if several identical procedures are found at the assembly level, no matter what the source code was, the duplicates are eliminated from the program. If similar procedures are found (e.g. in sorting routines where only the called compare method is different), they are merged using a new parameter.

Cheers,

Bjorn De Sutter
Ghent University

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 [bdsoft.com]

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 [cuj.com] 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++ [stlport.org], 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.

Wishing Ourselves to Death

[ChaoticCoyote]

In 2001, Bjarne Stroustrup [att.com] started a dialogue about the future of C++. As primary inventor of C++, Bjarne is giving interviews, visiting user's groups, and posting in forums, all with the intent of stimulating discussion about where C++ should "go." It's an important topic for software engineers, and everyone has a laundry list of features they'd like to see added in the next revision of C++.

I'll buck the laundry-list trend and suggest some things I don't want to put in the next C++.

In my experience, C++ iterators, algorithms, and containers are inefficient and unnecessarily complex. The actual source code doesn't look terribly confusing — it's the underlying mechanisms that obscure function with too much form. We heap template upon template, giving the compiler nightmares while obscuring what is really happening "under the hood."

Is container abstraction akin to the hiding a car's pistons from its driver? No, because I'm not driving the car, I'm building it. And as any good engineer can tell you, hidden complexity and obfuscated parts have been the bane of many software (and hardware) projects. I have no problem with containers being part of the language — what bothers me is that the current set of containers is complicated and inconsistent. We need to refine the current standard before we begin adding new material; otherwise, we build new code on uncertain foundations.

An official template library also leads to another question: Just what is a "standard" container? Some people argue that, for the sake of completeness, we should add hash-based containers to the standard library. But "completeness" means different things to different people; someone might want balanced binary tree containers, while others would prefer B-Tree or r-tree implementations. And then we get into the whole issue of graphical development — and you end up with Java, that tries to be everything to everyone but does few things particularly well.

The current template library is much too heavy, prone to the "feature creep" inherent in a committee-based standards process. And when the standard includes an inconsistency, (list<>.sort() comes to mind), we're stuck with it. Should a list be sorted via its member method or the sort algorithm? And what constitutes a "required" container feature? I use about 20% of the vector<> template 80% of the time; it seems to me that C++ needs a functional hierarchy that stems from a set of concise "base" containers.

We also have the entire realm of garbage collection and "smart" pointers, which is a nasty tangle of divergent opinions. The auto_ptr<> type has numerous logical and practical problems, as does the Boost smart_ptr<>. I don't believe one type of smart pointer makes sense for all applications — and C++'s experience with auto_ptr<> should teach us to avoid providing specific solutions to general problems. I'm still not convinced that automatic garbage collection is a good idea in most applications; it tends to make programmers lazy about controlling their resources.

I've always preached that code should be no more complicated than necessary — and that includes the code I obtain from language libraries. The C++ container types are heavy and detailed, when what we need is a simple set of light, fast containers, with hooks for adding algorithms that fit individual application needs.

Anything else is trying to be Java. ;)

Re:Lots of overhead.

[nonya]

Um...you don't know what you're talking about. The STL does not make use of virtual functions.

Re:Lots of overhead.

[PD]

Just to add to the parent... That's right. STL does not use virtual functions. In fact, STL is not an object oriented library at all. It's generic programming, and it's the coolest thing that I have seen for C++ ever. (Now is the place where LISP programmers can shout out that they've been generic for 40 years.)

Re:Lots of overhead.

[Xentax]

The tradeoff on binary size for code readability and maintainability (and execution time, of course) can be well worth it, IF you have the memory to spare. Our target machines rarely have less than 1GB of RAM, so it's not been an issue.

Re:Lots of overhead.

[gergi]

STL = Standard Template Library

It basically defines a lot of common tools that you can use with your program specific needs such as lists and queues.

Re:Lots of overhead.

[Anonymous Coward]

What are you talking about? The STL uses templates for genericity, not virtual functions. And no, there isn't a lot of overhead when you use the STL if you watch the things you're doing. Any overhead incurred by virtual functions (and it's typically dwarfed by whatever you do inside the functions called) is predictable, and shouldn't cause "havok" on your real-time requirements. Admit it, you're talking out of your ass.

Re:Lots of overhead.

[billnapier]

I'll admit that I may have spoken rashly about the virtual functions, but my other points about templates and code bloat still hold true.

And it will cause havok if you're not aware of it.

Re:Lots of overhead.

[Slowping]

Too bad I don't currently have any moderator points, but I agree with this statement.

It really helps to pre-plan what you're going to do with the STL (I guess that goes with everything else in software dev). It can get really ugly if you use them on-the-spot as you hack away at an implementation. But if you think it through, you can control the costs of using the STL. Pre-plan and take advantage of C++'s "pay only if you use it" philosophy.

Re:Lots of overhead.

[emount]

The C++ language spec explicitly specifies the performance requirements for STL components (which is rare in a language spec, IMO)... the brunt of the work is at compile time, and there is no virtual function dispatching in the STL.

Re:Lots of overhead.

[tenman]

If your building an application, then you will not want to use STL. STL is a speed deamon. It will be great for coders that write to hardware (ex: phone switches, automotive computers, etc...). Templates is the name of the game here, and because of the lack of objects, the programmer enjoys the power of C++, and the speed of the older style ANSI C compilers.

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)

Bad inline optimisation.

[Phil Wilkins]

The main problem with the STL is that it relies heavily on inline functions, and many compilers (GCC included) still have very poor inline optimisation. The GCC variant we use for the PS2 (ee-gcc) has a terrible habit of inserting spurious writes back to memory, causing all sorts of unnecessary stalls.

Perversely enough, despite the unreadable and buggy implementation shipped with it, Visual C actually produced remarkably good object code from it. The vector class in particular was more efficient than many of the hand-rolled examples I've witnessed during my career.

...

Virtual functions, as others have noticed, are a complete red herring, as the STL doesn't use them, and any moderator with an ounce of sense would mod parent down for being uniformed karma whoring bollocks.

Re:Lots of overhead.

[PuntaConejo]

Unlike an inheritcance-based container,
like those in Java, the
template-based containers of STL
do not use virtual function calls to achieve
genericity. Although this may result in an
increase in code size, there are cases
where different types can use the same
code at runtime. For example, a container
of int * and a container of char * might use
the same object code.

Some of the benefits of template-based containers
over inheritance-based containers are:
1) static type checking
2) can hold non-class type objects.
3) no virtual function call overhead.

To elaborate on item 2: If you want a
container of intgers in a Java container
(i think) you have to have a container of
"Int" rather than "int".

this is wrong

[Karma Star]

STL, as all the previous posts have mentioned, does not involve virtual inheritance overhead (unless, of course, you derive from the STL - YOYO at that point).

however, that doesn't mean that there aren't any "cons" to the STL. if you don't catch exceptions thrown back from a contain, your bound (no pun intended) for trouble. expect performance hits if you insert into a vector, or you don't allocate sufficient memory ahead of time. the STL only wraps common data structure and their operations - the idea being that you don't have to write a list for Class A and Class B and Class C; you can just create a template of a list that holds a Class A or Class B or Class C. the behavior of a list is similar, the only difference between lists is what they hold.

perhaps what bill was really try to say was "there is a lot of overhead with using C++" for embedded and realtime platforms. that, i would agree with - to an extent. i would have to say that the big performance hit on a RTS w/ C++ would be vlookups against the vtable - but how would that compare to a large switch-case block? the vtable itself may consume a bit more memory, but it might cost much less in manhours and frustration to work with derived classes than to maintain switch case logic. remember, every time someone adds some new functionality, someone has to go through a full compilation/regression test w/ a switch-case. by adding a derived class, you only need to compile/test the class itself.

Re:Lots of overhead.

[Ozwald]

Actually, STL is blistering fast and the size increase of marginal compared to a C equivelent. On some platforms (Linux being one), the STL code is in a shared library to reduce the executable size.

Instead, imagine what you are gaining. You get a good string class. No more worring about if the buffer is big enough or having to realloc/free memory when a string is appended or no longer required. It makes buffer overflows history.

Hash's and Trees: you can do this in C/Perl/Delphi/whatever, but STL's implementation is very easy to use and is optimized like crazy. The STL writers are very proud of their algorithms' performance. This may be one of the cases where it's impossible to write a faster C equivelent.

Portability. Anything written in ANSI C++ will compile anywhere as long as the compiler and libraries are up to date. A program I am working on will compile on C-Builder 4, Visual Studio, and GCC on Linux, without a single #ifdef or third party library.

The only downside I have experienced is that I needed to spend some money on books. STL has a learning curve and you might find yourself aging rapidly while fighting syntax errors that fill up the screen. But once you get the hang of it, STL is the easiest way.

Ozwald

Re:Lots of overhead.

[angel'o'sphere]

LOL

moded as interesting but plain wrong.


but there is a lot of overhead with using the STL.

No there is no overhead in terms of speed. The STL is designed to yield as efficient code as a VERY GOOD coder would get by hand coding. As the STL is coded with "how will the compiler work on this" in mind its often far more efficient than hand crafted code ever will be. (e.g. inlining over several function calls in depth)

Virtual functions and things of that like can make your code bigger and slower.

In the STL there are only few virtual functions. Most are non virtual.

Also a non virtual call costs you about 8 bytes asuming a 4 bytes instruction and 4 bytes adress, where as a virtual call you cost about 16 bytes, load register with adress, two times 8 bytes and jump idirect with register and offset, again 8 bytes.

However in practice the latter case is often only slightly bigger than the former(depending on the instruction set of the CPU).

If the code will be bigger than without STL is a question how your compierl and linker treat templates.

And it is a question how you would replace templates by hand.

Regards,
angel'o'sphere

Re:What virtual functions?

[billnapier]

But templates increase code size as the compiler has to genarate a different version of the class for each unique instance that you use.

ie. If you use a Vector to hold 15 different things, the compiler has to generate 15 different version of the Vector class to compile your project.

May not be that much of a problem if you've got the memory.

Re:What virtual functions?

[lkaos]

The number of abstract data types IN NO WAY AFFECTS CODE SIZE. Sorry to say it loudly but too many people here keep repeating that.

It may *appear* that way when working with STL but that is only because of the debugging information. Using templates will increase the amount of debug information in the executable (for each instance of the template) but it does not increase code size in any noticable manner.

Note: Ok, there are some methods that do get regenerated per-data type but the overhead is small and STL uses extensive inlining so this is almost meaningless.

Re:What virtual functions?

[randombit]

If I use *vectors* to hold fifteen different types of objects, then I'll be using at least fifteen different vectors and causing fifteen different classes to be generated.

Yes, 15 different classes, but the overhead, in almost all implementations, is very very low, because each of these 15 different classes has most of their code stored in type independant storage.

For example, the map type stores it's stuff in a red-black tree. In the implementations I've seen, the map type just forwards most of it's calls into an internal object that does almost all of the actual work, and which is NOT a template, so only one copy of that code exists. These internal types aren't type safe at all; they rely on the external interface to ensure that they are used safely.

Rimshot emoticon

[geophile]

Here it is, an ASCII rimshot:


\/!


This is my invention, which is mine.

Re:Memory Management

[lkaos]

Easy way to solve this problem known as the "swap trick." This will work with any container (and strings) and is the only way to guarentee a reduction in capacity.

vector v(10000); //reserve bunch of memory
//even though size is 0

vector().swap(v); //swap the elements from an
//empty temporary including
//swapping capacity

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:STL Downsides?

[Jherico]

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

Sorry, no. If you're working with multiple DLL's and you access a std::list declared in some header from both of them, functions that you call in both DLL's will be located in both DLL's Thus code bloat. For a monolithic application, you are correct.

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).

That's a pretty broad statement, and again I disagree. Suposing you want to create a string class with a subset of the functionality in std::string? Do you re-implement it? Supposing you want to create a structure that is best expressed as a list, but has just a little more functionality? Granted, you have to keep a pointer to the derived class, because of the virtual dtor issue, but its not completely unheard of.