Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Book review: "Effective STL"

By MSBob in Technology
Tue Jul 10, 2001 at 04:49:01 PM EST
Tags: Books (all tags)
Books

What I'd like to review today is the new offering from Scott Meyers the author of some of the most influential books in the C++ community: "Effective C++" and "More Effective C++". From this highly acclaimed author comes the third book in series: "Effective STL".


"Effective STL" is a logical continuation of the two original books. It is kept in much the same style with short recipe like chapters that are loosely coupled which makes it easy to read them out of order.

Those of you programming in C++ know that STL has been one of the most influential libraries in the C++ world in the past decade. Few will deny that STL holds an incredible amount of power and versatility. Unfortunately this power is in most cases largely unleashed. The problem lies in the fact that STL is a relatively new offering with little source code using it to its full potential and documentation that is somtimes less than adequate. This is the issue Scott is trying to address in his book.

If you are like me you probably use STL in your code already, chances are you use nested containers and perhaps even try to play with predicates. But if like me you feel that you are barely scratching the surface and you would like to use it a bit more extensively to simplify your coding effort Scott's book will appeal.

"Effective STL" is an enjoyable read. Scott has an incredible talent at presenting quirky issues in a straightforward manner so that even I can comprehend them! "Effective STL" scores particularly well in this department. There are very few books that I can honestly say I understand 100% after a single read. "Effective STL" is such a book.

The first chapters introduce the feature most commonly used in STL: containers. Topics such as choosing the right container and problems with container independent code are covered with depth and clarity. The book moves on to talk about more advanced issues such as thread safety in STL (an issue very much avoided by most STL books) and about proper practices for item removal from containers. He points out why std::vector<char> may sometimes be a better alternative to std::string and how to integrate STL containers with legacy C/C++ code. Some treatment is given to the very pragmatic issue of understanding STL error messages (if you ever programmed templates extensively I'm sure you know what I'm talking about).

A few pages are dedicated to the issues of localization. Not enough detail in my view but in Scott's defense most C++ books are guilty of this.

I would be doing disservice to Scott Meyers if I didn't elaborate on the style of his writing a little. His books are all a very enaging read and "Effective STL" is no exception here. Unlike books of certain other authors Scott really has some sense of humour which makes his writing a joy to read. Short and concise chapters make the book an ideal time filler for your morning train commute. "Effective STL" introduces colour text in order to emphasize the important parts of the code being discussed. I found those (judiciously used) colour cues made reading the book even more enjoyable.

Summary. If you are a C++ programmer you must have this book. As it's unlikely that you already know all the items this book covers, even long toothed C++ gurus will have much to gain from this book. If you only just embarked on the STL adventure you will find "Effective STL" a goldmine of useful information about the library. If you already own "Effective C++" and/or "More Effective C++" I doubt I need to convince you that you should have the third one too. It is in every bit as good as the first two. Undisputable five stars out of five.

You can buy "Effective STL" and the other two titles by Scott Meyers from amazon.com and other big bookstores.

Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library by Scott Meyers Paperback - 240 pages 1st edition (June 6, 2001) Addison-Wesley Pub Co; ISBN: 0201749629

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Favourite publising house
o Addison-Wesley 20%
o O'Reilly 63%
o Sun Microsystems Press 4%
o Microsoft Press 4%
o Wiley 0%
o Other (comment) 6%

Votes: 63
Results | Other Polls

Related Links
o authors
o amazon.com
o Also by MSBob


