An Interview With C++ Creator Bjarne Stroustrup

DevTool writes "Bjarne Stroustrup talks about the imminent C++0x standard and the forthcoming features it brings, the difficulties of standardizing programming languages in general, the calculated risks that the standards committee can afford to take with new features, and even his own New Year's resolutions."

Re:Too little and too much, way too late

[Anonymous Coward]

Not that I disagree with your feelings but QT is a major C++ magnet -- of course you could argue that QT is a language on its own, not really C++.

Re:Is C++ ever the right tool for the job?

[EsbenMoseHansen]

I tried to use ruby for a while, but ended up back with C++. I couldn't live without static typing, as it turned out, and also C++ had more libraries leading to faster development (for me, at least).

C++ is the worst language, excepting every other language I have tried. And I am happy about the new features, they should make coding much nicer.

yeah, void* was destroyed

[r00t]

Early C++ introduced void* and it was good. C adopted it.

Then C++ took away the automatic casting, I guess about the time C++ was first standardized. OK, now what is the point? The value of void* is gone. Now we write code with nasty casts. We can even hide the nasty casts in macros. Oh joy.

C remains fairly sane. There haven't been any serious fuckups since the trigraph disaster which no compiler enables by default. C99 is damn nice in fact.

Re:Too little and too much, way too late

[mswhippingboy]

There's still a market for low level C programmers, and for Java, C#, Perl, Python, VB, and just about everything else, but who uses C++ these days? Games developers, a few corporate app maintainers and... uh... hang on...

Not sure if you're being facetious or not here, but C++ is consistently in the top 3 languages (the others being C and Java) in terms of popularity and usage. It's well above PHP, C#, Perl, Python, VB, Obj-C, and so on. I realize that stats from Tiobe index, Sourceforge, Langpop and other sources are merely an educated guess as to what people are really using, but the fact that nearly all agree on these three languages as being the top contenders seems to add credibility to their accuracy. It certainly beats the opinion of some individuals who are biased toward their favorite (or least favorite) languages.

kept alive by beardy wierdies and a few caffeine soaked kids who'll burn out and end up writing SQL for banks in a couple of years

Hey wait a minute! I resemble that remark!

Re:Is C++ ever the right tool for the job?

[Anonymous Coward]

No offense but you have to be stupid to not know what + does. If it does something unexpected, chances are you wrote it incorrectly yourself, or are using a terrible library that has undocumented operators that are working incorrectly on top of that. It's not the languages fault when programmers code like retards.

Re:Interview

[Prune]

I wrote C for about 5 years and then switched to C++ with which I've stuck for the last dozen years. With that perspective, the article you linked to is such a lousy attempt at humor that it made me cringe. C++ has, like many other large entities with significant history, become a bit messy due to the need for legacy support given its huge installed base. This does not mean that you cannot write neat programs with it! It's easy to blame the language instead of the software developer. It is just a matter of a bit of attention and discipline to do great stuff with C++ even while using what some may refer to its more esoteric features like template metaprogramming etc. I could never give up things like multiple inheritance, which may require a bit of care during usage, but I've found to be the way to go in many situations. The majority of the C++0x additions are very welcome as well. What's really needed is a completely modern reference text that minimizes time spent on legacy issues. It's basically the same situation with OpenGL, which has become much larger in the 3.x and 4.x versions, while still supporting all the legacy code--and there is no proper reference so one usually sees a messy mix of 2.x and 3/4.x in most current projects, rather than a clean, organized design following the most recent variant. A proper text (other than the standards document itself) would make a huge difference.

Re:Make it stop.....

[lgw]

Well, variable declared at the top of the function are the least evil c-ism. The real problem is a lack of understanding of RAII, and a fear of exceptions. The last time I read Googles C++ coding standards I died a little inside. People just don't "get" C++ for some reason.

Re:Is C++ ever the right tool for the job?

[derGoldstein]

That's simply the fault of the way (or order) that CS is taught (at some places). Using C++ shouldn't have stopped you from learning about registers, memory blocks, and simply digital logic along with micro-architectures. Did you expect C++ to teach you CS, or expect not to need to learn CS if you used it? You're blaming C++ for a separate problem.

Re:Is C++ ever the right tool for the job?

[EvanED]

So you have to be paranoid and check the class definition just in case.

So I have two responses to your general comment, though they are related.

You don't need to check the class definition at all -- you just need to know that one of the operands is an object. That's all. IMO, that's the only* difference between an overloaded operator call and a normal function call.

