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

Comments

Objective C and C++

[Midnight Thunder]

If anyone has used both Objective-C and current C++, can anyone tell me whether the new specification is a clear improvement on either if these?

Re:Objective C and C++

[thermian]

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++

[larry bagina]

Objective C is C with a dynamic/runtime-based OO on top. C++ is C with a static/compile-time based OO on top. Plus lots of other syntactic sugar (operater overloading, references, templates, namespaces, etc). And did I mention that Bjarne Stroustrup hates the C language? Not surprisingly, there's a lot more syntactic sugar in the new standard. I hope you don't have diabetes!

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

[Anonymous Coward]

Most/All NDS games are Written in C++. C++ is a great language because it allows you to do so many things and still run fast. BTW i love this quote from Bjarne:
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off."
-Bjarne Stroustrup

Yeah except he's absolutely wrong. C++ makes it much easier to shoot yourself, but the effect is more like dropping an atomic weapon on yourself.

I think Alan Kay put it best:
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."

Kay goes on further to categorically state that C++ does not support object oriented programming because of the static type system.

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

[Free the Cowards]

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.

auto rocks

[ultrabot]

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

Re:Some counterpoints.

[Free the Cowards]

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.

[squarooticus]

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

[abigor]

These are all very good points, particularly regarding RAII. I'm sure you know this already, but other languages such as Python provide deterministic resource management as well (in Python, it's the "with" statement). Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern.

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

[Yokaze]

> 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:Time for the C++ haters to post...

[cyberjessy]

Let's see what C++ is missing.

C++ vs Ruby, Python,
1. No REPL in c++. For a large project, it takes a while to try out an algorithm.
2. Generators && Closures && lambdas
3. Strong "reflection" capabilities too, which means that code can inspect, load and modify other code (in Java, C# too).

LISP and C# has the above, plus
1. Static Typing
2. LISP possible has the more generic syntax conceivable, and code can extend the language to suit the domain. A consequence of Code itself being Data.
3. Concurrency (one of those things 0x is supposed to solve) is simpler in a language which supports functional programming.

Do not think that people are complaining about C++ lacking garbage collection. The real problem is with the expressiveness.

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

[Anonymous Coward]

A library that isn't baked into the language may or may not exist, or have been tested, or work, on any given platform. And it may not coexist well with any other such libraries. E.g., your cloud computing API and your network stack don't use the same thread class, so now what?

Modern languages don't produce "undefined behavior" if anyone that was involved with a project has ever made a single mistake in handling references, pointers, or iterators.

And lambdas aren't a lot to ask. They were invented forty years ago.

Re:Some counterpoints.

[Free the Cowards]

I'm not being unfair, I'm explaining why I use what I use.

1. It's still an external library, not built in. And even ignoring that, I couldn't find any indication that Boost implements some pretty basic things like URL fetching or data compression. I could be wrong.
2. Since C++ is not a dynamically typed language, how can you say that it has nothing to do with C++? Newsflash: I don't like C++ because it's not dynamically typed.
3. Python uses reference counting with a cycle collector. This makes an enormous difference. Plain old refcounting is just a memory management aid, whereas adding cycle collection gives you a full-up garbage collector.

And on for your last point, if I were writing a web server then I probably would do it in Python, since any web server I write is almost certain to be I/O bound, not CPU bound. I have no idea what a daemon control program would do that would require using C++; it sounds like a pretty simple and performance-unintensive thing to me. And large desktop software is exactly where dynamic, duck-typed, true OO languages shine. Note that Adobe wrote a significant chunk of Lightroom in Lua, just as one example.

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

[ardor]

Yes, this sounds logical. C++ has only recently become interesting. C++0x back in, say, 1999, would have totally killed off Java.

Re:Time for the C++ haters to post...

[Anonymous Coward]

Very well said. The C++ language has evolved over the years and compiler technology has improved to bring it a long way. Libraries have also vastly improved including the STL. As for pointers, understanding RAII (Resource Acquisition Is Initialization) techniques and using smart pointer libraries will go a long way to prevent a lot of your bugs.

I personally code in C++, was java certified ages ago and now do some C# code as well and I've got to say C++ remains a beautiful language to me.

Every language has pitfalls and one doesn't need to program the same way or use every feature of a language but I think it's nice to be able to do things when you need to. IMHO C++ is a language that provides options. The real trick for the skilled programmer is knowing when to use which feature and writing code in a fashion that is easily maintained years later by others.

The cowboy/whiz-kid mentality, or the lazy programmer mentality doesn't lead anywhere. In C++ it leads to memory leaks and random crashes and in other "modern" languages code that is so heavy on resources it's inefficiency is just amazing.

Just remember NASA and other venerable institutions, including the linux kernel are still written in C/C++

C++ is no longer a modern language

[MobyDisk]

C++ was once thought to be a language that was powerful enough that it could be used to express most features that other languages had. With things like operator overloading, multiple inheritance, and templates, you could pretty much make a class behave however you want. But years later, we have seen that C++ failed at that mission. There are simple and common OO constructs that C++ is unable to represent. Rather than focusing on improving the template functionality, I want the OO syntax fixed.

Let me cite some examples:
1) It is impossible to make a string class that behaves "normally"

