Slashdot Mirror

That letter *completely* misses the point Linus was making.

* C _forces_ a programmer to _always_ be thinking about efficiency.

* C++ _allows_ programmers to be _sloppy_ and not even bother to _think_ about efficiency.

When you have idiots calling a virtual function inside an inner loop because they don't know how a virtual function is _implemented_ that is PRECISELY the type of programmer Linus says is a crap programmer because they have never learnt the 0th rule of programming: TINSTAAFL

There Is No Such Things As A Free Lunch

Yes, C can be tedious, but it encourages a certain mindset. The GREAT programmer is always thinking about the high level theory AND the low level implementation. That is a more _balanced_ programmer then one who doesn't understand how to write atoi() and itoa() (aka printf) which is the typical C++ programmer.

The STL is a great example of the "rebuttal" completely ignorant of real-world needs.

The API _design_ of the STL is great because it is orthogonal and consistent. However STL is total crap when you need to :

- debug a container
- serialize and unserialize it in a FAST and PORTABLE manner

Part of the problem is that C++ compilers are crap and put out verbose messages because they can't output a simple, short type alias.
When you have tools like "An STL Error Message Decryptor for C++" you know your language _design_ AND _implementation_ is FUCKED. Sadly the C++ community doesn't have the balls to be honest and admit their ego is out of control. "OK, We screwed up in certain areas of the language. How could we simply the grammar and language for people _using_ the language AND people _implementing_ the language?"
http://www.bdsoft.com/tools/stlfilt.html

_That_ is why Linus says STL is crap. Programmers start using C++ features without thinking about the _consequences_. A hard-core C programmer will go "OK, this looks like a great design -- where are the areas where it excels in, and where are the areas where it sucks in?" In C you are locked into someone else's bad design.

To prove my point: WHY do you think EA (Electronic Arts) invented their OWN version of STL for game programming? Because the standard C++ STL has several KEY DESIGN FLAWS. Ignoring them doesn't make it go away!
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

C++11 _finally_ got Move Semantics. Gee, we've only had to deal with _that_ problem for the past 20 years. Typical over-engineer design-by-committee C++ ignoring real-world (performance) problems.

In closing, there are 2 points I'd like to make:

The *best* programmer is one who balances the simplicity of C with the features of C++; on that I agree that Linus is incorrect. Sadly you can't disable all the crap in C++. Linus' only _pragmatic_ solution was to ban the language outright. His project, his call.

and

The author(s) of the rebuttal need to put up or shut up -- when they have shipped their own kernel THEN they will have earned the right to disagree with Linus.

Hope this provides a little more insight into why C and C++ both suck. ;-/

...C++'s STL may introduce new problems, but it sure as hell fixes a metric ton of them in the process.

Other than the minor detail of using the term "STL", I agree completely. Actually, I'm a bit surprised that nobody mentioned the problem that I think is most annoying: the fact that a truly trivial error can result in an error message that's three pages long and nearly impossible to decipher. Leor Zolman's stlfilt can help, but it's hardly a panacea. (And yes, if there are any other old farts like me reading, this is the same Leor Zolman who wrote BDS C, back before the continents separated and such...)

In case anybody cares: I object to "STL" on the grounds that it's extremely ambiguous -- some people use it to refer to the entire STandard Library, others to refer to a library written years ago by Alex Stepanov, still others to a library currently maintained by SGI based on Alex Stepanov's library, and still others to those portions of the current C++ standard library closely based on Alex Stepanov's library (usually with a rather poorly defined boundary). Still others seem to use the term to refer to all code that uses templates. While ambiguity in English is hardly new or unique, this situation seems worse than usual to me -- enough to warrant avoiding the term altogether.

Use STLFilt.

> Also Perl prgrammers tend to put more than one statment on a line by convention.

Show me one module in CPAN coded like this.

And frankly if you think perl is unreadable, you havent worked with C++ templates that much. This is a language that requires just to start making sense of its compiler errors.

You're thinking of this.
I haven't used them myself, but then again, GCC 3.2.x's STL error messages are generally quite good. Not EDG quality, but pretty good. Certainly not as bad as the Visual Studio 6 crap that seems to have scared many people away from advanced C++.

We also use STLport on all platforms. Its debugging implementations answer one of the complaints I've seen on this topic -- difficulty debugging.

For the other one (cryptic error messages), I cannot recommend STLFilt enough. This is a Perl script that intercepts the output from cl.exe (in visual studio . . . not sure why no one has adapted this to gcc yet) that reduces the complexity of STL error messages to a manageable level.

http://www.bdsoft.com/tools/stlfilt.html
Works pretty well, available for lots of compilers!
The above example boils down to:

BD Software STL Message Decryptor Release .99 for g++ (4/11/2002)
readply.cpp(109): conversion from `iter' to non-scalar type `list' requested

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

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

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

Aside from the debugging nightmare (much improved by tools such as STLFilt, BTW) and the portability issues, IMHO the biggest problem with the STL at present is the lack of glue to take best advantage of it.

For example, there is auto_ptr but that's incompatible with the standard library container classes. Instead you need to head for something like Boost to plug the gaps.

Similarly, you have all these fabulous algorithms that take optional predicates, but then you start writing rubbish about binders and less<int> to get them to do anything useful. Again, the answer is perfectly possible (check out the various expression template libraries in circulation), but relies on a good level of template support in C++ and isn't (yet) standard.

Fortunately, the next version of the C++ standard should address these shortcomings and plug the gaps, at which point the C++ STL implementation will become one of the most fabulous libraries in existence.

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

www.bdsoft.com/tools/stlfilt.html

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

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

But the real bear is the compilation error messages, which can be pages long, and ultimately completely unreadable.

There are a handful of utilities that are designed to "translate" these types of error messages, and produce something human-readable (or at least developer-readable.)

I suspect that compiler writers will eventually start using these same sort of techniques to present usable error messages for STL constructs. Hmm... might actually be interesting to do this for GCC.