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.
Extreme Programming - Redundant Array of Inexpensive Developers
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."
"that's no longer possible."
Remember... This is Slashdot. Comments like these may have unintended consequences when made here.
It's, of course, possible to build a CFront-like preprocessor that converts current C++ code into C. It's not easy and the C code would probably be even less readable than what CFront wrote. It's not practical either. Or wise.
But it's certainly possible.
http://www.dieblinkenlights.com
> 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.
If you're thinking along the lines of a bunch of #defines making C into proto-C++ then you're completely wrong.
The early compilers produced C as a sort of "assembly language" so that it could be used on many different targets (C was widely available).
But it you looked at the C it produced you'd have a hard time relating it to the original C++ source code.
No sig today...
If 90% of your code is math, how about Lisp or Fortran?
Of course that might depend on what the 10% is.
It's the real reason that D hasn't taken off yet. Well, that and the fact that it has 90+ (!) keywords. The guys at digital mars are doing what Sun tried to do with java; it's ours, ours, and ours alone ! Yes, there is a spec, and yes you can build compilers, but wait - not so fast. You have to let us test your stuff, or you can't call it D. And maybe pay us a little. Or at least remember us in any code that you write.
.
Whenever I go to digital mars' website, I'm reminded of my Corba days and that institution - I forget what it's called - that was in charge of it. People should be well reminded that the days of commercial languages are over. Even Microsoft won't try it anymore. That should say something.
Religion is what happens when nature strikes and groupthink goes wrong.
Brian Kernhighan also admitted in an interview
that he only used a debugger to get a stack trace.
http://www.cs.cmu.edu/~mihaib/kernighan-interview/
About C: you think it is easier to manage memory with C char* and arrays than with C++ string,vector,and exceptions + resource-acquisition-is-initialization paradigms? I can only call that an outlandish claim! Hell even auto_ptr helps (I use it to express ownership transfers in function parameters and return values), and in C++0x they will finally have a real smart pointer standardized too. If you use raw arrays in C++ and get buffer overflows, don't blame stroustroup.
About garbage collected languages: true, memory management is not your problem anymore, which makes coding a bit easier (although there are other resources than memory which must still be managed manually). The problem is performance and, specifically, memory usage. My memory-leaking C++ implementation may well use half as much memory at any given time as your non-leaking GC code. Despite what people think, computers do not have over-abundant performance for all relevant tasks. I myself wrote 2 pieces of code in C++ just in the first months of this year where I knew from the start performance would be a problem. In one case because of the sheer size of the data I was handling, in the other because I knew the problem was NP-Complete. The first one would have simply page thrashed me to death in a GC environment.
The problem is that GC is viral, in the sense that if I link my non-GC code to a single library written to run in a GC environment, GC needs to be enabled for the entire program. This is the difficulty of adding GC as an optional feature to C++. Making it mandatory is not an option for performance reasons. In a GC environment you have little in the way of guarantees that memory will be freed right away, and this will occasionally come back to bite you hard when your application slows to a crawl as it runs out of memory. GC may be fine 98% of the time, the problem is if the language uses GC, you just can't turn it off locally where the memory usage is really hurting you.
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.