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

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