Slashdot Mirror
Bjarne Stroustrup Reveals All On C++
An anonymous reader writes "Bjarne Stroustrup, the creative force behind one of the most widely used and successful programming languages — C++ — is featured in an in-depth 8-page interview where he reveals everything programmers and software engineers should know about C++; its history, what it was intended to do, where it is at now, and of course what all good code-writers should think about when using the language he created."
I was kind of interested in the comment that C++ required a proper compiler rather than just a pre-processor macro package. From the fog of my memory I remember many of the early commercial C++ offerings being mostly a pre-processor package, were those really just C with Classes compilers rather than true C++ ones?
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
What a wonderful bit of fiction. I did find it entertaining, so thank you.
I have worked with some very good programmers, and some mediocre ones. The very good ones usually liked C++, and often preferred it when given a choice. The younger (good) ones tend to go with C# these days, though they don't bad-mouth C++.
It is always the mediocre ones who badmouth C++.
That has just been my experience, I don't know if this is true across the board, but I do encounter this a lot. Average and below-average programmers hate C++ with a passion, whereas the really good ones like it (or at least respect it).
First, read the printable version of the article on one page. The original version is one paragraph per page, surrounded by ads and related dreck.
There's really nothing new there. It's the usual Strostrup stuff. He's still in denial about C++ being the cause of most of the buffer overflows, system crashes, and security holes in the world.
The fundamental problem with C was the "array=pointer" concept. If array sizes were carried along with arrays, we'd have far less trouble. Even FORTRAN has conformant array parameters. That should have been fixed in C++, but it wasn't, and as a result, we had two more decades of buffer overflow problems. This isn't a performance issue, by the way; Modula 3 got it right, but Modula 3 disappeared for non-technical reasons - Compaq bought DEC and closed down the software R&D operation.
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.
Yes, some of these problems can be papered over with templates. The C++ committee is full of templateheads, focused on template features that few will use and fewer will use correctly and productively. That crowd is still struggling to make auto_ptr work.
Nice. If you don't like C++, it must be because you're a bad programmer.
It's much harder to write C++ code that, for example, will never leak memory no matter what goes wrong than in the assorted garbage collected languages, or even vanilla C. That, I don't see how anyone could even reasonably argue.
C++ was an important step on the way to better languages (for the problems it was trying to solve -- not for everything), but that doesn't mean that given today's alternatives it should be considered good.
Being a good programmer is about being good at solving the problem at hand in a clean, maintainable way. It's not about being able to memorize the weird inconsistencies in a language or fight a better fight with a difficult language. Even for a project that has to be done close to the machine, you'll almost always get in less trouble using C. (Or, if you must, using C++ but generally ignoring the C++ features.)
And I suppose your shop used to say "COM only", and now says "ugh, COM, who'd want to code those things up". You seem to have swallowed the Microsoft marketing man's sales spiel wholesale.
When you find out how slow some parts of .NET is (eg DB access), or how much memory it uses when you don't want it to, or how to find the object you expected to be GCd but hasn't been.. then you'll think about writing a chunk of your code in old C++.
MS did do a lot of work (pretty poor IMHO though) with C++/CLI to get some interop going between C++ and C#/VB. Poor because of the somewhat contrived bodges to the language they put in that they could have hidden behind the compiler, and also because there isn't any real interop with old unmanaged C++ except by wrapping it with a managed dll (or recompiling with the /clr flag set). Its also a poor implementation - eg STL/CLR is a lot slower than the .NET containers surprisingly.
25 years later there's still not a !@#^%^&$ single compiler that implements the entire language correctly. We're all waiting for Godot...
"Not an actor, but he plays one on TV."
> Aren't you just a bit biased?
If you're gonna be pedantic, it's a lower-case 'c'.
But I'll freely admit to being biased. I've spent my time in the C++ trenches. C isn't a terribly good language, but when you shoot yourself in the foot it's usually a clean wound.
c.
Log in or piss off.
The people using C++ for engineering, mathematical, and scientific applications may be a minority, but not a tiny minority. No one has to deal with operator overloading if it is not applicable to their application. If a developer is too immature to recognize when a feature is a bad choice, then operator overloading is the least of his problems.