Bjarne Stroustrup talks with Bill Venners about many aspects of software design, including growing small applications into larger ones, avoiding class distinctions between designers and users, the dangers of premature generalization, and the essence of elegance.

Read this Artima.com interview with the creator of C++:

http://www.artima.com/intv/elegance.html

Bjarne Stroustrup: The problem with C++ and GUI is not that there's no C++ GUI library, for instance. The problem is that there are about 25 reasonable C++ GUI libraries, of which a few are rather good. But people say, "Well, there's no C++ GUI. It's not in the standard." C++ has no common meeting place like there is for Python, for example, where you know you can find libraries. It's a problem of riches, plurality, and a lack of marketing.

Funny thing about this comment is that Python has the same problem in this case, though perhaps not on the same scale. There are several GUI libraries to choose from, which is in some ways worse than only one choice...

Bjarne Stroustrup: That's the new cast syntax. ... But the new syntax was made deliberately ugly, because casting is still an ugly and often unsafe operation.

This is interesting, because it also contrasts a bit with the desire to get people to adopt the new method. I remember in many case specifically choosing to use the old-style casts with thier concomitant shortcomings over the new style, just because the new style was so ugly.

Bjarne Stroustrup: One of the things that amazes people is when you compare good C++ code to good code in other languages, the C++ code tends to be shorter.

So I guess COM code doesn't qualify. I think that one of the things that really hoses up elegance in C++ is macro abuse. COM and MFC are rife with macros and while I have been obliged to use them both, it has always been with distaste. Even ATL is not very elegant. Of course, COM can be used in a clean and simple way from VB (or better, Python or C#, etc.) and it could be argued that that was the original intent, but I see no reason why it wouldn't also be possible to make the C++ usage elegant, as well.

>So I guess COM code doesn't qualify.