Plenty of people have tried. QT, Boost, STL, Gnome, WxWidgets, all have their own string classes. Years ago, when VB developers touted how easy it was to use strings compared to C++, I told them it was merely because nobody had made a good string class. After 10 years of trying to write one, and using dozens of other ones people created, I realized that C++ is simply too weak and too loosely typed to do this.

Suppose I make a string class, kinda like the STL string:
string foo;
1) foo = "whatever";
2) foo = foo + "bar";
3) foo = 7;
4) foo = foo + 7;
5) foo += 7;

Take a look at these. The first one is no problem. That can call an assignment operator to copy the char * contents to the string. The second one can also be done with a + operator. The third one can also be done via assignment. But what if you forget that? Well, the compiler will see that as foo = foo(7) which will call the constructor that allocates 7 characters, and then assign that. So instead of the string "7" you get a blank string. The next example is a problem too. If the string class can be converted to a const char *, as is common, then does this mean to use the + operator on string and an integer? Or did it mean to convert foo to a const char *, then move 7 characters ahead, then assign it? That can result in a crash. This is because pointer arithmetic is intrinsic in C++, but it is inherently type unsafe.

Then how about a function that returns a string? A simple case in most languages, but in C++ it results in redundant copies across the stack. So people revert to funny things like auto_ptr and other wrappers, or complex mechanisms for doing shallow copies to prevent that. Other languages just avoid the problem entirely by not allocating things on the callee's stack. It's just an intrinsic problem in the old everything-goes-on-the-stack-by-default mentality of C++. It just doesn't always work.

Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++ // C#
class Foo
{
private int _x;

public int x
{
get { return _x; }
set { _x = value; }
}
}

So in the above class, I want to access _x via a property get/set. C# has a built-in construct for this. In C#, I could do:

MyFoo.x = 7;
MyFoo.x++;
MyFoo.x = MyFoo.x + 3;
MyFoo.x/= 7;

etc. The compiler knows how to get/set x, and it can even be inlined! This allows me to do things like log when x changes, or see what accesses the variable. Now, let's try that in C++.

class Foo
{
private:
int _x;

public:
int x(); // Get X
void x(int); // Set X
int &x2(); // Another way to get/set X
};

MyFoo.x(); // Gets x, no problem
MyFoo.x(7); // Weird syntax, but that is fine
MyFoo.x()++; // Does not modify the value of x, hmmm...
MyFoo.x2()++;// Modifies x, but only lets you track the get, not the set.
MyFoo.x()/=7;// Same exact issue
MyFoo.x(MyFoo.x()/7); //

Re:C++ is no longer a modern language

[luzr]

Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++

I never really understood this effort. What is so good about properties? Why is writing () after getter function name so hard? And for setters, setter chain is much less verbose anyway, like

mywidget.NoWantFocus().SetReadOnly();

instead of

mywidget.nowantfocus = true;

mywidget.readonly = true;

Why should any language look like Visual Basic?

Re:C#++?

[johanatan]

