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

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

[ron_ivi]

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 )

Make it stop.....

[jythie]

Stop trying to add more redundant features to C++... it is already getting progressively harder for C++ programmers to read each other's code and teach newbies what something means.

All this does is result in yet more more syntactic sugar to teach people in order to accomplish the same tasks they can already do with the older standards, and yet another round of relearning so you can tell what someone who learned a 'neat new trick' is doing. And of course you STILL need to teach the old methods to newbies so they can understand C++ code that they have to maintain.

Seriously.. this really does not help.

Linking

[MrEricSir]

The biggest beef I have with C++ is linking.

Linking to a library that was compiled in a different C++ compiler (or even a different version of the compiler you have) is somewhere between painful and downright impossible; this is because function name mangling was never standardized and the core libraries are often incompatible.

Couldn't they standardize this in C++? It would make life so much nicer for those who deal in binaries.

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

[derGoldstein]

C++ allows you to work at a level of abstraction that you need right now, for this function or section/area of the program. It gives you this ability while not forcing you to inline other languages, but you *can* compile C alongside it in cases where there's already a C library that does specifically what you want (and almost all task-specific libs are written in C, across most languages). No other language can boast anything near this level of flexibility. Can it be messy? Definitely. But good software structures will look clean and logical no matter where you look along the spectrum of abstraction ("spectrum of abstraction"... I need to remember that next time I publish something intended for academia...).

Re:Multi-processor Extensions

[scorp1us]

So, I am an unapologetic Qt freak.

It does everything pretty damn easily and extends your C++ compiler by using a MetaObjectCompiler (MOC pre-processor) and gives you most, not all, of what C++0xForever is promising. Platform independently.

Of you don't like Qt, then there is Boost. Both are just C++ libraries.

Re:Multi-processor Extensions

[lgw]

The core Boost classes were written by guys on the C++0x committee - they were written with the intent of becoming part of the standard library eventually. It's nice to have commonly used libraries incorporated into the language standard, especially to standardize cross-platform interfaces to platform-dependent stuff like threads.

But some stuff like Lamba just gets better syntax sugar if you change the language instead of using a library. While I'm not all that happy with the new C++ lambda syntax (what's wrong with making lamba a keyword, guys? same for you C# guys?), is still way easier than the Boost lamba syntax.

And some stuff like move semantics are just an outright fix to the language. Vector will stop requiring that Foo be copyable - finally!

Re:Make it stop.....

[js_sebastian]

Stop trying to add more redundant features to C++...

Did you even bother to read about what these supposedly "redundant" new features are? Personally, I think these redundant new features will help maintain C++ as one of the 2 or 3 most used programming languages for the next decade. Especially since this time all of the new features already have reference implementations, so the compilers will be very quick to implement them (GCC already supports a long list of them).

I would say the single most important feature is finally having standard support for threading and concurrency. Hopefully, this will gradually lead to a standard library of high-level abstractions for parallel programming as well as concurrent algorithms (did you ever try the parallel mode of the gnu stl? parallel sort on 8 cores is sweet...).

There are also a lot of little tweaks under the hood, that programmers will benefit from even if they never need to know about it, just by using the STL. For instance even if you have never heard of move constructors, they will make some methods of standard containers more efficient and make it possible to have a proper implementation of the new unique_ptr (useful for Resource Acquisition Is Initialization paradigm). And most of the added syntax is straightforward enough that it doesn' t really add complexity:

Initializer lists:

vector<string> v = { "xyzzy", "plugh", "abracadabra" };

Range-based for+auto types:

for (auto x: my_container) {
...
}

Re:Make it stop.....

[lgw]

Because the "debt" is mostly in short term bonds - it used to be mostly long term, but the Fed broke that. We therefore can't inflate our way our of debt without destroying the currency itself, because you have to complete that process before the bonds mature.