Once you're at that point, I don't see any difference between calling the function "+" and calling the function "doSomethingSimple". If you're paranoid enough about the class defining "+" in a way that will cause it to open sockets and thus you have to check the class definition to see if it does, you should be equally paranoid that "doSomethingSimple" will do the same thing and you have to check the class definition anyway.

The second part of my response is this: why do you CARE what "+" does internally? I can think of two reasons.

First, because you're concerned about efficiency. I've already said why I think this is a red herring, especially because I suspect most overloaded operator functions will be inlined to something efficient in general other way.

The second reason is because you want to know whether "+" is a good name for that function. But again I don't see how this differs from normal functions. If I call a function add and write a.add(b) instead of a + b, why are you more suspicious about the latter? I can come up with bad names without operator overloading plenty easily enough. Hell, I come up with bad function names for my non-overloaded functions far more often than bad function "names" for my operators. (And that even neglects the personal opinion that the normal convention of a.add(b) for a + b -- e.g. like what's used in Java's complex class -- feels wrong to me. a.add(b) feels way more like a += b than a + b to me. But again -- this isn't the fault of Java not supporting operator overloading per se, but rather the fault of Sun's function naming.)

* Okay, there is one other difference. Operator overloading is cool and tempting to use. It invites abuse way more than function naming does. But some high-profile cases aside (in particular, the proposal to overload the comma operator or whatever it was to load containers, a la Vector v = 4, 5, 6, 7, 8; or something), it certainly seems to me that, in practice, programmers are actually able to hold their tongues pretty well. Strangely enough, the biggest exception to this, I feel, is the bitshift overloading in iostreams. And IMO, that's easy enough to learn and brings about enough benefits (I/O type safety, non-repetition of type information, and extensibility vs a printf-style interface, and way less syntactic overhead vs repeated function calls) that it's probably the best solution even though it's not entirely satisfactory.

C++: a good academic exercise. Not much else

[Anonymous Coward]

A few years ago, I was invited to a musical performance. It was performed by a lady I knew who was completing her PhD in musical performance. She was hoping to round up people to attend the performance. I, along with about 4-5 others went as a group, and in a hall that can hold about 350, there were 20 or so in total. There were three people at the front -her teachers- grading her performance. The pieces were quite.... longhair. One was immensely atonal. It seemed to be a mere exercise in accurately hitting notes at one end of the piano keyboard, then at the other end, and then back and fourth a few dozen times. It did not sound like music in any traditional sense of the word. Why am I talking about this when the Slashdot piece is about C++? C++ is a good academic exercise. It provides nothing else. C, is a great, all purpose, fully functional, Turing complete language (full stop). It didn't need anything major added to it. It was and is fine. A few cleanups here and there, a few cases where things could be done a bit better, but its expressive, logical and elegant. So then we have C++. Elegance is gone. Out the window. We traded clarity, for obscurity. And what did we trade it for? What? Well now thats the big question, isn't it? What exactly did we get? Overblown? Overhyped? What real good functionality do we get, that we did not have before? Is there anything useful in C++ that did not exist in C? NO, thats the whole point. We were fine with C. C is complete. Its a bit like the movie Highlander. It was fine on its own, but then Highlander 2 comes along. OH MY THE DISAPPOINTMENT! What a failed exercise! What a waste of time and effort! I've heard people making arguments for C++ for a long time. They fail. Elegance, simplicity, beauty were replaced by something matching Cobol in verbosity, and binary in readability. Oh, we are told, you just need to examine a few thousand classes to understand... and thats where it fails in elegance. Like its object oriented, overloaded, overblown brethren, it hypes it virtues, fails on those, and ruins what was elegant. This truly isn't anything about zeal, this is the practicality of the language itself. Its an academic exercise, best left in academia. It provides nothing useful that hasn't been done better elsewhere.

Re:Is C++ ever the right tool for the job?

[firewrought]

If you don't like $FEATURE then don't use it.

I always cringe when I see this statement in a discussion about programming languages. The presence or absence of a particular feature will impact the third-party libraries you use, the code samples and tutorials you come across, and the legacy apps you inherit. Even if you develop in a vacuum, some features can impact you by accident [operator overloading isn't a good example, but implict-conversion-of-numeric-types-to-boolean is].

In $FEATURE desirable or not for a particular programming language? Most always, that's going to be a complex usability/design question answerable by some combination of analysis, research, experience, testing, etc. Read the programming languages weblog [lambda-the-ultimate.org] or the discussion forums for D, Haskell, etc., to see the level of thought that goes into make these tradeoffs.