Bjarne Stroustrup Reveals All On C++

An anonymous reader writes "Bjarne Stroustrup, the creative force behind one of the most widely used and successful programming languages — C++ — is featured in an in-depth 8-page interview where he reveals everything programmers and software engineers should know about C++; its history, what it was intended to do, where it is at now, and of course what all good code-writers should think about when using the language he created."

Comments

Normal Read

[MoonlightSeraphim]

Print Version of the same article http://www.computerworld.com.au/index.php/id;408408016;fp;16;fpid;1;pf;1

Interesting Read

[dreamchaser]

It's always cool to see this kind of interview. It's even cooler when you can read it all on one page rather than 8.

I suggest that anyone who uses C++ or is interested in the history of programming read this. Some of it is a bit banal, like how they chose the name, but some of it is really intersting. RTFA for once, you lazy clods!

Re:Interesting Read

[Anonymous Coward]

You're thinking of CFront, the original implementation, which was just a front end. But the C++ language itself has been developed further and that's no longer possible.

Re:Interesting Read

[c]

Early C++ "compilers" usually did more than just macro processing, but only just; most of them were implemented in terms of translating C++ to equivalent C code and then compiling the resulting C. Not so elegant, but it allowed compiler vendors to pick the low-hanging fruit and get something on the market ASAP.

It wasn't just commercial compilers, either. g++ worked that way.

Of course, it goes without saying that these early C++ compilers sucked hard.

c.

Re:Interesting Read

[shutdown -p now]

For the record, the first C++ compiler that compiled directly to native code was Zortech C++ (which beget Symantec C++, which beget Digital Mars C++). Its author, Walter Bright, is the guy behind D programming language.

Re:Interesting Read

[hitchhacker]

C isn't a terribly good language, but when you shoot yourself in the foot it's usually a clean wound. From TFA:

"C++ makes it harder to shoot yourself in the foot; but when you do, it takes off the whole leg" is sometimes quoted in a manner hostile to C++. That just shows immaturity. Every powerful tool can cause trouble if you misuse it and you have to be more careful with a powerful tool than with a less powerful one: You can do more harm (to yourself or others) with a car than with a bicycle, with a power saw than with a hand saw, etc. What I said in that quote is also true for other modern languages; for example, it is trivial to cause memory exhaustion in a Java program. Modern languages are power tools. That's a reason to treat them with respect and for programmers to approach their tasks with a professional attitude. It is not a reason to avoid them, because the low-level alternatives are worse still.
-metric

And ...

[LizardKing]

... for an equally partisan view from another perspective, the C++ FAQ.

Re:And ...

[Kamineko]

In case anybody got confused, that's FQA above, not FAQ. This is FAQ: http://www.parashift.com/c++-faq-lite/index.html

If you liked that, read "Design and Evolution"...

[SuperKendall]

The interview just seems like a very brief sampling of "The Design and Evolution of C++".

Even if you do not care much about C++, it's an excellent look into the philosophy and thought that goes into language design.

Love C++, but it still sucks...

[UnknownSoldier]

* No standardized pragmas
* Macros after-thought and not type safe
* No 24, and 32 bit (unicode) chars
* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
* No distinction between typedefs and aliases
* Inconsistent left-to-right declarations
* Compilers still limited to ASCII source
* No binary constant prefix (even octal has one?!)
* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time

Re:Love C++, but it still sucks...

[PhrostyMcByte]

* Pragmas are made specifically for non-standard compiler extensions. There can be no "standard" pragmas.
* C++0x is adding support for UTF-8, UTF-16, and UTF-32 character types and literals.
* TR1 adds cstdint which includes int32_t etc. types.
* NaN and +Inf (not -Inf, though) can be had from std::numeric_limits

alas, if those are the first complaints you think of, you haven't been using C++ long enough to really know the painful bits.

Re:Love C++, but it still sucks...

[Eponymous Bastard]

Most of your complaints seem aimed at C and not C++. Let's see:

* No standardized pragmas

You want standardized *compiler extensions*?

They standardized the extension mechanism. That sounds good for a start, but I don't see how you could go farther.

* Macros after-thought and not type safe C compatibility, basically deprecated now as they also affect everything, including members, variables, anything that gets #included, etc.

* No 24, and 32 bit (unicode) chars wchar exists, toghether with I/O stuff, though I'm not sure about the encoding type. You can even declare streams and strings for any character type you build.

* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc... C compatibility. I believe they are inheriting the new types from C99 too.
Also, short/int/long give you the sizes optimized for the specific processor, so you can use that if that's what you want. You can't really deprecate them because of that

* No distinction between typedefs and aliases What on earth is an alias? Are you talking about C's struct namespace? (one of the few things that C++ doesn't inherit)

* Inconsistent left-to-right declarations Inconsistent in what sense?

* Compilers still limited to ASCII source C++ has included trigraphs for over ten years now, which allow an editor to insert any unicode character and still store everything in ASCII for compatibility. Compilers don't even need to support unicode for things to just work. The editor just has to interpret the trigraphs and paint them on screen as the appropriate character.

I've never used them though.

* No binary constant prefix (even octal has one?!) I've never met anyone who actually worked in binary. Hex is close enough and less error-prone. Octal probably got included for a) C compatibility and b) People did use to work in octal (see file access permissions)

* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time Would you like a quite or signaling NaN?

For double:
#include <limits>

const double inf = std::numeric_limits<double>::infinity ();
const double minf = -std::numeric_limits<double>::infinity ();
const double nan = -std::numeric_limits<double>::signaling_NaN();

See more here for example.

There are has_infinity() and related functions to check for a type's capabilities (say, in a template)

Re:Love C++, but it still sucks...

[Bazer]

* No standardized pragmas

