Interview With Bjarne Stroustrup

koval writes "artima.com has published an initial portion of interview with Bjarne Stroustrup. The scope of first part is mostly about improving the style of C++ programming and getting maximum from a language."

Comments

Compilers

[ultrabot]

Speaking of C++, is there a compiler that complies with the ISO standard already? Does anyone use it?

Re:Compilers

[X]

as any C++ programmer knows, most compilers completely blow when it comes to standards conformance at the moment.

This is the conventional wisdom. It is (sadly) based on how things used to be. However, there has been a significant amount of progress in the last few years with regards to standards compliance. Aside from the Comeau compiler, you have Microsoft's, Intel's, IBM's, and G++. The last time I used Sun's C++ compiler, the only problems I had were with the antiquated version of the STL that they insist on using for backwards compatilibity purposes. The lastest issue of Dr. Dobbs has actually looked at this based on examples from the C++ standard, and while Borland seems to be making little progress (I don't think their compiler itself has changed in a while), most of the other vendors are rapidly approaching full compliance (although export seems to remain a mystery to everyone besides Comeau).

Re:Compilers

[Zathrus]

Aside from the Comeau compiler, you have Microsoft's, Intel's, IBM's, and G++.

I believe that MS VC++ 7.0 (or whatever it's marketed under now) and G++ are the most compliant of the bunch. IBM's compiler may be standard, but their linker is anything but -- thanks to it we can't use dbx or gdb on our code base (both simply core either while loading the core image or when you do a "where"; IBM's dbx occasionally works but never gives proper symbol names and setting break points is impossible). I don't have any experience w/ Intel's compiler so I can't say there. HP's compiler is abysmal.

One interesting place to look at compatibility is the Boost library -- Boost is a rather large C++ library being developed by some of the big names in C++ that may wind up in the next standard -- and how well it compiles on various platforms and compilers. Check out the compiler status page. It's certainly not a definitive test of what is and is not standard, but it's a data point.

You're certainly correct in that C++ compilers and their STL libraries have come very far in the past couple of years. One of the worst (Microsoft) is now one of the best -- largely due to them hiring a project lead that's a STL advocate.

Read Stroustrup's Design and Evolution of C++

[ChaosDiscord]

If you hate C++, it's unfair to suggest you read a book on it. But if you have any fondess for C++, or use C++ (even if you dislike it), Design and Evolution of C++ is probably worth your time. You learn why C++ is the slightly confusing mess that it is, and why Stroustrup believes it's the only way it could have succeeded. Having a grasp on why C++ is C++ (and not Objective C or Java) can improve your C++ coding abilities. And understanding why behavior you don't like is there can at least help minimize the suffering ("This is stupid, but there really isn't any way to change it.").

Re:What is OOP?

[exp(pi*sqrt(163))]

It's just a partially evaluated polymorphic function. Construct one of these things thusly: F(2) and it can now be applied like a function to other objects so F(2)(4) returns 6. The fact that it's polymorphic is very useful because that same object can be applied to a quite different type, say an interval arithmetic type, so F(2)(Interval(1,3)) might return Interval(3,5).

Why is this useful? I do a lot of numerical/engineering work. Say I have a root finding algorithm that throws a bunch of methods at a function in an attempt to find roots. It might first try doing some interval arithmetic to bound the roots and then when it's close enough go in for the kill with a newton solver. So I need to be able to write a polymorphic function that can be evaluated on the types appropriate to these methods (first intervals and then maybe doubles) but also be able to hand it in as an argument to a solver routine (which in this case would be rank-2 polymorphic though people will tell you C++ can't do that!). The above is the only way I know, And the cool thing is that It can also be a partially evaluated function (ie. in the simple example I gave I'm passing in the two argument function + but partially evaluating it by giving one of the arguments 'a'). This is all routine stuff in the functional world and is beginning to be routine in C++, but not yet. It's kinda object oriented but the object oriented frame of mind really is the wrong way to look at it.

Greenspun's rule. Yes, someone said that about some code of mine recently. But I have a response. For one thing the primary function of Greenspun's rule is to provide strokes for Lisp programmers' egos but these are the wrong people! C++ is a typed language and Lisp isn't. This makes a big difference. These methods push C++ more towards typed functional languages like ML or Haskell. Secondly: The example I gave is of a closure, written as (a+) in Haskell. But look where the work is happening: I haven't written any kind of interpreter, the compiler's doing the work. In fact if you take this stuff to its logical conclusion you're not implementing a Lisp interpreter but instead twisting the C++ compiler into a Haskell compiler. And if you don't believe me, here is that logical conclusion. If you look closely very little of that code is executed at run time (the lazy lists are), instead that minor mountain of code is directives to the compiler telling it how to behave like a Haskell compiler.

As for performance penalties: yup, they exist. It's the so-called abstraction penalty. I don't really understand why it exists because it takes only simple rewriting rules to eliminate the overhead but compiler writers don't use them. Luckily people like Veldhuizen are writing papers showing the compiler writers how they should be doing their job.