Display: Sort:
Book review: "Effective STL" | 57 comments (45 topical, 12 editorial, 0 hidden)
kludge (1.64 / 14) (#9)
by core10k on Tue Jul 10, 2001 at 04:08:49 AM EST

STL; the kludge you use when every class doesn't derive from the same ancestor class. It's crap, people. Pick up a book on Java or Smalltalk instead, and maybe you'll actually learn something.

Who put their paradigm up your ass? (4.70 / 10) (#10)
by codemonkey_uk on Tue Jul 10, 2001 at 04:37:03 AM EST

Why insist in inefficient runtime-binding for problems that are best solved with compile time binding? Its ineffecient, and inellegent.

Okay. You'll want an example. How about writing image manipulation routines that work on a selection of binary (hardware) colour formats?

You can't use runtime binding because a single pixel is generally one of a selection of 16 or 32 bit types, but using compile time binding and generic interface design, its simple.

Traditional (Smalltalk et al) OOP is not a magic bullet, and its not the only valid paradigm. Open your eyes.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

heh (4.00 / 2) (#17)
by Garnier on Tue Jul 10, 2001 at 11:17:48 AM EST

You can't use runtime binding because a single pixel is generally one of a selection of 16 or 32 bit types, but using compile time binding and generic interface design, its simple.
Well, you can do it Java using reflection. That would kill the speed though (yes, even Java's stellar performance :-) which is probably not good for image manipulation routines as they tend to be quite CPU intensive.

[ Parent ]
zah? (none / 0) (#18)
by core10k on Tue Jul 10, 2001 at 12:13:46 PM EST

Either I didn't understand or you didn't; I'm not sure why 'selection of 16 or 32 bits' would require the STL, or Iterators, or whatever; what are you doing with those 16 or 32 bits? you aren't just "selecting" them - where do they go? If you're just talking about "virtual Colour getPixel(x,y)"(for example) then the STL doesn't apply at all.

[ Parent ]
You didn't understand (4.50 / 2) (#31)
by ttfkam on Wed Jul 11, 2001 at 01:57:56 AM EST

Find a good, advanced C++ book and look up the topics of type traits and template specialization.

codemonkey_uk wasn't specifically talking about the STL in this case, but rather about compile-time specialization. The STL is simply an example of this type of flexibility and efficiency.Note to folks who only know C, Java, Perl, etc.: Generic programming and template specialization are concepts that cannot be duplicated in most languages. Yes, I know about the early-access template support for Java, but I'm sorry but that's just the tip of the iceberg. Trust me, there's more out there that you haven't seen yet.

It's like trying to explain OOP to someone who's only ever worked in a traditional C model.

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
thank you (none / 0) (#39)
by core10k on Wed Jul 11, 2001 at 03:00:45 PM EST

Thank you for actually taking the time to explain what I didn't understand, by taking my example and critiquing my assumptions, so that I would have a better understanding.

Ahem.



[ Parent ]
Always funny (4.40 / 5) (#13)
by RangerBob on Tue Jul 10, 2001 at 09:28:28 AM EST

It's always funny that the most vocal critics of things C++ are also those don't really know much about it. This has been the case with any organization I've been involved with.

Most people that complain really either only have a small understand, or only dabbled with it a long time ago and haven't kept up with it at all. It's even funnier that people keep proclaiming that Java will save the world. Then again, they've been proclaiming it for many years now, but I have yet to see the world peace and unity that it's supposed to bring about.

As usual, you use the programming language that best fits your purposes. No language is really "better" than any other in any sense other than they're better suited for some tasks for others. Most people don't understand this, which is a shame since there's soooo much information about language theory out there. Code hackers don't understand this, and I'd gather that there are a lot of computer scientists out there who also don't get it.

[ Parent ]
The problem is... (1.75 / 4) (#30)
by John Miles on Wed Jul 11, 2001 at 01:26:47 AM EST

It's always funny that the most vocal critics of things C++ are also those don't really know much about it.

Knowing "much" about C++ can take you the rest of your life.

Computer languages shouldn't have a minimum-IQ requirement. C++ must die.

For so long as men do as they are told, there will be war.
[ Parent ]

Maybe less (none / 0) (#32)
by ttfkam on Wed Jul 11, 2001 at 02:08:23 AM EST

I give it a year or two assuming that you have had a strong programming background. I don't agree with it being taught as a high school AP language, but then again I think that a scripting language such as Python should take that role.

I don't want to start a flamefest here. Just from personal experience, I started learning C++ in earnest about a year ago and now I am reasonably competent in the language (including "advanced" topics such as templates). Believe it or not, but the STL actually makes things easier once you get used to it. And it really doesn't take all that long to get used to it.

---

#include <iostream>
#include <string>

int main () {
std::string mystring = "Hello World";
std::cout << mystring << endl;
}

---

Not too tough. There are some subtle things going on here, but 90% of the time, they can be safely ignored. The other 10% of the time, you should ask someone who's more experienced in C++ (just like any other language/library). I could tell you about some of those things, and I've only been doing this for a little more than a year.

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Oh Please (4.50 / 2) (#35)
by RangerBob on Wed Jul 11, 2001 at 09:58:51 AM EST

Operating a vehicle has a minimum IQ requirement. And even the most incompetent programmers I've seen can master C++. It's not that hard of a language, and it's a heck of a lot easier than some of the AI languages. People that say it's too hard either don't try or can't get past the confines of doing things in a functional manner. Either way, and I'm sorry if you take this as a slam, but an extreme bias against any language and a cult to any one language shows a lack of understanding of computer science.

[ Parent ]
kludge (4.00 / 3) (#15)
by ksandstr on Tue Jul 10, 2001 at 09:55:19 AM EST

RTTI; the kludge you use when your development environment doesn't support parametrized typing. It's crap, people. Pick up a book on STL or ML instead, and maybe you'll actually learn something.


Fin.
[ Parent ]
Java (4.00 / 1) (#16)
by Garnier on Tue Jul 10, 2001 at 11:06:58 AM EST

Actually the thing I am most looking forward to in Java, is the addition of generic type, in other words templates. They will probably be added in the next major release (1.5) in about 18 months time - if Sun keeps releasing a new version every 18 months. The Collections API will probably one of the first things to be implemented as generic types, so that we can have type-safe collections (and checked at compile time which is not possible now).

And to Ranger Bob who complained that Java hasn't saved the world: just give us some more time dude!

[ Parent ]

Generic programming (4.50 / 2) (#33)
by ttfkam on Wed Jul 11, 2001 at 02:17:36 AM EST

There's more to C++'s templates than simple type info. Unless Java comes out with things like type traits and partial template specialization, it will still lacking compared to C++. Don't get me wrong. I love coding in Java, but it is for different purposes and occupies different niches. If Java ever got all of the feature set of C++, it would be greatly diminished as the simple-to-grasp language that became so popular.

Then again, if C++ had some standard APIs for database access, networking, threading, etc., many of the reasons to go to Java would be eliminated as well. Time will tell.

In the meantime, the STL is IMHO the grand-poobah of general libraries out there for any language. Speed-wise it excels even when compared against the C standard library, and with regards to flexibility, it makes the C standard library practically laughable.

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Been there, done that (5.00 / 3) (#21)
by ucblockhead on Tue Jul 10, 2001 at 01:30:40 PM EST

The earliest container classes available for C++ did exactly that. I have less than fond memories of the early Borland Turbo C++ compiler container classes. Two types were provided, one type that required you to derive from "Object" another that stored void pointers and required a cast.

Both solutions sucked. One reason why the STL came about in the first place is people tended to avoid the "Derive from Object" versions in favor of the "void*" versions. The marketplace spoke, basically.

Anyway, I'm very happy not to have to do the derive from Object thing. It was a royal pain in the ass and made the code less maintainable.

I have no desire to return to those days.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Err.. (none / 0) (#29)
by marx on Tue Jul 10, 2001 at 11:32:09 PM EST

The point he was trying to make is that in Java, "Object" is the parent of every class by default. There is no marketplace, it is designed to be like that. The only reason C++ does not give every class a parent is that it would degrade performance, thus making C faster, and C++ would never have been accepted.

I'm not saying Java solves everything, I have a feeling the problem is object orientation itself, i.e. it cannot solve every problem well. Still though, if you're going to claim you're an OO language, it's not very good to leave out all the OO stuff from the defaults (i.e. default base class, virtual methods). In practice, classes in C++ are just abstract data types, which is very well, but things become very confused when people start claiming they are programming object oriented when they are not using any significant features of the paradigm.

Join me in the War on Torture: help eradicate torture from the world by holding torturers accountable.
[ Parent ]

Yeah, well, duh... (none / 0) (#36)
by ucblockhead on Wed Jul 11, 2001 at 10:49:02 AM EST

What I was trying to point out is that movement in that direction in C++ was pretty firmly rejected by the user community back before the STL ever saw the light of day.

I've worked on C++ systems where the only things that didn't derive from an "Object" class were base types, and I even knew of some obsessive-compulsives who wrapped "int" and "float" with class wrappers so that they could derive from Object. These systems sucked. They were an unmaintainable mess.

As for what people claim to be doing, well, most people are idiots. You can program in an object-oriented fashion in C++. You can also program in a structured fashion in C++. Your choice. That's really the whole point. Choice. Not having to conform to some academic's notions about what coding should be.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

cognitive dissonance (none / 0) (#40)
by core10k on Wed Jul 11, 2001 at 03:07:31 PM EST

I've worked on C++ systems where the only things that didn't derive from an "Object" class were base types, and I even knew of some obsessive-compulsives who wrapped "int" and "float" with class wrappers so that they could derive from Object. These systems sucked. They were an unmaintainable mess.

As for what people claim to be doing, well, most people are idiots. You can program in an object-oriented fashion in C++. You can also program in a structured fashion in C++. Your choice. That's really the whole point. Choice. Not having to conform to some academic's notions about what coding should be.

Either A)You're holding two contradictory points of view in your head at one time or B) C++isn't an object oriented language.

Hint as to the answer; as much as I'd like B) to be true, it isn't.



[ Parent ]
Sigh.... (5.00 / 1) (#42)
by ucblockhead on Wed Jul 11, 2001 at 04:57:21 PM EST

C++ is a language that can be used in an object-oriented manner if the programmer desires. This is in contrast with Smalltalk, which can only be used as in an object oriented manner, and C, which can not be used in an object oriented manner.

Anyway, there are no contradictory thoughts there if you understand the language.

Back to the original point, deriving everything from "Object" has little utility other than to satisfy academics. In the real world, real programmers have to ask, "what does it buy me". In this case, not much that can't be solved in other ways (i.e. templates). In addition, it has a high cost. You've either got to give up compile-time binding, or face a maintenance nightmare. That's fine for computer science professors and their toy programs, but in the real world, it doesn't fly. That's why Smalltalk never caught on.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

C in an OO manner (3.00 / 2) (#47)
by Azathoth on Thu Jul 12, 2001 at 04:44:06 AM EST

and C, which can not be used in an object oriented manner

Sure it can! Object oriented programming is a design philosophy not a language construct. Remember that C++ used to be nothing more than a preprocessor that generated C code. OO C is not pretty but it is OO.


[ Parent ]
Yeah... (none / 0) (#48)
by ucblockhead on Thu Jul 12, 2001 at 11:14:57 AM EST

Yeah, I know, I meant "not easily".
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Why there's not a single hierarchy in C++ (none / 0) (#56)
by fullcity on Thu Aug 09, 2001 at 09:58:19 AM EST

Others have said that the reason is efficiency. I'd like to expand a little.

In Java, you put a String into a container but when you take it out it's an Object. Then you have to cast it to String--that is, check that yes, it is really a String still. And think of the correct thing to do in case it's not. That is, you will get a runtime error.

The statically typed containers in C++ don't require casting when you take things out of the container. That is the efficiency advantage.

But STL containers are also more robust in that your type errors are caught at compile time, instead of being deferred to runtime.

In my opinion, the advantages of static typing are often underestimated by C++ programmers. They often develop runtime typing systems for their class hierarchies, intentionally defeating static typing.


Today's roast: Panama Hartmann Songbird, very light roast
[ Parent ]

One of the cool things about Meyers (4.00 / 5) (#14)
by RangerBob on Tue Jul 10, 2001 at 09:35:27 AM EST

Other than the fact that Meyers has more of a grasp of things than most, he has a cool outlook on updates to books. I had emailed the errata address for the "Effective C++" CD-ROM once to see if they had ever considered putting out patch files for it. I thought you could do something like copy it to a hard drive and then untar the errata updates on top of it. Turns out Meyers actually gets those emails himself and took the time to personally reply. He said he's been trying to get the publisher to buy into the idea for a while now, but that they are refusing to have a more modern thinking about media (more than likely, I think they just want to keep forcing people to buy newer versions of the stuff).

I've found that he's one of the few people out there to actually talk to the "peons". He also has never struck me as having too big of an ego (something I can't say about some of the big OOAD guys).

Addressing the editorial comments... (4.28 / 7) (#19)
by MSBob on Tue Jul 10, 2001 at 12:47:22 PM EST

Every time I post anything that has C++ or STL in the message body I always wake up at least one JavaBot (mindlessly) writing how obsolete C++ is. Well C++ has had templates for over a decade and now that Gosling saw how good containers are done he wants templates in Java. Go figure! But I digress...

I've recommended this book not to those who want to learn C++ or STL. I thought the third paragraph makes it clear: the book is for those who know C++ well and use STL in its basic form but want to improve their STL skillset significantly. Like I said in the review there is little wrong with the book. It retains the style of its hugely successful predecessors and the text is much up to date. It even includes tips for VC++6.0 programmers who are stuck with that incomplete and broken implementation of the C++ compiler. Just like the other books it's highly practical in style without being the monkey-see-monkey-do type of books that have been flooding our bookstores in the last few years.

Scott is very humorous and has the ability to stun the reader with language nuances that baffle experts. But he won't leave you baffled though. For every trick or obscurity he will offer a clear and unambiguous solution. Just to give you the taste of things to expect, Scott asks us to evaluate a short innocent looking piece of code:

ifstream dataFile("inst.dat");
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>() );

While this looks perfectly kosher on the first sight (we're passing two iterators to the constructor) it doesn't work! In fact the second line won't even create an object. You'll have to read the book to find out why...

Effective STL is one of those books where the beginning of each chapter states a problem or a puzzle or an ambiguity that is unavoidable on the surface but then the text proceeds with explanations and clarification. No chapter of the book left me with the feeling of only learning half the story. Pretty much all subjects that were discussed were done with a superb insight and a lot of thought must have gone into organising the chapters. The book does what is says on the tin: it teaches you how to program in STL effectively.

I'd like to ask the JavaBots to refrain from replying or I'll post to the queue the biggest antiJava rant Kuro5hin ever saw in its history. It's been a Java nightmares week at work so don't tell me I didn't warn ya :)

I don't mind paying taxes, they buy me civilization.

Come on! (3.33 / 3) (#20)
by Garnier on Tue Jul 10, 2001 at 01:19:27 PM EST

We want the Java rant!
We want the Java rant!
If you submit it in the queue it will probably go down fast, but you can at least post it in a diary.

a-content-Java-developer-who-enjoys-the-rants-nonetheless

[ Parent ]

Me too! (none / 0) (#24)
by jacob on Tue Jul 10, 2001 at 04:19:26 PM EST

I second your request for a java rant. Especially a long detailed one that will have a lot of points, so it'll a) stay in the queue longer and b) have more points for people to argue against. I do so enjoy those, as I've said before.



--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
zen (none / 0) (#26)
by core10k on Tue Jul 10, 2001 at 08:03:46 PM EST

Java is faster than Smalltalk and more flexible and complete than C++.

The End.



[ Parent ]
In this corner... (none / 0) (#34)
by ttfkam on Wed Jul 11, 2001 at 02:25:11 AM EST

Java is faster than Smalltalk because more resources have been put into it. Put the engineering muscle of IBM and Sun (and Microsoft and Blackdown and Symantec and Transvirtual and...) behind Smalltalk and watch its speed increase dramatically.

Complete as in breadth of library? Here I agree. Complete as in language features, I'm sorry, but you don't know what you are talking about.

Then again, I feel I have just been trolled by someone who wanted to read MSBob's rant too.

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
huh? (none / 0) (#38)
by core10k on Wed Jul 11, 2001 at 02:56:02 PM EST

Complete as in breadth of library? Here I agree.

Then we agree.

Complete as in language features, I'm sorry, but you don't know what you are talking about.

OK, I'm confused. How could anyone say with a straight face that C++ has a fuller spectrum of language features than Java? It's really quite baffling. C++ is a statically linked language, but Java supports dynamic class loading. QED. As in, there's no point in mentioning any other points, because that's pretty much a bloodied knife right there.

Anyways, no, you haven't been trolled. I'm not going to write any more responses (it's pointliness, I'm not an OOP expert, and neither are you. Any discussion we have is inherently sophomoric).



[ Parent ]
Aww c'mon! (5.00 / 1) (#41)
by ttfkam on Wed Jul 11, 2001 at 04:47:21 PM EST

What makes one an OOP expert? Reading and understanding "Design Patterns" by the GoF? Writing a large-scale OOP-based project? I am actually quite strong in both C++ and Java. But then statements such as this are always subjective aren't they?

Java supports dynamic class loading. Java also has different design goals than C++. C++ wasn't made to fill the niche that Java currently occupies. For example, C++ has language constructs that allow for decisions and optimizations to occur at compile-time. Java is very much a run-time based language. Compile-time parameterism and policy-based objects are unknown to and syntactically impossible to duplicate in Java.

I acknowledge that this seems like a whole lot of elitist mumbo jumbo at the moment. But take the following example of a smart pointer. (With apologies to Andrei Alexandrescu for this incomplete example)

smart_ptr<Widget,SingleThreaded>

smart_ptr<Widget,MultiThreaded>

In this example, whether or not the management of a shared item is threadsafe is determined by a compile-time policy. The resultant code does not show anything but a specifically thread-policy optimized smart pointer made especially for an object type called Widget. No runtime conditionals (if-statements), no large switch statements, and no object hierarchy to traverse through virtual methods. This example only used two template parameters (and only one policy). Imagine what happens when we add a storage policy and a checking policy. Your classes become like Legos with all of the possibilities that entails with basically no runtime overhead and (outside of the library) very clean and easy-to-understand syntax.

Impossible to do in Java and rightly so. This is not Java's designed problem space. No, a smart pointer is not necessary in most cases due to Java's garbage collection, but then this was only used to illustrate a point.

This also brings up another major point. C++ is seen as overly complex by many people. This is mostly due to the amount of options given by the language and the flexibility that these options may be used together. It is not for the faint of heart.

For the record, I learned Java before I learned C++. This is a good thing I think. It taught me to appreciate Java for its strengths (such as dynamic class loading), but also illustrated to me the problems that Java cannot solve and the niches that Java cannot occupy. Java is a simpler language and I am a firm believer that simpler languages should be learned first and only when you have exhausted your options should one move on to more complex languages. As such, I am a big fan of scripting languages for beginners and compiled languages for intermediate-to-advanced programmers. But that's a whole other conversation.

-------------

I do not believe that discussion is ever pointless. The only thing that is pointless is when you stop trying to learn from each other. I hope I haven't come across as overly arrogant or condescending. It was not my intention.

And finally, the troll comment was not meant as an insult. On K5, it can sometimes be difficult to tell if someone is making a joke, making a point, or just making noise. I honestly didn't know what your intentions were in this case.

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Well said. (none / 0) (#44)
by core10k on Wed Jul 11, 2001 at 06:06:14 PM EST

See subject. And I'd also like to add that the complexity of the C++ SYNTAX is my major beef, not the feature set. C++ to me is a nightmarish language where a person's knowledge of the language's isoteric features results in faster code.

Compare with, say, Java, where a person's knowledge and ability to implement algorithms results in faster code which is more 'comfortable' for me personally. If you consider faster code to be a worthy goal.

But then, if you really want faster code, you're better off twisting your 'OO design' just slightly so that you're left with mostly OO code with some procedural 'leafs' of your design, and then implementing those leafs in assembly. (I tend to have minor procedural sections anyways, old habits die hard.)

Anyways, I've gone off on a tangent and broken my promise not to respond, heh.



[ Parent ]
And Java? (5.00 / 1) (#45)
by ttfkam on Wed Jul 11, 2001 at 11:29:15 PM EST

Even Java relies heavily on esoteric language trivia for performance.

---

The "new" operator in Java: very expensive (when compared to C or C++) and should be avoided through the use of object factories, pools, or some other reuse mechanism. This is hardly common knowledge to someone first learning the language.

String manipulation (especially concatenation): should be done with StringBuffer objects and only after the StringBuffer has already reserved space for the character array.

Reflection: very handy for those hard-to-reach places, but an absolute dog performance-wise.
---

Yes C++ has more, but any substanitive language will have these problems. Every language has quirks and every language has gems. Java simply hides the fact that PODs are allocated on the stack and objects are allocated on the heap for example. It doesn't allow for any flexibility in this regard. Sometimes it's a good thing and sometimes allocating an object on the stack would be really useful, but Java won't allow it.

The idea behind type traits and partial template specialization (for example) is that these are things to be implemented within libraries so that others have simple yet powerful paradigms with which to work.

A person's knowledge and ability to implement algorithms results in faster code in C++ as well. It is just that your choice of algorithms is broader. Just because one musical instrument is easier to learn than another, and they both play a middle C, doesn't necessarily mean that the easier instrument should automatically be used. Otherwise most music would be done on recorders!

Going back to the STL (how did we get here?), downplaying it because the source for the STL is cryptic is unfair. I would bet you that java.util.Vector is a horrible monster from the inside. But that isn't the point. Let the complex but recurring themes get handled once by experts and leave the higher level APIs to the rest of us. The difference between Java and C++ is that Java tries to protect us from ourselves. Sometimes, especially when we're learning, this is a good thing. Other times, we want to take the training wheels off.

What many of us want as developers is this:

string greeting = "Hello";
greeting += " World";

and/or

string hello1 = "Hello World";
string hello2 = hello1;
if ( hello1 == hello2 ) {
cout << "Praise Allah!" << endl;

This is on the same par of performance as character pointers and functions such as strcat(), but far safer and easier to understand. They are also (slightly) faster than the equivalent code in Java. And it is by no means non-standard or inherently harder to use. Is it immediately clear what is going on down to the bit? To me, yes. To a novice, perhaps not. But then, how many Java novices get by without knowing the garbage collection algorithms used by the JVM or whether most operations are O(log n) versus O(n)? Once again, use the right tool for the job, not the right job for the tool. Language favoritism should always be secondary.

> But then, if you really want faster code,
> you're better off twisting your 'OO design'
> just slightly so that you're left with mostly
> OO code with some procedural 'leafs' of your
> design

I whole-heartedly disagree that one must alter their design to fit a problem. If this is the case, many times it points to a deficiency in the design. Some of the more advanced features of C++ (what some might call the dark corners, but I happen to find them refreshing) keep you from having to resort to such measures much of the time. Many template operations (when used judiciously) can keep flexibility and code optimization alive without unduly sacrificing maintainability or clarity.

But of course, in the end, for that last little tweak, chances are the time you spent implementing those last few leafs in assembly would (in terms of money spent on salary) have more than paid for a more powerful server. Tune your algorithms, not your implementation. As compilers get better and choice of CPU becomes more diversified, the assembly tweak becomes less and less of an option. The law of diminishing returns still applies.

Woah! That was longer than I was expecting. I really need to concentrate more on my day job...

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
In other words (4.00 / 1) (#37)
by ucblockhead on Wed Jul 11, 2001 at 10:54:07 AM EST

It is slower than C++ and less flexible and complete than Smalltalk.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

My beginnings with the STL (4.50 / 2) (#25)
by zavyman on Tue Jul 10, 2001 at 06:46:48 PM EST

The class that I took in high school on c++ programming did not once hint at the existence of the STL. This was, in my opinion, the biggest mistake, since when you start using the advanced features of the language, you must "unlearn what you have learned" and do things over again.

That's what happened to me at least, when I started my first research job in computer science. The wealth of features and time savers in the STL is simply astounding, as I soon found out when I investigated it. The only problem is that I am working on MPI, whose c++ bindings are just a kludge to get support for c++. It was really designed for C and Fortran. As a consequence, I cannot pass iterators to the messaging functions in order to use vectors as the storage mechanism. Instead I have to design my own class now to act like the STL vector but provide the functionality to hook into MPI.

My reccomendation for programming teachers in high school (and intro college courses) is to drop hints of the full features of the STL to make life much easier on the students, should they pursue usage of the templates. This is one book that I'm definitely going to get to get a better understanding than I can just by looking at the reference.



They can't drop hints if they don't know about em (5.00 / 2) (#27)
by RangerBob on Tue Jul 10, 2001 at 09:28:45 PM EST

My experiences with a lot of CS professors and teachers is that not many of them actually try to stay current. When I went through college, most of the profs were years behind the standard. Today, when I talk to the students that work for me, I'm not seeing that things have gotten a whole lot better. At the local university, U Missouri - Rolla, I'd wager that not one professor there who teaches things in C++ has ever read through the standard. This causes problems as they don't teach the more advanced features because they don't know about them.

It's also surprising how many professors don't even know how to code good and efficient C++. They never teach about things like vtables and how tons of virtual functions can bite you performance-wise. I'm not actually sure that the professors are aware of it themselves. This bothers me because I feel that they have a responsibility to keep themselves informed so that they can keep their students current.

By far the biggest problem I've seen is that even if a professor knows about things like the STL, they still teach in the old school days of "You always have to write your own data structures". Yeah, it makes sense to make students code them themselves when they're in their first data structures class, it's silly to make them do it when they're seniors.

[ Parent ]
Teaching programming (none / 0) (#43)
by jasona42 on Wed Jul 11, 2001 at 05:47:56 PM EST

I noticed while I was in college that there weren't really any courses on learning languages. We had a required class on computer languages in general, but none to really teach a student the features of a particular language in any detail, let alone enough to do any kind of comparison for choosing the best language for a project. The other courses involving coding were focused on specific fields like databases, algorithms or artificial intelligence. I've always felt there should be some sort of class "Programming In The Real World" or something along those lines which teaches one how to be an effective programmer. We had several classes on software engineering with the goal of how to plan a project, yet many people graduate with a Computer Science degree that can't code their way out of a paper bag.

[ Parent ]
doh. (4.00 / 1) (#28)
by majcher on Tue Jul 10, 2001 at 11:19:53 PM EST

I initially misread the title of the article as "Effective FTL". My interest quickly waned once I realized that there would be no discussion of Faster-Than Light theory. Damn.
--
http://www.majcher.com/
Wrestling pigs since 1988!
Wow, me too (NT) (none / 0) (#55)
by jreilly on Sat Jul 14, 2001 at 01:07:22 AM EST



Oooh, shiny...
[ Parent ]
So this book is good? (none / 0) (#46)
by khallow on Thu Jul 12, 2001 at 12:30:47 AM EST

After reading the comments from people who actually have to code in C++ for a living, I get the impression that this book is good. Anybody have bad experiences with it? Also are there any good web-based references to STL? Thanks.

Web-based STL reference (5.00 / 2) (#51)
by hawkestein on Thu Jul 12, 2001 at 07:40:36 PM EST

SGI has the best web-based STL reference I've found (I believe they're official STL maintainers these days). http://www.sgi.com/tech/stl

[ Parent ]
Dunno (none / 0) (#54)
by ucblockhead on Fri Jul 13, 2001 at 07:41:35 PM EST

I'll let you know after I read it. His other two books are required reading for C++ programmers.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Publisher poll topic (5.00 / 1) (#49)
by ttfkam on Thu Jul 12, 2001 at 02:48:56 PM EST

And here I see the cause for so much fire and brimstone levelled at C++: the choice of publisher.

O'Reilly may in fact be my favorite publisher overall. The wide variety of topics they cover well is very impressive -- with some notable exceptions. Folks, run -- don't walk -- away from any of O'Reilly's C++ titles. I would venture that "Practical C++ Programming" has killed more C++ developers in the womb than any other book out there.

If you're gonna learn or talk about C++, you have to go Addison Wesley. No ifs ands or buts. O'Reilly is describing shadows on the back of the cave.

"SQL in Nutshell" blows chunks too...

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
Seconded (none / 0) (#53)
by Vulch on Fri Jul 13, 2001 at 10:49:12 AM EST

I would venture that "Practical C++ Programming" has killed more C++ developers in the womb than any other book out there.

I'll definitely second that. I'm now 6 months in to my first job involving C++ (Everything before has been ordinary C on various platforms) and was asked to buy and read a C++ book before the interview. Guess what I landed up buying? I got fed up with being told how I should be programming and decided to wing it in the interview. They still gave me the job.

In the mean time I've now read the two Effective C++ books, and Effective STL will be on the companies next book order.

[ Parent ]

Poll: Other(comment) (none / 0) (#50)
by Langley on Thu Jul 12, 2001 at 05:54:03 PM EST

Real men read books from the MIT Press. 'Nuff said. ;P



A Prohibition law strikes a blow at the very principles upon which our government was founded. -Abraham Lincoln (Sixteenth President of the United States of America)
Effective STL vs The C++ Standard Library (3.00 / 2) (#52)
by malikcoates on Fri Jul 13, 2001 at 10:32:02 AM EST

As a C++ programmer and an occaisonal STL programmer who is familiar with Meyers' previous work, I decided to pick this book up. I think that Meyers has written yet another must-have book for advanced C++ programmers.

I've seen posts wanting a comparision vs "The C++ Standard Library" by Josuttus. Effective STL is not written at the same level as The C++ Standard Library. Meyers references Josuttis frequently. Effective STL is an easy to read in-depth explaination of 50 do's and don't for STL programming complete with why's and wherefores. Its main value comes from Meyers ability to make difficult concepts crystal clear to the reader.

The target audience includes people who have a fair grasp of the STL and STL experts. It is not intended as a beginner or reference work.

STL made C++ programming tolerable for me (none / 0) (#57)
by fullcity on Thu Aug 09, 2001 at 10:21:55 AM EST

A general plug for the STL. I had been programming in C++ for several years, and never particularly liked it. I relished the opportunity to do little tasks in awk or ML, just to break the tedium.

The relevant distinction: awk has associative arrays. C++ lets you write a hash table from scratch.

When I started using STL, I realized that C++ finally felt like a real language. Before STL, one puts everything in vectors while rationalizing the efficiency loss in a linear search (and sweating over memory allocation). Now, we can keep a sorted collection or an associative collection with no extra work over putting the collection in a vector.

Also, memory errors pretty much went away for me, because I started putting many of my containers on the stack. (Of course, the collection is really still on the heap, but with good general-purpose containers, I tend to let the destructors do their thing, rather than putting in logic for calling delete[].)

So, fatigued C++ programmers, not looking forward to learning STL, take heart! It's actually pretty cool.


Today's roast: Panama Hartmann Songbird, very light roast

Book review: "Effective STL" | 57 comments (45 topical, 12 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!