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."

C++0when?

[fishexe]

Of course by this point it really should be called the imminent C++1x standard.

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

[godrik]

I aggree that people tend to do too many things in C++ (me first). However, there are quite some place where C++ should be used. Mainly gaming engines and high performance computing. You NEED low level programming to deal with that. They could be written in C. But numerous C++ programming techniques (mainly template mechanism) makes it much easier to program. You could not get reusable algorithm accross multiple data type with efficient compile-time type checking at no runtime cost without templates. You could do it with macros but you will have terrible compilation problem if you screw up. Or you could use inheritance but will pay the cost at runtime.

Re:Too little and too much, way too late

[JBMcB]

> Games developers, a few corporate app maintainers and...

Most Mozilla project applications including Firefox.. Pretty much all of KDE and some of GNOME. WebKit. Google Chrome. Opera. A good chunk of OpenOffice. Most Adobe applications. Most Microsoft desktop applications including Internet Explorer. CUPS. The Qt toolkit and pretty much everything that uses it. MySQL. Autodesk Maya. Winamp.

I wouldn't say a *few* corporate apps are written in C++, I'd say pretty much every major desktop app that's undergone a major re-write within the last two decades is probably C++.

Re:Could they not have named it something sensible

[Korin43]

Because it's still just C++. C++0x is just one particular version, like C++98 or C++03. Java 1.6.23 doesn't exactly roll off the tongue either.

Re:Too little and too much, way too late

[derGoldstein]

Let's ask Bjarne the same question: List of C++ Applications [att.com]
Chop off half of the software applications on that list, at random -- can you still use your computer now? How about the internet?

Re:Multi-processor Extensions

[lgw]

The std::thread and std::async libraries should give you all the tools you need in a plaform-independent way. The popular compiler vendors seem to be eager for C++0x - once the standard is official, Visual Studio will do a patch, and I'm sure G++ will beat them to release. Many of the C++0x features are already there with the -std=gnu++0x option to G++, though I'm not sure if that includes the threading stuff.

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

[mswhippingboy]

It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.

IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.

( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 [slashdot.org] . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )

I disagree on several points. C is great for low level programming, but many times you want to use OO rather than procedural programming. C++ allows you to do exactly the same low level programming you can do in C (including inline-assembler if needed), but also offers the ability to design in OO. I can't think of a good reason not to use C++ rather than C unless it is a simple monolithic (preferably small) project. Mixing languages brings a whole other set of headaches (including staffing issues). Ruby, Python or other languages are fine and have their place, but I can't imagine using them for systems level programming anymore than I would use C++ to build a web application. Languages like Python, Ruby, (errr.. LISP? - there is considerable debate over whether LISP is even a true "programming language" but rather an alternate implementation of a Turing machine, but I digress) are orders of a magnitude too slow to be used as systems programming languages.

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

[EvanED]

I used to be a huge C++ fan, though that has waned over the years as I've used better-designed languages and have also seen other people struggle with C++'s testier features.

That said -- I'd still take C++ over plain C for essentially anything in a heartbeat. (Basically the only exception would be stuff like microcontroller programming or other environments where there isn't really a good C++ compiler.) RAII alone is enough to seal that deal.

I don't buy most of the arguments of C over C++. For instance, take your statement that "IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules."

But with modern compilers, I feel it's already very not obvious what the compiler is going to do with your code. What function calls are inlined? What loops are unrolled? For what I think is a reasonably dramatic example of this, take the following snippet:

int main(int argc, char** argv) {
    int y = 50;
    if (argc > 1) {
        y = 100;
    }
    return y;
}

and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)

If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.

In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.

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

[Spykk]

If you don't like operator overloading then don't use it. I don't see how that has any effect on C++'s usefulness as a low level language. C++ can use inline assembly the same way C can. C++ has all the power of C with the convenience of classes.

There is no mandate that you must use templates or operator overloading in C++. If you are going to complain that it gives you the option then why aren't you complaining about C having goto?

In my experience when someone wants to use C over C++ for a new project it is generally because they don't know C++.

Re:Too little and too much, way too late

[shutdown -p now]

That there is a code generator there is really an implementation detail. From programmer's point of view, signals and slots are really just a language extension, and could as well be implemented by the compiler directly.

Re:Linking

[shutdown -p now]

It can't be standardized in the language spec itself, because there's no notion of "object files" or even "linking" in general in the spec - it's not tied to a particular implementation technique. That's why you can actually write a conformant C++ interpreter.

Now a separate standard for C++ ABI is quite possible, and they do, in fact, exist. The trick is getting the compilers to subscribe to them, and the problem is that they already have their existing ABI (usually incompatible with other vendors), and moving to standardized ABI would break compatibility with libraries compiled with older compiler versions. It's not a big deal in Unix world where source code is generally available these days, which is why Unix compilers (e.g. g++ and Intel) converged on a common one; but Windows stuff is still broadly incompatible.

Re:Could they not have named it something sensible

[simula]

C++0x is the draft name. If it is published by the ISO in 2011 then it will be C++11.