Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Downsides to the C++ STL?

Cliff posted more than 12 years ago | from the getting-the-whole-story dept.

Programming 1046

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

Sorry! There are no comments related to the filter you selected.

Downsides to Deep Anal (-1)

Sexual Asspussy (453406) | more than 12 years ago | (#3430665)

first post, fuckshitters

Re:Downsides to Deep Anal (-1)

Luke SkyTroller (564295) | more than 12 years ago | (#3430737)

Although I am a proud heteresexual with a healthy active sex life, last night my girl friend stuck her finger in my butt hole. Felt kinda wierd.

Re:Downsides to Deep Anal (0)

Anonymous Coward | more than 12 years ago | (#3430761)

I encourage you to encourage her to get a strap-on dildo. It's absolutely fabulous to get fucked in the ass by your girlfriend. Just take your time to get used to the dildo up your ass.

Re:Downsides to Deep Anal (-1)

L0rdkariya (562469) | more than 12 years ago | (#3430741)

Good job. I had a chance, but Slashdot logs me out every 7 seconds.

PS - I am not a fuckshitter.

Digital Canadian Theaters? (-1, Offtopic)

Syn Ack (3105) | more than 12 years ago | (#3430672)


Anyone know if any digital theaters exist in Canada and where?

Paul

A list of digital theatres: (0)

quakeroatz (242632) | more than 12 years ago | (#3430763)

Digital Theatres [technicolordigital.com]

And there are a few in Canada, most notably:
Famous Players Paramount
259 Richmond St. West
Toronto, Ontario Canada M5V3M6
Tel: 416-368-5600

Go raps!

Second Post (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3430679)

SP

FP! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3430681)

omg bejken..

first (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3430687)

goat~! first goat! haha ha this eats you all to pieces me rule you! Abklah baljf this is to get past the lameness filter. I'm not lame?! no estoy lamo.

Lots of overhead. (0, Informative)

billnapier (33763) | more than 12 years ago | (#3430702)

This may really only be a major concern for embedded and realtime platforms, but there is a lot of overhead with using the STL. Virtual functions and things of that like can make your code bigger and slower. The impact may not be noticed on a desktop system, but can cause havoc on your real-time requirements if you're not aware of them.

What virtual functions? (1, Informative)

Anonymous Coward | more than 12 years ago | (#3430728)

The STL uses templates, not an object hierarchy. And code that's heavily optimized for speed. Everything I've read has said that performance isn't an issue.

Re:What virtual functions? (4, Informative)

billnapier (33763) | more than 12 years ago | (#3430794)

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? (1, Insightful)

Anonymous Coward | more than 12 years ago | (#3430902)

It only generates code for what you instantiate. What code do you expect to write to support those 15 different types of things in C when you hand-write it and all the algorithms for it?

Re:Lots of overhead. (4, Informative)

nonya (65503) | more than 12 years ago | (#3430752)

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

Re:Lots of overhead. (3, Informative)

PD (9577) | more than 12 years ago | (#3430810)

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

56ker (566853) | more than 12 years ago | (#3430880)

What does STL stand for?

Re:Lots of overhead. (2)

gergi (220700) | more than 12 years ago | (#3430914)

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

Xentax (201517) | more than 12 years ago | (#3430898)

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. (2, Informative)

Anonymous Coward | more than 12 years ago | (#3430786)

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. (2, Informative)

billnapier (33763) | more than 12 years ago | (#3430827)

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

Anonymous Coward | more than 12 years ago | (#3430868)

Anything you do will cause havok if you aren't aware of it, but that doesn't generally include virtual functions since it's easily timed if you need to. You didn't make a comment about templates, and it doesn't bloat your code when any more than having to rewrite the functions when you're dealing with the equivalent of different template instantiations. So, I'm afraid you're still full of it.

Re:Lots of overhead. (2, Insightful)

Slowping (63788) | more than 12 years ago | (#3430800)

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. (5, Informative)

emount (547804) | more than 12 years ago | (#3430801)

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. (4, Insightful)

tenman (247215) | more than 12 years ago | (#3430816)

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. (2, Interesting)

Hawke (1719) | more than 12 years ago | (#3430819)

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)

Re:Lots of overhead. (1, Informative)

Anonymous Coward | more than 12 years ago | (#3430830)


There are no virtual functions in the STL. From an embedded developers stanpoint, the biggest drawback to the STL would probably be binary code size.

Re:Lots of overhead. (1)

yumyum (168683) | more than 12 years ago | (#3430860)

For I/O, perhaps. But all of the STL containers I've seen are templates with no virtual functions. Vendors may do things differently, but I've used GNU, Sun's Forte (RogueWave), and STLport and a grep of all of the them show just I/O and related virtuals.

Since most of the STL type checking evaporates during compile time and potentially inlines, your code just might be faster and with less overhead than otherwise. I'm addicted to the std::for_each function myself.

Brad

Bad inline optimisation. (5, Informative)

Phil Wilkins (5921) | more than 12 years ago | (#3430890)

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.

No (0)

Anonymous Coward | more than 12 years ago | (#3430704)

Use your own functions. Remember linus, real men code all from the ground up.

Re:No (1, Funny)

Anonymous Coward | more than 12 years ago | (#3430782)

ground up? right. im sure you're using a computer you whittled together from resistors and capacitors - each of which im sure you created out of the natural elements. you dont want to leverage anybody elses work you know.

Maria Covarrubias (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3430710)

I sure would like to fuck the blonde who plays the bitch on X-files! Even more than I would like to fuck Gillian Anderson.

One Downside (5, Funny)

jsonic (458317) | more than 12 years ago | (#3430711)

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 (0)

Anonymous Coward | more than 12 years ago | (#3430905)

Parent is not troll...
Parent is funny...
please read post before modding!!!

Gnome sucks! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3430713)

GNOME = Gay Nerds Obscene Masturbation Equipment

Implementation is not so 'standard' (2, Informative)

Anonymous Coward | more than 12 years ago | (#3430714)

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

i luv cars (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3430716)

Howdy. Read this entire document before trying any of the steps.

'Having sex with a car'. The phrase is sometimes misunderstood to
mean sex in a car, and sometimes is greeted with skepticism. How can you
have sex with a car? The short answer is, up the tailpipe.

The long answer is much more involved, including techniques,
precautions and cautions all designed to get you maximum satisfaction from
screwing a car. Our first subject will be the tailpipe.

The tailpipe of the car is, of course, where the exhaust comes out.
So in this sense, the tailpipe is an anus.

First we will deal with some cautions you should know about.

In most cars, the edge of the tailpipe is sharp. You should
therefore exercise caution when doing anything with the tailpipe.

If the engine has been on for a long (or even a relatively short)
period of time, the tailpipe will be hot. Do not do anything with the
tailpipe hot. Wait until the tailpipe has cooled off. The tailpipe will
cool off faster than the engine, so you don't have long to wait. I call
screwing the car while the tailpipe is hot, "fucking the car hot". Never fuck a car hot. I did, once. Once.

The exhaust from a car contains poisonous gases. One of these,
carbon monoxide, is a slow killer. Carbon monoxide takes a long time to
be flushed out of the body, so it can build up to toxic levels without
your knowing it.

Never do anything with the tailpipe while the engine is on!

Now, the first thing you should note is that the inside of the
tailpipe is usually coated with soot. This is the usual particulate debris
of combustion. Before having sex with the car, clean the inside of the
tailpipe with soap and warm water, as far as you can go. Keep in mind
the possibly sharp edge of the tailpipe.

Now that the tailpipe is clean, you are ready to pleasure and be
pleasured by the car.

You can do this two ways. One way doesn't require any equipment.
The other way (which is much more rewarding) does.

The first way is to fuck the car 'raw'. This does NOT mean stuffing
your cock into the tailpipe and thrusting. This would hurt (remember the
sharp edges?) and be no fun anyway, since the tailpipe doesn't flex.

What you should do is get behind the car and start jerking off.
When you are about to come, carefully put your cock into the tailpipe of
the car, and then come. But, in the heat of passion, you must still
remember the sharp edge. Even putting just the head into the tailpipe is
good enough. Just make VERY sure that you don't hurt yourself.

Now, this assumes that you can get your cock into the tailpipe
in the first place. Some tailpipes are too small, and then, well, you're
out of luck. Find someone who has a car with a bigger tailpipe.

The best way to have sex with a car, however, is not raw. You
need the following equipment:

1 Dekhyr Dragon Industries (Teledildonics Division) Sexual Interface Unit.

If you don't have one, you can get one through me (Dekhyr,
xdraco@panix.com) or you can attempt to build one yourself. The SIU is
essentially a tube made of foam rubber, rolled such that the inner diameter
is slightly smaller than the diameter of your erect penis. When lubricated,
it acts as a sexual interface to whatever you attach it to. In this case,
it is inserted into the tailpipe of the car you want to have sex with.

To build one, you will need black electrical tape, a 'Koozie',
a can of soda, and a hefty pair of scissors. A 'Koozie' is a foam rubber
dingumbob in which you put a soda. It keeps the soda cold and your hand
warm. Being a 'give-away' item, you usually can't find it anywhere. I've
had reports of finding them in liquor stores. I've actually found a good
deal of them at a local discount-type store.

There are two kinds, thick walled and thin walled. I've only been
able to find the thick kind; the thin kind I've only been able to get
through an advertising company. The thin kind is particularly good with
tailpipes not much bigger than your cock.

Here is what you need to do:

1. Measure the circumference of your erect penis. This is most easily done
by wrapping a string around your cock (around the shaft, not the head).

2. Take the bottom of the Koozie out. You should be left with a tube.

3. Cut the wall of the tube from top to bottom so that you are left with
a slab of foam rubber which refuses to stay straight.

4. Now, carefully cut away material parallel to the first cut until you
can put the ends together making a smaller tube, and such that the inner
circumference of the tube is slightly smaller (say, by 1/2" or so) than
the circumference of your shaft.

5. Take a piece of electrical tape. Hold the ends of the tube flush.
Place the tape on the cut on the outside to secure the tube in the
middle. Now repeat with more tape until the cut is secure. Wrap tape
around the whole thing.

6. Drink the soda. With the scissors, CAREFULLY cut off the top and bottom
of the aluminum can. CAREFULLY cut a strip of aluminum lengthwise from
the can, about 3/4" to 1" wide.

7. Coat the strip with electrical tape. This is to prevent the edges from
cutting.

8. Attach the strip to the tube at one end.

9. 'Test drive' it! Lube it up with KY (try not to use oil-based
lubricant; you may want to use it with more than one person, and then
you'll be using a condom).

Now, stuff the SIU up the tailpipe and lube well.

You now have several options for fucking your car. One major one
is from behind. If the car is automatic shift, then put the car in Park
and remove the emergency brake. This will enable the car to rock back and
forth to your thrusts. If the car is manual transmission, chock the wheels
well, remove the emergency brake, and put the car into gear -- the higher
the gear, the more play the car has. This will also enable the car to
rock. Kneel behind the car. Now thrust in.

You may not have any trouble with heavier manual transaxled cars,
since you may not have to chock the wheels -- the weight of the car will
prevent the engine from 'topping out' and moving the car away. Lighter
manual transaxled cars are more likely to be topped out by your thrusts,
so chocking is necessary. In general, the lower the gear, the less
play, but the more difficult it is to top the engine out.

Another major method is to lie down under the car, your upper body
under the car, and thrust into the car. It is difficult, though, to make
the car rock unless you push on the closest rear tire.

I've also had some success leaning on my side and fucking the car
sideways.

More than one person can fuck a car if it has more than one
tailpipe on opposite sides of the car. This will also make the car rock
faster and harder since the energy of two people will add.

NEVER fuck a car with the engine on. Firstly, you will be breathing
hard, and that means you can poison yourself faster. Secondly, the car
will either stall (because there's something blocking the tailpipe, heh)
-- causing damage to the engine -- or will force the exhaust out. And
you have an idea where the exhaust will go, I trust. Ouch! Fatality City!

If you do not use a condom and you come inside the car, ten or
fifteen minutes of driving will kill off anything inside. So you do not
have to worry about STDs from that. What you will have to worry about,
though, is the SIU itself. It is not being sterilized. Therefore, if you
use an SIU you think is going to be used by someone else, use a condom,
and use KY jelly or some other water-based lubricant. Remember -- oil
rots condoms, and so will an oil-based lubricant.

Enjoy your cars!

Drawbacks (2, Informative)

EEBaum (520514) | more than 12 years ago | (#3430717)

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 (1, Informative)

Anonymous Coward | more than 12 years ago | (#3430771)

??

it seems pretty standardized to me-

vector-

std::vector v;
std::vector::iterator cur = v.begin();
while (cur != v.end()) cur = v.erase(cur);

map-

std::map m;
std::map::iterator cur = m.begin;
while (cur != m.end()) m.erase(cur++);

list looks like vector.

Re:Drawbacks (0)

Anonymous Coward | more than 12 years ago | (#3430833)

He's talking about when he wants to incorrectly iterate through a structure who's iterators he's just invalidated. It isn't a standardization issue, just one with him going into undefined behaviour territory...
P.s., don't use loops when you can use algorithms.

Re:Drawbacks (0)

Anonymous Coward | more than 12 years ago | (#3430873)

right, but he made it sounds like an STL problem instead of his. You do bring up one of the most powerful parts of STL in correcting me, though, the header. combined with and STL lets you do some absurdly powerful things in very little space.

Re:Drawbacks (1)

zimbu (99236) | more than 12 years ago | (#3430891)

I bet you read from pointers after freeing them as well.

Downsides to the STL (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3430718)

It might make your anus look like this. [goatse.cx]

So many standards to choose from (4, Insightful)

Anonymous Coward | more than 12 years ago | (#3430720)

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 (4, Insightful)

adamwright (536224) | more than 12 years ago | (#3430721)

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 (2)

Henry V .009 (518000) | more than 12 years ago | (#3430781)

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:Pitfall 1 : Lousy implementations/compilers (2)

SanLouBlues (245548) | more than 12 years ago | (#3430895)

This was fixed, but the patch was not distributed a`la MS's regular update channels. Patches here: http://www.dinkumware.com/vc_fixes.html (They're all header fixes as far as I can tell)

buggy implementations. (2)

rebelcool (247749) | more than 12 years ago | (#3430722)

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.

Re:buggy implementations. (1)

zaphod110676 (211758) | more than 12 years ago | (#3430841)

This is true but the beauty of C++ is that you can implement the obscure, ugly stuff once and burry it in a class with whatever type of interface you would like to use. Abstraction is your friend.

Re:buggy implementations. (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3430897)

rebelcool, have you been touching little boys' pee-pees again? i hope not. you know you are going to prison again if you have.

AFAICT, Very Little (2)

4of12 (97621) | more than 12 years ago | (#3430724)

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.

I never learned STD (-1, Troll)

CEO zed (568464) | more than 12 years ago | (#3430725)

Because Visual C++'s MFC is far superior.

Re:I never learned STD (0)

Anonymous Coward | more than 12 years ago | (#3430775)

In what ways are MFCs superior to STLs ? Pray do explain the benefits to us all... Is it just me or are MFCs 'good' for windows centric exclusively?

Re:I never learned STD (0)

Anonymous Coward | more than 12 years ago | (#3430778)

And hopefully you used condoms as well.

Re:I never learned STD (1)

Palidine (473353) | more than 12 years ago | (#3430793)

except of course that the MFC makes your executables the LARGEST things in the known universe. MFC is good for GUI app programming bad for everything else. It includes tons of libraries into the .exe and unless you are doing GUI you won't use most of them.

Re:I never learned STD (0)

Anonymous Coward | more than 12 years ago | (#3430796)

I never learned STD


Doesn't that stand for Sexually Transmitted Disease?


Also M$'s implementations of the STL are buggy and broken despite these problems being noted since release 1.0.

M$ dislikes ALL standards they didn't create?

Dunno....

Re:I never learned STD (1)

emount (547804) | more than 12 years ago | (#3430875)

Okay, thanks Bill. Another drone with the M$ blinders on that will never look at another API.

Re:I never learned STD (0)

Anonymous Coward | more than 12 years ago | (#3430900)


Uhhh. Do you know what you are talking about? The container classes in the STL blow the MFC container classes out of the water. I doubt that the engineers at Microsoft would even argue this point (I wonder what Herb would say). Furthermore, MFC simply does not have anything comprable to the STL algorithms. Nothing.


You do realize that the STD, as you call it, is not a GUI library?

ahem... (0)

Anonymous Coward | more than 12 years ago | (#3430729)

First post? I dunno. Anyway, one of the bad things about the standard library is spotty compiler support, especially around the edges where you can have goofy things like template template arguments and so on. Still, when it works, and it works most of the time, it can be a real treat to program it. I'm becoming a big fan of it myself. Meyer's "Effective STL" is a great book about the gotchas that lurk inside the STL (there be dragons :) ). I would have loved to have gone to a session by Meyers...

pros and cons of STL (0, Troll)

Anonymous Coward | more than 12 years ago | (#3430730)

advantages:

  • unified scoping and dereferencing between classes
  • metacircular allocation, instead of the old malloc-free style
  • deferred addressing (this is more of a compilation feature than programming boon)


disadvantages:

  • still no multiple inheritance
  • problems with template incompatibility between STL/non-STL applications
  • gay syntax
  • underpowered for serious e-commerce and business-to-business deployment.

STL downsides (4, Interesting)

Hawke (1719) | more than 12 years ago | (#3430733)

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 (??) (2)

Ars-Fartsica (166957) | more than 12 years ago | (#3430742)

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.

SGI STL reference (1, Informative)

Anonymous Coward | more than 12 years ago | (#3430743)

SGI [sgi.com] has some extra libraries [sgi.com] that are not included with some c++ editions...

Jim [biacreations.com]

everybody knows (-1)

IAgreeWithThisPost (550896) | more than 12 years ago | (#3430747)

programmers are losers.

Can also be hard to debug (1)

billnapier (33763) | more than 12 years ago | (#3430756)

If you have a problem with your program that is using the STL, the number of classes you have to wade through to figure out what's wrong can be enormous. I guess this really applies to any library that you're bringing in, but with all the virutal functions and template classes, it can be really hard!

I once spent a week fighting with the STL and my compiler because of the way the compiler was generating code for the template classes. I had to explicitly tell the compiler which specific classes to instantiate. But I've learned from my problems and won't have that mess to sort out again!

Not all compilers support it, god-awful comp errs (5, Informative)

Avumede (111087) | more than 12 years ago | (#3430758)

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.

Not many (5, Informative)

Xentax (201517) | more than 12 years ago | (#3430765)

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 (5, Informative)

Xentax (201517) | more than 12 years ago | (#3430849)

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

Major downside: VC++ support (1)

Christopher H (25358) | more than 12 years ago | (#3430769)

Extant versions of MS Visual C++ still don't support lots of important aspects of templates. You usually don't get bitten until you're writing your own STL-style utilities (ie just using the stuff is fairly portable). Someday MS may get their act together and make an attempt towards ISO compliance.

One disadvantage... (1, Flamebait)

FortKnox (169099) | more than 12 years ago | (#3430772)

... it isn't Java

*rimshot*

uh... wait,... that wasn't a rimshot... that was the sound of downmoderation... *grumble*

Rimshot emoticon (2)

geophile (16995) | more than 12 years ago | (#3430834)

Here it is, an ASCII rimshot:


\/!


This is my invention, which is mine.

Slow compile time and horrible error messages (0)

Anonymous Coward | more than 12 years ago | (#3430773)

It's a template based library, so it has all the problems associated with templates:

Long compilations on most compilers, but worse is horrible error messages when you make small mistakes. Every type is a template with two or more arguementsIt happens because every type is actually a template so you get very long error messages.

But it is still a great library, very efficient and highly expressive.

Its slashdotted (0)

Anonymous Coward | more than 12 years ago | (#3430774)

Use the mirror! [linux-kernel.tk]

Well.. (2, Informative)

DCram (459805) | more than 12 years ago | (#3430783)

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 (2)

Todd Knarr (15451) | more than 12 years ago | (#3430784)

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.

Going to miss Rogue Wave (1)

Codex The Sloth (93427) | more than 12 years ago | (#3430788)

I used to use RW for server side stuff -- switching to STL along is a poor substitute. The string class is much poorer and the msdev STL implementation is nowhere near as good as RW. OTOH, Rogue Wave is pretty expensive (which is why most people switch away from it I imagine...)

Good luck though!

overhead and memory leaks (0)

Anonymous Coward | more than 12 years ago | (#3430789)

Alot of overhead and tons of memory leaks. STL has not been tested as well as one might think...

Documentation could be better. (1)

sean-mccorkle (108563) | more than 12 years ago | (#3430799)

My limited experience with STL was pretty satisfactory, but I had a lot of trouble finding either a well-written reference or guide. There are plenty of books out there, but I had to study them pretty seriously and do a lot of learning-curve testing before I felt comfortable using the library.

Otherwise, the STL design is pretty rational. I'll continue using it.

the STL is imporperly named (4, Insightful)

dutky (20510) | more than 12 years ago | (#3430809)

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.

STL incomplete - needs Join (1)

j_dot_bomb (560211) | more than 12 years ago | (#3430814)

I find that much code I want to write requires database-like functions like join. I dont mean that it requires any of this necessairly written to disk. STL has all sorts of ways of indexing to speed up searches and inserts and do it cleanly. But then it misses the next key step which is join.

The STL is pretty good (1)

xiox (66483) | more than 12 years ago | (#3430821)

Once you've got used to it, the STL is a great productivity booster. No more writing those generic data structures. I'd say anyone using C++ who doesn't know the STL is missing out on a large chunk of useful knowledge. Unfortunately it takes a long time to master it (I haven't reached that stage yet!).

Problems? I find that executables can become quite large if you use the templates all the time, without thinking how large the code for all these classes can be. You have to think about using vector<T*> rather than vector<T> (vector<T*> is specialised).

Another problem can be the warnings from compilers. gcc-2.95 has awful warnings for errors in using templates. It's good to have a modern compiler (e.g. gcc-3.1), which doesn't leave you with an awful mess of < < blah > blah >. This is a general problem with C++'s template syntax, which can become very messy! I'd love a language which really cleaned up C++'s syntax generally.

STL migration (1)

roberto0 (242247) | more than 12 years ago | (#3430822)

As far as I can tell, STL is supposed to be standardized, but there are different implementations out there. You must always be wary when migrating your code. Different compilers will implement the STL, well, differently. This basically means that you'll always have to debug and test your code on every OS and with every compiler.

Another drawback is that STL methods don't parallelize that well.

Not many drawbacks (5, Interesting)

emarkp (67813) | more than 12 years ago | (#3430823)

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.

STL? (1)

Neill_Smith (177678) | more than 12 years ago | (#3430825)

Forgive the ignorance, but what exactly is the/a STL ?

Re:STL? (1)

jrennie (79374) | more than 12 years ago | (#3430863)

Standard Template Library. If I'm not mistaken, it's part of what defines "C++" (as opposed to being an addition to C++)

Jason

Memory Management (1)

keird (519534) | more than 12 years ago | (#3430831)

Here's my only beef with the STL: memory management. I've run into many situations where the STL memory manager just won't seem to release memory, especially in the string class. Now, it could have been the specific implementation that I was using, but I've seen many others with the same issue.

Re:Memory Management (2)

lkaos (187507) | more than 12 years ago | (#3430889)

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

Cross-platform compatibility is a pain (4, Informative)

catslaugh (443278) | more than 12 years ago | (#3430835)

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 (5, Informative)

lkaos (187507) | more than 12 years ago | (#3430843)

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.

Where the linkage? :-( (2, Informative)

NOT-2-QUICK (114909) | more than 12 years ago | (#3430848)

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!!!

well thats easy (0)

Anonymous Coward | more than 12 years ago | (#3430851)

Well obviously c++ is not c so it is not the One True Language and there for totally sucks ass and is just trash. C is The One True language and any innovative open source hacker knows c is the greatest and should be used for the rest of eternity and if you disagree i will declare a fatwah on you.

please not the sarcasm. thanks.

Potential code bloat (1)

Christopher H (25358) | more than 12 years ago | (#3430852)

Extensive use of templates can result in substantial executable code expansion. If you know what you're doing you can mitigate this by sharing code between instantiations. Like other time/space tradeoffs in C++ it requires the exercise of programmer judgement.

Templates can get really, really, really ugly. (0)

Anonymous Coward | more than 12 years ago | (#3430859)

Template code can be the most obscure, insanely ugly code imaginable.

So much so that I believe it's not worth it for most of the uses people have in mind. Fact is, if you can't read, you can't fix the bugs, you can't maintain code someone else wrote, etc.

And in my experience there are some really hot-shot C++ gurus who can look at any C++ code and instantly know exactly what it means and whether it's written correctly or has fallen into one of the (many) C++ legalistic potholes. But I don't believe your average C++ programmer falls into this category. As soon as you get beyond the trivial uses for templates you get into code that is inherently prone to error simply because correctly writing it is very difficult, mistakes and mistaken assumptions or understanding become common, etc.

If you don't agree with this assessment, just go look at the STL code yourself. It's template code, so you get to see the sources. Now, if you could actually implement that yourself, then you are one of the gurus I mentioned earlier. If you couldn't, and be honest with yourself, then you are playing with stuff you don't truly understand, and that is a recipe for disaster.

As Brian Kernighan once said, debugging code is inherently twice as hard as writing it, therefore if you are writing code that is as hard as you know how, by definition you are not smart enough to debug it.

This is true for C++, in fact I'd argue it's not even just doubly true, it's triply true.

Re:Templates can get really, really, really ugly. (1, Insightful)

Anonymous Coward | more than 12 years ago | (#3430884)

the whole point of c++ is so even non-gurus can use good implementations of standard stuff...

Overhead (0)

Anonymous Coward | more than 12 years ago | (#3430864)

STL is good, but realise the limitations. STL can only store objects, not pointers, unless you write a class to wrap the pointers (Simlar to a smart pointer class). Therefore to add something to a list a copy is made. Thats why copy constructors are necessary. You do know the difference between a deep and a normal copy ?

They are useful, good knows we don't anyone to write another linked list class, but lots of copying can go on behind the scenes.

Welcome to C++

Downsides? not a lot phisically (1)

tandr (108948) | more than 12 years ago | (#3430872)

more mentally

from my expirience

a. Management heard that it is bloated, not readable etc -- you will have HARD TIME to get permission to use it.

b. Not all programmers are equal - if somebody does not understand your code, they will try to make look like all the bugs are came from this particular code. See a. as well.

c. If there is even a slight possibility that this platform is not support some standart feature (old compiler, etc) you better know it in first place so b. will not led to a.

All other things like code bloatness etc -- well, if you write embedded app, you better be carefull. YMMV, you know...

Partial List (5, Informative)

Viking Coder (102287) | more than 12 years ago | (#3430887)

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.

SGI-STL Port (1)

JBMcB (73720) | more than 12 years ago | (#3430888)

Here's the portable SGI STL library, which is pretty good. Replace the crappy VC++ 6.0 version!

http://www.stlport.org/download.html

Enterprise issues with STL (5, Insightful)

MobyDisk (75490) | more than 12 years ago | (#3430892)

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.

downsides (1)

feldkamp (146657) | more than 12 years ago | (#3430906)

Regarding the STL, there are few downsides (in my opinion). My perceived downsides are:

Learning curve: it will take a little while to get used to the STL, but once you do, you'll love it. The STL documentation assumes a very good knowledge of data structures.

Confusing error messages: because of it's highly generalized programming approach, compiler errors tend to be very cryptic, and long. Again, once you've gotten used to the stl, the messages begin to make more sense.

Upsides:

Great performance: the STL is ridiculously efficient on virtually any platform; the people who coded the STL really knew what they were doing. If you understand the data structures that you're using, and read the documentation, you'll get great performance results.

Great documentation: it even includes complexity information (big-o/big-theta notation) and runtime guarantees

Very portable: works on VC++ 7 and GCC in the same way.

Hint: a central key to understanding the STL is understanding iterators

Biggest problem is Thread Safety (0)

bdrosen (203194) | more than 12 years ago | (#3430912)

Different implementations have different degrees of thread safety. Some implementation are very good with thread safeness, others don't do anything and most fall somewhere in betweeen.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?