Interview Update With Bjarne Stroustrup On C++0x

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

Nice name, chief.

I saw the headline and thought I was seeing some 1337 form of "cox."

huhuhuuhuhuh he said "form."

Truer words have never been spoken.

C++ is to C as Lung Cancer is to Lung

Re:C#++?

Because performance is important to some people.

Re:C#++?

If it was as good as it stands, then newer languages such as C# wouldn't take off.
Don't get me wrong, I love C++ and it's my primary programming language, but to say it's perfect as it is, is just silly.

Re:C#++?

No it's not. The standard does not define concurrency issues. Not how to spawn threads and create mutexes, but lower-level issues, like coherency. This is sorely needed for truly portable code. Rvalue references will help a lot with the creation of temporaries that are just copied and destroyed. You see this now in all the specializations in the libraries for the swap function. With rvalue references, you can write a single template that will be optimal for all types. Currently template error messages are a mess. several lines of unreadable garbage because your type doesn't supply a member or operator that the template needs. Concepts will lead to concise, easy to understand error messages. typedecl and the new use for the auto keyword will reduce verbosity, and stop the nightmare that is figuring out the type of a complex template (i.e., when using Spirit, et. al.). Lambdas and closures will simplify using the STL algorithms without having to create a lot of functors. REH

On of the features:

"control of alignment"

I'd like chaotic good please

Re:On of the features:

I'd like chaotic good please

I hate to be the one to break the news, but C++ isn't the only thing that's been revised recently...

LOL C++0x0Rz

...or, as a former manager explained it, "When C++ is your hammer, everything looks like a thumb."

Re:LOL C++0x0Rz

No, no. It's "C gives you enough rope to hang yourself. C++ gives you enough rope to hang yourself and every programmer who comes after you"

Just want to remind everybody

http://yosefk.com/c++fqa/ [yosefk.com] - this site says it all.

And it's also being argumentative and verbose at that, unlike your routine 'C++ sucks' rant.

C++ has one major problem

C++ is an extremely powerful programming language and that is why I use it every day. But it has one major problem: It is too complicated. As long as you do programming full time you are OK but if too much of your time is spent on the application side of things you quickly get in trouble. This is what people like BS don't seem to get - not everyone can spend 100% of their time studying the language.

auto rocks

The new "auto" declarations really fix one of the biggest gripes with C++. Everybody is dead tired of doing

std::map::iterator it = m.begin()

Now you can just do:

auto ip = m.begin()

It takes much of the pain away from static typing...

I can.

Yes.

Re:Objective C and C++

No, not really.

In fact C++ is barely managing to hold its own any more against C# and Java.

It's not that C++ isn't good, its just that its harder to do things in it then it is to do those same things in either C# or Java. Harder to do means more expensive, and businesses all over are having to tighten their purse strings.

I keep finding that for fast number crunching apps, C beats C++, and for less intensive work its usually easier to use Java or C#, or indeed python, then it is to use C++.

Also, its certainly true to say that in the UK C++ is not anywhere near as useful in terms of getting yourself a job as it used to be.

Re:Objective C and C++

Objective-C is essentially unrelated to C++ in every way. C++0x does not change this fact at all. Comparing the two makes just slightly more sense than comparing C++ and Prolog.

Re:It hurts you to learn C++ is still being used.

Been there, done that.

Most of the time, the potentially reduced running time of the C++ implementation never comes close to the months saved in development.

And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.

I just don't get it....

...what do people find so difficult about C++? Use the standard libraries, exception handling, and make sure your news all have deletes, and it's no more difficult than any scripting language. I actually prefer it over scripting languages, which have their place, but feel all sloppy and unspecific. It's like the difference between building a house out of 2x4s and building one out of sticks you found laying on the ground.

Re:I just don't get it....

Well, here's what I personally dislike about C++. You don't have to agree with them, but this is how I feel and I think it's how many other people do as well. Certainly when talking to people who prefer other languages over C++, they have expressed similar sentiments.

1. Lack of libraries. The C++ standard library basically gives you file IO, containers, and that's it. If I want to do something like fetch the contents of an HTTP URL, parse XML, serialize objects, compute dates and times, use regular expressions, compress data, or even just simple, basic Unicode support, then I have to hit some external library that I may have to install and probably can't rely on existing on another machine.
2. Flexibility. In C++ it is essentially impossible to make, say, a dictionary where each key can refer to an object of a completely different type. This is what you refer to as "sloppy", but I actually find this flexibility to be essential in designing good software. The fact that C++ does not allow it forces me to either twist my program's design in unnatural ways to fit the language, or do a lot of extra work to twist C++ to fit my program's design.
3. Manual memory management. In any complex program, balancing your news with deletes is not as simple as you make it out to be. Object ownership is a tough problem. Lots of C++ code solves this problem by making a lot of defensive copies, which in turn hurts performance greatly.
4. Errors. Make one simple typo in a template instantiation and you can generate literally pages of twisted, non-obvious errors. This makes it much harder to get a C++ program to compile than it should be.
5. Nonportability. C++ compilers tend to differ massively in just how well they adhere to the C++ specification. Creating portable C++ code is much harder than it ought to be, especially when you take into account the necessary dependence on external libraries I mentioned above. And then you need a build system to go with all of that, which brings its own set of headaches.
6. Readability and writability. With all the type information being declared all over the place, big template declarations, and the like, I find that C++ takes considerably more effort to both read and write.