Pragmas were meant to be OS and compiler specific. If your OS or compiler doesn't provide a standard then it's the language is not at fault.

* Macros after-thought and not type safe

Macros weren't meant to be type safe. You should use templates if you need type safety.

* No 24, and 32 bit (unicode) chars

What about std::wstring and cwchar?

* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead * Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...

Use cstdint and cfloat

* No distinction between typedefs and aliases * Inconsistent left-to-right declarations

I don't have much experience with those in C++ so maybe someone else should elaborate. Could you provide examples where these two would be a problem?

* Compilers still limited to ASCII source

This is true but hard-coding unicode strings is considered a no-no.

* No binary constant prefix (even octal has one?!)

This is true.

* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time

Standard since C99.

Re:yawn

[Anonymous Coward]

So just what is a protected abstract virtual base pure virtual private destuctor, and when was the last time you needed one?

Re:Use this link to read article on one page

[PhrostyMcByte]

The developer should know if he'll need the size of an array or not. Which is why there is a convenient std::vector and std::tr1::array for when you do want the size. Not forcing you to carry around a size is a feature, not a bug - if you don't need the size, it's just a waste of space.

And auto_ptr is likely to be depreciated in C++0x, with unique_ptr and shared_ptr replacing it.

Re:yawn

[Samrobb]

For example, if you declare even one virtual member function, you HAVE to declare your destructor virtual.

I don't know where you got this idea. If you have virtual member functions, you probably want a virtual destructor, but it's neither a requirement, nor a given.

From the C++ FAQ lite, read [20.7] When should my destructor be virtual?

Anyone trying to defend C++ as a language

[frank_adrian314159]

Anyone trying to defend C++ as a language should read this. And I speak as a programmer who has used C++ since cfront 1.0 was released to the world.

Useful, yes. Pragmatic, maybe. Design heavily rationalized ex post facto by its creator and its proponents, most certainly. But a well-designed programming language, it is not.

Re:useful but oh so flawed

[pclminion]

Good book, but I don't see how some minor nuances translate to insurmountable design flaws. It's true that proper use of C++ requires a level of expertise beyond what's required for many other languages. IMHO, that just makes real C++ programmers more valuable.

Re:yawn

[shutdown -p now]

All languages have "implementation details" and various gotchas.

It's true, but some have more, and others have less, and C++ is on the "a fucking lot" end of the spectrum. Of all the languages I know, the only one that has more (mostly because it covers a lot more ground) is Common Lisp.

Re:Use this link to read article on one page

[shutdown -p now]

C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.

Delphi is no more memory-safe than C++ is. For that matter, Delphi actually requires you to call destructors for all objects explicitly, and woe be on you if you forget to, or, worse yet, accidentially call it twice. No smart pointers either: welcome to hell.

By the way, what the hell is "object overflow"?

Re:Use this link to read article on one page

[Eli Gottlieb]

I can see why you've been modded Funny. Null-termination is not, at all, even slightly, the same thing as an array carrying its size with it. Null entries can pop up anywhere for any reason, often bugs. It's much, much, much safer to just use the extra integer word and store the number of entries in the array.

Stroustrup seems to say (don't use exceptions!)

[EMB Numbers]

Here is a real eye opener: Bjarne Stroustrup cited the JSF coding standard as an example of C++ usage: "Also, embedded systems programming is a major area of use and growth of C++; for example, the software for the next generation US fighter planes are in C++ (see the JSF++ coding rules on my home pages)." http://www.computerworld.com.au/index.php/id;408408016;pp;5;fp;16;fpid;1

I particular like the following statement in the JSF++ coding rules that the creator of C++ holds up as an example of how to use C++:
AV Rule 208 C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)

Rationale: Tool support is not adequate at this time.

A wisely used tool for elegant implementation

[Douglas Goodall]

I am the first to admit you can write totally unmaintainable code in c++ if you want to. I will also admit that I have known a lot of c++ programmers that absolutely had to use every feature or they weren't happy.

I on the other hand used about 10% of the features and had a wonderful time using a subset that probably was actually just "c with classes". I used c++ as a better c compiler with warnings turned up all the way. I found classes an elegant way of encapsulating code that dealt with hardware. Concrete classes were my favorite. My c++ programs were straightforward and easy to read. I am thankful that BS wrote the language. It was a lot of fun. I never really needed more than I learned in the first month. Strong type checking kept me out of trouble. I actually spent very little time subclassing and enjoyed the luxury of keeping my prime classes functional. Modeling hardware as c++ objects was the most fun I had in programming ever. When done right, the code was as compact and maintainable as any I have written in any other language. Unfortunately I got very little follow-on work because the functionality of my code was obvious. Vendors like Microsoft and Borland just couldn't wait to use polymorphism to create frameworks. I hated frameworks because they were these huge collections of c++ complexity that had to be studied endlessly, and about the time you knew enough, the vendor brought out a new version. MFC is a prime example of a piece of code I just couldn't get my head around. It seemed to me that the point of all the frameworks was to make hello.cpp in 100 lines or less, but anything non-trivial got huge quickly.

I suspect that there are other people out there that felt like I did about c++. At least I hope there are. Every time I encountered a project where the legacy code used every feature of c++, my spirits took a dump. C++ was a tool that consultants often used to make themselves indispensable. Some of the code I encountered, like the bio-rad application was a good thesis, but a lousy piece of intellectual property. Twenty levels of nested classes, heavily subclassed made for a long research project every time you needed to track down a bug.

The secret of c++ for me was knowing just how much to use to leverage off the power of it's object orientation. Encapsulation was good, Inheritance was ok sometimes. Multiple inheritance was almost never a good thing, and polymorphism usually lead to spaghetti code. IMHO