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."
C++ is a woman?! I didn't see this coming.
Print Version of the same article http://www.computerworld.com.au/index.php/id;408408016;fp;16;fpid;1;pf;1
It's always cool to see this kind of interview. It's even cooler when you can read it all on one page rather than 8.
I suggest that anyone who uses C++ or is interested in the history of programming read this. Some of it is a bit banal, like how they chose the name, but some of it is really intersting. RTFA for once, you lazy clods!
(C'mon KDE guys, it's funny. Laugh.)
My blog
C++ is a language of a million gotchas. The moment I start having to think about implementation detail and I'm not writing an operating system or compiler, I know I'm using the wrong language.
in an 8 page interview? I feel like a sucker for buying the 900 page book
More music, fewer hits
... for an equally partisan view from another perspective, the C++ FAQ.
programs in C++ could be simultaneously elegant ... and efficient for systems programming... Obviously, not every program can be both and many are neither
Many are neither. Ain't that the truth.
Best Slashdot Co
FTA they tried calling it C with Classes, but that didn't stick, so they asked for suggestions and got C++
I think they should have called it Class-C. Much more fun to pronounce.
On the 1st of January, 1998, Bjarne Stroustrup gave an interview to the IEEE's Computer magazine.
Naturally, the editors thought he would be giving a retrospective view of seven years of object-oriented design, using the language he created.
By the end of the interview, the interviewer got more than he had bargained for and, subsequently, the editor decided to suppress its contents, for the good of the industry, but, as with many of these things, there was a leak.
Here is a complete transcript of what was was said,unedited, and unrehearsed, so it isn't as neat as planned interviews.
You will find it interesting...
Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem.
Interviewer: problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty.
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen.
Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better.
Stroustrup: Exactly. Well, the same happened with 'C' programmers.
Interviewer: I see, but what's the point?
Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.
[NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)]
Interviewer: You're kidding...?
Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that's what I used to do.
Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.
Interviewer: I don't believe you said that...
Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would.
Interviewer: So how exactly did you do it?
Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.
Interviewer: What?
Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code?
Interviewer: Well, never, actually, but...
Stroustrup: There you are then. Mind you, a few tried, in the early days. There was this Oregon company - Mentor Graphics, I think they were called - re
Inaccurate. You forgot COBOL. But that's understandable, I want to forget it, too.
Extreme Programming - Redundant Array of Inexpensive Developers
The interview just seems like a very brief sampling of "The Design and Evolution of C++".
Even if you do not care much about C++, it's an excellent look into the philosophy and thought that goes into language design.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
* No standardized pragmas
* Macros after-thought and not type safe
* No 24, and 32 bit (unicode) chars
* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
* No distinction between typedefs and aliases
* Inconsistent left-to-right declarations
* Compilers still limited to ASCII source
* No binary constant prefix (even octal has one?!)
* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time
If the messages are the same, no one has any reason to see both, so scoring one out of the default view is the Right Thing. If you're pathetic enough to care about karma and this happens so often that it even matters, complain to the admins that the author of a redundant comment hasn't done anything wrong.
And in fact, Cfront was a compiler, not just a preprocessor; it was just a compiler that compiled C++ into C.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Bjarne Stroustrup Reveals All On C++
You mean... He's been holding back?
If you do what you always did, you get what you always got.
I'm afraid that web site is one of those things that gets way too much attention in some on-line communities because of its controversial nature.
The reason the two sides are far from equally partisan is that Stroustrup freely admits there is another side to the debate and that C++ has its flaws, and he is making efforts to improve the situation. The FQA, on the other hand, just makes blanket statements like "For example, the lack of garbage collection makes C++ exceptions and operator overloading inherently defective", which simply isn't true (and neither are many of the statements made in the FQA under those particular headings).
If you read the comments the guy who wrote the FQA makes on forums like reddit, as well as throughout the FQA itself, it's pretty obvious that unlike Stroustrup, he has little interest in any balanced discussion on the subject. He's just out to prove the other side wrong — where "wrong" often means "not agreeing with him" — and perhaps, the cynic in me suspects, to make a reputation for himself in the process.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"The Design and Evolution of C++" by Stroustrup is a must-read if you are interested in why C++ is the way it is.
After reading it, I really hated C++. It's the classic example of a project that gets ruined by too many people working on it, all with their own goals, and the book tells you exactly why this happened. C++ now is a hideously complex monstrosity that is popular because it is all things to all people, not because it is a good language.
Anyway, if you disagree with me, have a look at the book. It is a testament to Stroustrup's objectivity that I came to the conclusion I did, and that you may come to the exact opposite conclusion as me after reading it.
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."
Back that statement up, buddy.
Well, there's no doubt in my mind that C++ is a language design tour de force. The question is whether its design objectives are the right ones.
They were probably the right objectives for the place (Bell Labs) and time (1979) it was conceived.
At the time, computers were inconceivably slow by today's standards. I worked at a small developer that had a very nice AT&T 3B2-400, which had a WE32000 microprocessor, which probably ran at about 10-15MHz; a half dozen programmers shared it.
As for the place, well, it was crawling with C programmers and C libraries, doing rather complex and important systems programming. Compatibility with C and proven C libraries would have been a huge thing.
So, an efficient, object oriented version of C was probably exactly what was needed.
I think that if there was any fault, it was the attempt to meet the goals of efficiency and compatibility with a language that implemented everything that (at the time was thought to be) necessary for programming in an object oriented style. Multiple inheritance carries too much baggage when all you want to do is to guarantee objects have a certain interface. Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion. In situations where you need a special purpose language, it's probably better just to create one.
Still, that's hindsight. If you really understand all the things Stroustrup was trying to do, C++ is quite awe inspiring.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion.
.add(), .subtract(), .multiply(), etc. Once I transliterated a piece of C++ code I had wrote for him and it consumed three times the space and was much less readable due to the nesting of the member functions... being able to use natural math symbols and natural parenthesis makes the math so much more readable, and when 90% of your code is math, you come to appreciate it. I wouldn't have it any other way, at this point.
I write math codes for fun and for a living. I have this discussion on an infrequent basis with a Java buddy of mine. Now granted I'm a dumb mechanical engineer and he's a smart CS major, but when I need some custom math classes that aren't provided by the language (tensors, vectors, Jacobians, Quaternions, etc.) and evaluating long math expressions, it is so much easier to view it using the native math symbols than to nest it all in member functions
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...
Anyone trying to defend C++ as a language should read this. And I speak as a programmer who has used C++ since cfront 1.0 was released to the world.
Useful, yes. Pragmatic, maybe. Design heavily rationalized ex post facto by its creator and its proponents, most certainly. But a well-designed programming language, it is not.
That is all.
On the other hand, that's not the only natural way to handle the situation you are talking about. Another way is to create a new language. Altogether, I'd rather do the kind of work you're talking about in Matlab or Octave.
I write code for clusters, now specifically CFD. Lots of math, lots of parallel processing. Matlab and Octave isn't gonna cut it, and you really desire the close to the metal aspects of c++.
It may be a narrow range, but there's a lot of people in this narrow range. Specifically, (mechanical/aerospace/etc.) engineers. C++ isn't sexy like Java or Python, but we do a lot of things you just can't do in Python, and can't do fast in Java.
Good book, but I don't see how some minor nuances translate to insurmountable design flaws. It's true that proper use of C++ requires a level of expertise beyond what's required for many other languages. IMHO, that just makes real C++ programmers more valuable.
Basically when you have rules you ought to (or "must" unless you want magical bugs) follow that are not enforced by the compiler, the language is flawed. Like when you oveload new but not delete and thus have incompatible memory management. Or you return a reference to a method-local (auto) string object.
It does however give rise to a market for code analysis tools that checks all the stuff the compiler will let you get away with.
But you can save the cost of these tools (or the alternative manual hunt for bugs) by using more modern and productive languages like Java or Ruby, leaving C++ for operating systems and games. And the latter is moving into other lanbguages as well, i.e. Microsofts push for C# in game development, and the widespread use of Python in e.g. EVE Online, ToonTown, Civ IV and other games.
If 90% of your code is math, how about Lisp or Fortran?
Of course that might depend on what the 10% is.
Hex is close enough and less error-prone
When you're actually bitmasking, it's nice to see the bits rather than having to accumulate them in your head.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
His answer was along the lines of: "Oh, I never use a debugger. If something's not working right I just think about it...maybe I'll add a printf once in a while if I need to check something."
Now you know why utterly un-debuggable features like templates went into the language...
Here is a real eye opener: Bjarne Stroustrup cited the JSF coding standard as an example of C++ usage: "Also, embedded systems programming is a major area of use and growth of C++; for example, the software for the next generation US fighter planes are in C++ (see the JSF++ coding rules on my home pages)." http://www.computerworld.com.au/index.php/id;408408016;pp;5;fp;16;fpid;1
I particular like the following statement in the JSF++ coding rules that the creator of C++ holds up as an example of how to use C++:
AV Rule 208 C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
Rationale: Tool support is not adequate at this time.
the bloke was complaining about function nesting and you suggested Lisp?
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.
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.
I on the other hand used about 10% of the features and had a wonderful time using a subset that probably was actually just "c with classes". I used c++ as a better c compiler with warnings turned up all the way. I found classes an elegant way of encapsulating code that dealt with hardware. Concrete classes were my favorite. My c++ programs were straightforward and easy to read. I am thankful that BS wrote the language. It was a lot of fun. I never really needed more than I learned in the first month. Strong type checking kept me out of trouble. I actually spent very little time subclassing and enjoyed the luxury of keeping my prime classes functional. Modeling hardware as c++ objects was the most fun I had in programming ever. When done right, the code was as compact and maintainable as any I have written in any other language. Unfortunately I got very little follow-on work because the functionality of my code was obvious. Vendors like Microsoft and Borland just couldn't wait to use polymorphism to create frameworks. I hated frameworks because they were these huge collections of c++ complexity that had to be studied endlessly, and about the time you knew enough, the vendor brought out a new version. MFC is a prime example of a piece of code I just couldn't get my head around. It seemed to me that the point of all the frameworks was to make hello.cpp in 100 lines or less, but anything non-trivial got huge quickly.
I suspect that there are other people out there that felt like I did about c++. At least I hope there are. Every time I encountered a project where the legacy code used every feature of c++, my spirits took a dump. C++ was a tool that consultants often used to make themselves indispensable. Some of the code I encountered, like the bio-rad application was a good thesis, but a lousy piece of intellectual property. Twenty levels of nested classes, heavily subclassed made for a long research project every time you needed to track down a bug.
The secret of c++ for me was knowing just how much to use to leverage off the power of it's object orientation. Encapsulation was good, Inheritance was ok sometimes. Multiple inheritance was almost never a good thing, and polymorphism usually lead to spaghetti code. IMHO
I also like to remind that generics as now widely used in languages such as Java and C# initially started as templates in C++, only the latter has far better support.
For those who think that garbage collection is the holy grail against leaks in a program, think again. While it may solve memory leaks, it doesn't solve resource leaks (like open connections, file locks,
If you want to know more, I'm always in for a discussion on the subject. Happy to inform.
And what if there's nothing behind the door until it is being opened?