The really big issues for me are the flexibility and the lack of libraries. The rest is less important. But with C++ it's like building a house out of 2x4s that you're not allowed to cut to length, whereas with moer modern languages it's more like building a house out of prefabricated rooms, with a ready supply of 2x4s and tools to shape them as you need if the prefabbed rooms don't fit your needs.

Please note that this is just my opinion, and you asked for it. Feel free to disagree, but please don't flame.

Re:Some counterpoints.

Counter-counterpoints:

1. Boost is an external library, and from my very limited experience none too easy to incorporate.
2. Likewise, an external library. But putting that aside for a moment, what's the C++ equivalent to this python code?
   d = {"name":"Bob", "age":42}
   print "Name is %s and age is %d" % (d["name"], d["age"])
   Keep in mind that this is a complete python program, no further code is required.
3. While those are handy, they don't substitute for a real garbage collector.
4. I hope you're right, but I'm skeptical. Massive template instantiation errors seem to be a compiler problem, not a spec problem.
5. Key words being "can be". It's tough to do, especially since the compilers out there almost never comply perfectly with the spec.
6. Of course it's a matter of taste, I never said otherwise.

Re:It hurts you to learn C++ is still being used.

...and roll on the C++-hatred! Second C++ article in a short time, and again lots of venom and anger. "Months saved in development"? Really? What are you doing, implementing your own OS before you start application development? Here's a newsflash: C++ also has support libraries, just like Java, Perl, Python and Ruby. They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way), but that doesn't mean they don't exist.

Anything you could want for in a modern language is there. And nobody is holding a gun to your head and making you write those scary templates if you don't want to.

I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++. Not that there is nothing to criticize about it, but it is still an amazingly powerful, versatile tool that programmers anywhere would do well to learn.

Re:It hurts you to learn C++ is still being used.

> I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++.

Because C++ is not a pure language. It is a multi-paradigm language (imperative, OO and functional) with both a high and low-level language features and people seem to hate the aspect they which they don't prefer.

The close-to-the-metal types hate the high-level aspects and rather use C. Disregarding the fact, that changing the code from C to C++ is purely syntactical and runs without any detriment in performance. Exactly the prime idea behind C++.

The high-level people dislike C++ exactly for this approach. They don't like that the basics are so clearly visible, and are even the default. You have to hop through some loops, before you get to a higher abstraction layer. E.g. you have to use external libraries and/or special classes for memory management.

Personally, I like C++ for exactly that reason. I can start on a fairly abstract layer with pure virtual interfaces, smart pointer, signal slots and there is not a single (raw) pointer or a manual deallocation to see (or other manual resource deallocation).
Granted, it is more verbose than in a pure high level language, but that is what the machine has to do.

And if there is a performance bottleneck, I can seamless go down in the abstraction level from simple inline functions, over imperative functions with pointer arithmetic, down to inline assembler and can even guarantee a certain timing, if necessary.

Re:It hurts you to learn C++ is still being used.

You do know that you don't have to screw around with any of that in a managed language, right? "Very easily make the different processor needs compatible" my ass--Java/C# do it on their own.

Re:It hurts you to learn C++ is still being used.

No, the "premature optimization" thing applies to all areas. Especially areas where it's never fast enough.

Why? It's simple: resource management.

You have X amount of resources to put into your product. X is always finite. It's kind of tough to measure X, but you can think of it as lines of code, man-years, or even just dollars. The amount of resources you have varies a lot depending on your budget, how much time you have, and the quality of the programmers you have. But the important thing is that X is always limited.

Now you have two approaches:

1. Spend X on making the code fast from the start, and keep spending X until you run out.
2. Spend X on making the code functional and with good design. When appropriate (i.e. when the design is good and the code works), start spending X on making the program go faster. Keep spending X on speed until you run out.

Paradoxically, I hold that #2 will produce a faster program. This is because the X you spend on making the program faster in #2 will be more effective, because you've already laid the groundwork for it. It's always difficult and time consuming to optimize code that doesn't even run yet. It's much more efficient to optimize code that already works. So the result, even though you spend less X on speed, is a faster program.

Think of it as transporting a lot of material into the wilderness somewhere. If you first spend some of your resources on building a road, you'll get the job done for less time and money than if you just start hauling stuff into the woods immediately.

Re:It hurts you to learn C++ is still being used.

I am not going to go read a book simply to settle an argument: you need to summarize here.

In particular, explain to me why his techniques are not generally applicable to other languages (or to Python or Ruby in particular) or why using those techniques or similar ones and interfacing to C when necessary actually provide a less efficient development environment.

I know C++ can be made "acceptable" as a high-level language through sufficient effort; I spent 7 years doing such a thing. I want to know why that's a better solution than using tools that are---out-of-the-box and without reference to a magic cookbook---ready to do the things that require months of development or dozens of third-party libraries to achieve in C++.

Re:And Then COBOL 2009

I'll consider Java and C# as C++ replacements once they get:

1. REAL templates, not this generics joke
2. Proper RAII, which many programmers mistakenly believe to be useful for memory management ONLY (scoped locks come to mind) (Java/C# finalizers are no replacement)
3. Java: operator overloading

These points are serious, especially the first, without real templates, generic programming/metaprogramming at compile-time is not possible. These two are one of C++'s biggest strenghts, though.

To be fair, C# 3.0 is somewhat nice, especially its functional core. Java is a totally uninteresting language with very small expressiveness. Of course, if the job requires it, there is no discussion, but in my spare time, I prefer C++.