Slashdot Log In
Bjarne Stroustrup Reveals All On C++
Posted by
CmdrTaco
on Wed Jun 25, 2008 08:37 AM
from the still-secrets-after-all-these-years dept.
from the still-secrets-after-all-these-years dept.
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."
Related Stories
Submission: A-Z of programming: C++ creator reveals all on C++ by Anonymous Coward
[+]
Technology: Interview Update With Bjarne Stroustrup On C++0x 589 comments
An anonymous reader writes "DevX interviewed Bjarne Stroustrup about C++0x, the new C++ standard that is due in 2009. Bjarne Stroustrup has classified the new features into three categories: Concurrency, Libraries and Language. The changes introduced in Concurrency makes C++ more standardized and easy to use on multi-core processors. It is good to see that some of the commonly used libraries are becoming standard (eg: unordered_maps and regex)."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Oh... my... god... (Score:3, Funny)
C++ is a woman?! I didn't see this coming.
Re:Oh... my... god... (Score:5, Funny)
It shouldn't be that surprising. The new operator should have given it away. After all, in C++ you can create objects (children) that consume resources and don't clean up their garbage. The secret to how it works is that C is a man.
Parent
Re:Oh... my... god... (Score:5, Funny)
C++'s social life is a bit weird as well: I hear that friends have access to your privates.
Parent
Normal Read (Score:5, Informative)
Re:Normal Read (Score:4, Funny)
You mean the cout version, noob!
Parent
Interesting Read (Score:5, Informative)
It's always cool to see this kind of interview. It's even cooler when you can read it all on one page [computerworld.com.au] 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!
Re:Interesting Read (Score:5, Funny)
Parent
Re:Interesting Read (Score:5, Funny)
Hey! I'm illiterate, you insensitive clod!
As are most c++ programmers.
Parent
Re:Interesting Read (Score:5, Interesting)
Parent
Re:Interesting Read (Score:4, Informative)
Early C++ "compilers" usually did more than just macro processing, but only just; most of them were implemented in terms of translating C++ to equivalent C code and then compiling the resulting C. Not so elegant, but it allowed compiler vendors to pick the low-hanging fruit and get something on the market ASAP.
It wasn't just commercial compilers, either. g++ worked that way.
Of course, it goes without saying that these early C++ compilers sucked hard.
c.
Parent
Re:Interesting Read (Score:4, Interesting)
> 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.
Parent
yawn (Score:4, Insightful)
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.
Re:yawn (Score:4, Funny)
Parent
Re:yawn (Score:4, Insightful)
Because a programmer is a car designer, assembler or a mechanic, depending on his specific job description. The user of the program is analogous to the driver of a car.
If you want to be a car mechanic, you'd better learn how cars work. If you want to be a programmer, you'd better learn how programs work. You'd think this would be bloody obvious, but oh well...
Parent
Re:yawn (Score:4, Insightful)
This is the problem with people who don't know how to appreciate C++ capabilities. Do you even know why a "virtual" declaration on a method may be useful, or what it does internally? The whole idea is that you write code that can call methods named in a base class but defined in a derivative (child), via pointers. So, if you want to keep your code clean, you just have one line like:
Parent *p = new Child();
and the rest of the "user" code stays the same. You change the one line above to change functionality of every virtual method.
Now since destructors are called implicitly most of the time, and since you OBVIOUSLY DECLARED VIRTUAL METHODS FOR A REASON, the compiler will warn you if the destructor is not virtual too, because then the object will be destructed as if it is a Parent object. It is a very valid warning, and will save you memory leaks(child objects contain more stuff to be freed..etc). It all makes sense now, see. The compiler is being nice, yes? Do you not agree that you should be blushing, after accusing the heavenly father Stroustrup of psychosis?
Advice for life in general: If you don't know how to use something, don't use it ;)
Parent
Re:yawn (Score:4, Informative)
Parent
everything programmers should know about C++? (Score:5, Funny)
in an 8 page interview? I feel like a sucker for buying the 900 page book [amazon.com]
Re: (Score:3, Funny)
Yeah, he is apparently very good at refactoring.
And ... (Score:4, Informative)
... for an equally partisan view from another perspective, the C++ FAQ [yosefk.com].
Re:And ... (Score:4, Insightful)
...it's largely a waste of time. The author spends an inordinate amount of time complaining that C++ prefers compile-time overhead to run-time overhead, and has no understanding that C++ is designed to have no unnecessary performance penalty relative to C. It would be nice if he did, as whatever insights the FQA author has concerning OO languages could be gleaned without wading through a few thousand lines of whining over the lack of things like garbage collection, heap compaction, run time bounds-checking, etc. He also has apparently never heard of Boost.
Parent
The FQA is "equally" partisan? (Score:5, Insightful)
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.
Parent
Favorite line... (Score:4, Funny)
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.
The Truth about C++ (Score:5, Funny)
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
Re:The Truth about C++ (Score:4, Interesting)
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.)
Parent
Re:The Truth about C++ (Score:5, Insightful)
Yawn.
If you don't like C++, you probably just don't understand it [emptycrate.com]. Yes, it's a complex language. However, if you use RAII (a fundamental tenant of C++) you will not. leak. memory. ever. Same arguments about C++ are used over and over again by people who don't grok the language. Is it the end-all be-all language? No. But it is darn good at what it does (performance minded system level code) with almost none of the problems C has (memory leaks and weak typing).
Parent
"What good progammers should think" (Score:3, Funny)
Language stability (Score:3, Interesting)
Re: (Score:3, Insightful)
Stoustrup probably means the binary still runs on the now antiquated system it was originally compiled for. I very much doubt he means that the 20 year old source code still compiles with a modern compiler, as the language has changed way too much. So, Stoustrup's probably being a little bit disingenuous as usual.
Non Geeks (Score:3, Interesting)
If you liked that, read "Design and Evolution"... (Score:3, Informative)
The interview just seems like a very brief sampling of "The Design and Evolution of C++ [amazon.com]".
Even if you do not care much about C++, it's an excellent look into the philosophy and thought that goes into language design.
Use this link to read article on one page (Score:5, Interesting)
First, read the printable version of the article on one page. [computerworld.com.au] 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.
Re:Use this link to read article on one page (Score:5, Informative)
The developer should know if he'll need the size of an array or not. Which is why there is a convenient std::vector and std::tr1::array for when you do want the size. Not forcing you to carry around a size is a feature, not a bug - if you don't need the size, it's just a waste of space.
And auto_ptr is likely to be depreciated in C++0x, with unique_ptr and shared_ptr replacing it.
Parent
Love C++, but it still sucks... (Score:5, Informative)
* 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
Re:Love C++, but it still sucks... (Score:5, Informative)
* Pragmas are made specifically for non-standard compiler extensions. There can be no "standard" pragmas.
* C++0x is adding support for UTF-8, UTF-16, and UTF-32 character types and literals.
* TR1 adds cstdint which includes int32_t etc. types.
* NaN and +Inf (not -Inf, though) can be had from std::numeric_limits
alas, if those are the first complaints you think of, you haven't been using C++ long enough to really know the painful bits.
Parent
Re:Love C++, but it still sucks... (Score:5, Informative)
Most of your complaints seem aimed at C and not C++. Let's see:
* No standardized pragmas
They standardized the extension mechanism. That sounds good for a start, but I don't see how you could go farther.
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
Also, short/int/long give you the sizes optimized for the specific processor, so you can use that if that's what you want. You can't really deprecate them because of that
I've never used them though.
For double:
#include <limits>
const double inf = std::numeric_limits<double>::infinity ();
const double minf = -std::numeric_limits<double>::infinity ();
const double nan = -std::numeric_limits<double>::signaling_NaN();
See more here [unc.edu] for example.
There are has_infinity() and related functions to check for a type's capabilities (say, in a template)
Parent
and worst of all... (Score:4, Interesting)
Parent
Re:Love C++, but it still sucks... (Score:4, Funny)
... +Inf, -Inf...
Everything has its limits, you know.
Parent
Sand-bagger (Score:4, Funny)
Bjarne Stroustrup Reveals All On C++
You mean... He's been holding back?
Want to know more? Read the book (Score:4, Insightful)
"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.
Anyone trying to defend C++ as a language (Score:4, Informative)
Anyone trying to defend C++ as a language should read this [yosefk.com]. 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.
C++ Debuggers (Score:4, Funny)
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...
Re:Humour (Score:4, Insightful)
The pun seems to be that KDE isn't structured, efficient, portable or serious, despite being written in C++. I can't blame you for missing it, or finding it not funny.
Parent
Re: (Score:3, Funny)
Inaccurate. You forgot COBOL. But that's understandable, I want to forget it, too.
Re:managed code (Score:4, Interesting)
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.
Parent
Re:useful but oh so flawed (Score:5, Insightful)
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.
Parent
Re:useful but oh so flawed (Score:4, Insightful)
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
Parent
Re:useful but oh so flawed (Score:4, Insightful)
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.
Parent
Re:Operator overloading... (Score:4, Interesting)
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.
Parent
Re:useful but oh so flawed (Score:4, Informative)
Parent
Re:useful but oh so flawed (Score:4, Insightful)
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.
Parent