I think we can all agree that it most certainly does not.
The Comet Library (http://www.lambdasoft.dk/) makes an attempt at C++'ifying COM. I don't know how well it does it as I don't use it but it sure looks better than plain COM.

> Bjarne Stroustrup: One of the things that amazes
> people is when you compare good C++ code to good code in
> other languages, the C++ code tends to be shorter.
>
> So I guess COM code doesn't qualify.

Definitely not. Unfortunately, many have the curious notion that COM, or the styles popularized by MS/COM, is what C++ is, or what C++ is supposed to be.

> I think that one of
> the things that really hoses up elegance in C++ is macro
> abuse. COM and MFC are rife with macros and while I have
> been obliged to use them both, it has always been with
> distaste.

I use macros only to control #ifndef to deal with platform dependencies. All else is unnecessary *unless* you have to (or simply decides to) *directly* deal with a seriously misdesigned interface (rather than excapsulating it).

> Even ATL is not very elegant. Of course, COM
> can be used in a clean and simple way from VB (or better,
> Python or C#, etc.) and it could be argued that that was
> the original intent, but I see no reason why it wouldn't
> also be possible to make the C++ usage elegant, as well.

Neither do I. However, cleaning up an existing major mess is one of the hardest tasks there is. As long as users insists "doing things the old way" (because that feels comfortable because they are used to it) or "being able to doing every trick we could do before", the old stuff will pervasively affect the new.

Better examples of more modern style can be found on www.boost.org.

-- Bjarne Stroustrup: http://www.research.att.com/~bs

A lot of the things I call elegant you'll find are short compared to alternatives. One of the things that amazes people is when you compare good C++ code to good code in other languages, the C++ code tends to be shorter. C++ code is shorter when it's written in terms of things like the standard library or other good libraries, because you can express ideas very succinctly

I find this terribly ironic from the designer of a language which requires implementation of at least 4 methods per class (default ctor, copy ctor, op=, dtor) as well as requiring added syntax to enable dynamic dispatch (virtual methods).

Maybe Bjarne will weigh in on this himself, but I think (perhaps, in the context of this article combined with the earlier articles in the series) that he may be refering to the implementation code that uses a set of well-designed classes. In that case, using those objects is (or can be) very clean and simple.

I think that it makes sense that library implementations require a bit more rigor than the client code.

By the way, none of the things you mentioned are actually required. It sounds like you are refering to one of Scott Meyers' suggestions (not to be confused with requirements of the language) from Effective C++?

> A lot of the things I call elegant you'll find are
> short compared to alternatives. One of the things that
> amazes people is when you compare good C++ code to good
> code in other languages, the C++ code tends to be shorter.
> C++ code is shorter when it's written in terms of things
> like the standard library or other good libraries, because
> you can express ideas very succinctly
>
> I find this terribly ironic from the designer of a
> language which requires implementation of at least 4
> methods per class (default ctor, copy ctor, op=, dtor) as
> well as requiring added syntax to enable dynamic dispatch
> (virtual methods).

How can you find a fact ironic?

Have you actually looked at equivalent code in several languages? One recent example is the comparative paper on generic programming from OOPSLA last year. Another was a comparison of programs in various OO languages from about a decade ago by one the top Stepstone guys.


-- Bjarne

>> I find this terribly ironic from the designer of a
>> language which requires implementation of at least 4
>> methods per class (default ctor, copy ctor, op=, dtor) as
>> well as requiring added syntax to enable dynamic dispatch
>> (virtual methods).

>How can you find a fact ironic?

Now it's even more ironic. I've once read your comment on c++ syntax that the syntax beauty depends on taste of the evaluator. When have C++ beauty now become a fact ?

>Have you actually looked at equivalent code in several
>languages?

I'll be glad if you have time to give us some examples.

>One recent example is the comparative paper on
>generic programming from OOPSLA last year. Another was a
>comparison of programs in various OO languages from about a
>decade ago by one the top Stepstone guys.

Base on what I've heard people complains about C++, I strongly believe you need more than these two evidences to convince your fact.

Not really. The language doesnt require you to implement those methods, the compiler will generate default versions of these methods.

The rule of thumb is:- if you need to write one of copy ctor, dtor or assign op, then you will almost certainly need to write the other two methods as well.

Exactly the same thing would happen in Java. Say you had a class that created a database connection in its constructor and assigned it to a member variable. Then you would need to write a Clone method and a Dispose method. The only difference is that the user of the Java class would have to call Dispose themselves.

As for the virtual keyword, this comes from the C++ philosophy of using only what you need. Most often I dont need dynamic dispatch for my methods , so why have the overhead of always going to the vtable? In Java you'd have to use the final keyword to disable dynamic dispatch on a method.

> Base on what I've heard people complains about C++, I
> strongly believe you need more than these two evidences to
> convince your fact.

There's a comparison of how to print out 99 bottles of beer on the wall in 621 languages. Appropriately enough, it has several different versions of C++ program, each with in a different style. The length varies widely:

http://99-bottles-of-beer.ls-la.net/c.html

When Bjarne made the claim in the interview, I imagined him to be talking more about algorithms than program infrastructure. Bjarne, you can correct me if I was wrong about that. So for example, looking at what code -- the while loops and for loops and data structures -- it would take to implement an algorithm that does something specific. Not the access specifiers and object infrastructure you might want to put around that algorithm if it were to be part of a large system.

I can't remember who said this and in what context, but somewhere I heard someone talking about how it is ironic that the bigger the language, the smaller the code in that language. In other words, the more features a language has in it, the more ways a programmer can say what needs to be said -- including possibly a very succinct way -- so and the smaller the programmer can make the code. I thought it was Matz who said this about Ruby in his interview, but I can't find it. Regardless, C++ has a lot of features, and perhaps that helps make code shorter.

After one of Bjarne's talks at the JAOO conference where we did the interview, someone in the audience asked Bjarne about readability. And Bjarne's answer was that many people confuse readability with familiarity. It occurred to me that if you handed both me and Bjarne a book written in Danish and a C++ program, I would find both much harder to read than Bjarne. I think that different languages kind of aim at a different level of familiarity than others, so that's another factor in play. Languages that enable more terse code probably also assume the readers of the code are going to have spent more effort becoming familiar with all the various aspects of the language.

I'm curious, Bjarne, if you were talking about C++ compared to scripting languages like Ruby and Python and Perl, or just C++ compared to systems languages like Java and C# and Eiffel. And if it is more about comparing just the algorithms versus an entire application. Because my experience is that at the application level, Java was less verbose than C++, and Python is less verbose than Java. Although in Python I tend to write in a structured design style, not an OO style, so it is kind of an apples to oranges comparison. Whereas I have built the same kind of OO sytems in Java that I used to do in C++. That said, I was programming in C++ long before the STL, so I was not using a modern C++ style.

"Although in Python I tend to write in a structured design style, not an OO style"
Now you are making me curious ;-)
Why is it that you tend to program in a structured style with Python?

>How can you find a fact ironic?

Its a claim - open to dispute.

>Have you actually looked at equivalent code in several languages?

I'm about equally fluent in C, C++, Smalltalk, Objective C, and Java. I used to be quite good at F77 as well but its been awhile. Of these, I find Smalltalk to be the most compact and elegant in all cases.

If you have an online pointer to the paper in question, I would be interested in seeing it.

>Not really. The language doesnt require you to implement those methods, the compiler will generate default versions of these methods.

And 90% of the time does it badly. This compiler generation of methods as well as its over-eagerness to do type conversions via construction of temporaries, user defined conversion operators and so forth results in frequent programmer surprise. The amount of context the developer must hold in his head to understand what he is seeing is daunting. The exact same syntax will be interpreted in many different ways depending on the existence of available conversion paths.

C++ appears to have been designed according to the principle of most surprise.

> >How can you find a fact ironic?
>
> Its a claim - open to dispute.

"Ironic" is not an argument or a productive word in a technical discussion. It tends to inflame and distract.

Especially, as your mention of constructors, etc. was diverting the discussion from programs to language features.

I made an observation based on my experience. I didn't back it up with serious academic study - people rarely does, unfortunately.

> >Have you actually looked at equivalent code in several
> languages?
>
> I'm about equally fluent in C, C++, Smalltalk, Objective
> C, and Java. I used to be quite good at F77 as well but
> its been awhile. Of these, I find Smalltalk to be the
> most compact and elegant in all cases.

That's not the same as having looked at equivalent code. For example, comparing Smalltalk to C++ without a good container library is just silly. (No, I'm not suggesting you did that, but I have experienced many cases where people failed to do such basic "homework").

> If you have an online pointer to the paper in question, I
> would be interested in seeing it.

OOPSLA 2003 Garcia, et al: A comparative study of language support for generic programming. pp 115-134.

I don't know if it's online.

The old short study, which I do not have a reference to, ws by Tom Love (of Stepstone fame).

-- Bjarne Stroustrup: http://www.research.att.com/~bs

> And 90% of the time does it badly. This compiler
> generation of methods as well as its over-eagerness to do
> type conversions via construction of temporaries, user
> defined conversion operators and so forth results in
> frequent programmer surprise.

Well you've changed the subject, from your original post about how much code a C++ programmer is forced to write, to something equally incorrect.

The compiler doesnt generate any type conversion operators at all. As the name suggests 'User defined' conversions operators have to be coded explicitly by a programmer. I dont see much room for programmer surprise there. There could be unexpected conversions with single arg constructor, but we have the explicit keyword to suppress that. Personally I've never experienced the things you're complaining about