Why does everyone think that 'simplifying the usage of STL algorithms without creating a lot of functors' is the only use for lambdas and closures? What about making your own code tighter by factoring symmetric blocks into one?

Re:And Then COBOL 2009

[Yokaze]

> I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python.

Well, Python is a different game than Java or C#, which both have a much better JIT-compiler.

I mainly program in C++ (real-time data processing), but I feel hard-pressed to believe, that Java has to be severely slower than C++ in numeric computations. The Java implementations of FFT and LinPack suggest, that comparable performance should be possible. The SciMark 2.0 should also be more up to par, when you replace the synchronized Random in the benchmark with a Java implemented Mersenne Twister.

Re:What tool is better than C++?

[phoenix.bam!]

I guess D is dead? Could have been a lot of hype but it sounded like the language you were looking for.

Re:Some counterpoints.

[Free the Cowards]

Twisted? I wasn't talking about a 68000 or a Palm. I was talking about an embedded microcontroller with a grand total of 32kB of RAM. About half of that is left to hold both program and data once the kernel gets done taking what it wants. Can you fit Python into 16kB of RAM for both program and data, and still have enough space left over to do anything useful? I'll be very interested if your answer is "yes", but I'm doubtful.

Don't get me wrong, I'm a huge advocate for higher level languages. But there are certain places that C can go that others can't simply because C is really just a user friendly assembly language. And C++ may be difficult to compile, but the end result of its being built on top of C is that it goes nearly anywhere that C does.

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

[Kjella]

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),

I work a lot with C++/Qt, but it's damn near that I want to say I program in Qt instead of C++. What's the problem with that? Well, I'm essentially lost if I have to work on a STL/WinAPI/MFC/wxWorks/boost/whatever project. Not in that I don't grok C++ which I do, but that I don't know any of the objects or functions or whatnot being in use. I do realize that there are differences between the libraries but certain basic functions should just be common, there's no reason why you'd need more than one string class. Sun got behind Java, Microsoft got behind C#, nobody got behind C++ and the result is that even the most basic of appliications can source-wise look completely different using different toolkits. It means that apart from equal syntax (and which kind of braces is the least of my problems moving to another language) there's barely something like "C++" - it's a loose family of code which happens to be compatible.

Re:Some counterpoints.

[Anonymous Coward]

Still, if you're writing system software

(e.g. a web server,

I tend to agree, but the folks at Plone and Zope would probably disagree. That's easily one of the most powerful CMS packages, with the only competitor in the same league being Typo3. On the other hand, Django recommends bog-standard Apache.

daemon control software,

I have no idea why you think daemon control software needs the performance of C/C++.

filesystem indexer, etc)

I've actually written a filesystem indexer in Python as part of an image management program (think ACDSee). Obviously the hashing algorithms and performance critical parts are written in C/C++, but there is no reason not to write the rest in Python. You spend most time waiting for the disk I/O...

or large desktop software (Photoshop, Microsoft Word, KDE),

Again, the only one of those that shouldn't be written in Python is KDE (parts of it could be). Image-handling code should be written in C/C++, but the GUI doesn't need to be. My (currently unreleased, but fully-functional) image management program is faster than ACDSee, which has more to do with loading the GUI without blocking waiting for the image to load than it does with using C++. It also uses less memory because I only load the thumbnails that are displayed on screen into memory... Actually it blows the old-school application ACDSee out of the water for performance. Again, for image manipulation, I would use a C/C++ coded image library such as ImageMagick, which has bindings for Python.

then it would be madness to choose Ruby/Python over C++.

Not hardly.

Re:And Then COBOL 2009

[Viol8]

"Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern."

Really?

What about:
COBOL
FORTRAN
VB
Prolog
Lisp
ML

In fact any non-OO languages , given that RAII is an OO concept.

Re:Some counterpoints.

[Kevin Stevens]

It doesn't solve anything that *couldn't* be solved before, but that's not the point, as anything can be solved given enough time and effort.

But out of the box, without even any compilation needed(!) you can get smart pointer implementations, timers, asynchronous I/O, a multithreading toolbox, conversion libraries, containers, memory pools, and tons more (some would say so much more that its bloated) with the added peace of mind knowing that tons of people out there are using them as well and they are thoroughly debugged. Its worth it for the shared_ptr's alone- those alone dramatically reduce the biggest source of C++ bugs.

In my previous company, I worked on a system that was about 10 years old- started before the STL came into existence, and long before it was well supported by compilers, and thus the team had spent a lot of time building STL-like functionality with dynamic strings, iterator like functionality, vector/list work-alikes, etc. This meant that now once the STL came around, a programmer familiar with "standard" C++ had to learn how to re-do mundane things like string and container manipulation. Similarly, that team had created smart pointer implementations, logger classes, multithreaded and socket libraries, etc. Boost not only provides all of this functionality, but you get it working right out of the box, and since Boost is well known, you don't have to wait for a programmer to get up to speed for a month or two while he becomes familiar with your code.

There are some more exotic features that you don't have to use, but I recently used multi_index to implement what is more or less an in-memory database cache in about 100 lines of code. This replaced a lot of code that read records and then threw them into hash maps or vectors using the OrderId as a key, then the CustomerId as a key, etc... so we had fast lookups to our most commonly used objects.

What are its advantages over ACE? ACE is a great networking and concurrency library, which not all applications necessarily need, and ACE's strong point is multi-platform networking and concurrency, which while I wouldn't call a small niche anymore, can't be used across all applications. At least some of Boost's libraries, most notably shared_ptr, can be used in any C++ program. In fact, until Boost::asio was released relatively recently, I would say ACE and Boost were entirely complementary. Also, boost is more or less a testing ground for the C++ standards committee, so it is more or less "blessed" and can be seen as a Beta for future versions of the standard.

Re:Just want to remind everybody

[immcintosh]

I looked at that, and at first it seemed, well, this is fair. A lot of these things are drawbacks, and it's pretty well laid out. Then I read into it a little further... and I really have to wonder. A lot of it is just WILDLY exaggerated. I mean, the author clearly tried to blow some minor problems up to ridiculous proportions. Some of the stuff in there is just absurd. Gems like this:

[8.2] What happens if you assign to a reference?

FAQ: A reference is the object, so of course you assign to the referent object.

FQA: Which means that you can't understand the effect of a statement as simple as a=b; without knowing whether a is a reference or not. A nice feature complementary to references (which make you wonder what "a" means) is operator overloading (which makes you wonder what "=" means). Be careful as you work your way through a quagmire of C++ code.

I'm sorry, but that's just inane. Of course you can't know what the effect of an assignment will be without knowing the actual type of what you're assigning to. How is this news? How is this important? Unfortunately a great deal of that site you linked to is filled with useless fluff like this.

Yeah, that article says a lot. Unfortunately, upon close inspection, very little of it is of much value.

Re:C#++?

[Anonymous Coward]

Nonsense. Microsoft puts huge effort into promoting C# over languages in insidious ways - like putting hundreds of times more effort into ensuring their OS and applications interact well with it, and exposing functionality through C# preferentially to other languages. Why? Not because it's better or easier for them or the user, but because they can't control C++, Java, etc. Programmers working in those languages are also inherently able to develop software for non-Windows systems / browsers. The languages can stipulate that non-portable extensions creating OS or vendor lock-in aren't to be offered. Portable skills are an even bigger threat to Microsoft's near monopoly on the desktop, and aspirations on the server, than portable languages and toolkits. Put Microsoft's muscle behind a language and of course it's going to "take off". And Java's success isn't so much a negative reflection on C++ as a product of having embraced a different and inherently valuable deployment technology: the "web" browser.

Re:C++ has one major problem

[Barnett]

I spend a lot of time on analysis and design. By the time I get down to programming a few months may have past since my previous project. That is the problem. Are you suggesting that C++ programmers should only do full time coding and let other people do the analysis and design work?

Re:C#++?

[neokushan]

Efficiency is just one of the goals of the language, but general use is another. That's why you can do absolutely ANYTHING with C++. Give me a task another language can do that C++ can't.
That's what I mean by being "general".