An Interview With C++ Creator Bjarne Stroustrup

DevTool writes "Bjarne Stroustrup talks about the imminent C++0x standard and the forthcoming features it brings, the difficulties of standardizing programming languages in general, the calculated risks that the standards committee can afford to take with new features, and even his own New Year's resolutions."

Comments

C++0when?

[fishexe]

Of course by this point it really should be called the imminent C++1x standard.

Re:C++0when?

[Anonymous Coward]

No, it's going to be called C++0xc or 0xd.

Re:C++0when?

[h4rm0ny]

Nah, the revised and improved C++ is going to be called D.

Oh wait, it already is. ;)

Re:C++0when?

[c 0xFF]

My user name seems appropriate here.

Re:c++ 1x sucks

[wiredlogic]

They should have added nullptr 20 years ago. It's always amusing to read about C++'s design for type safety when we've been forced to sling around magic '0' literals all this time because someone got their panties in a bunch over automatic casting of void*.

Is C++ ever the right tool for the job?

[ron_ivi]

It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.

IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.

( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )

Re:Is C++ ever the right tool for the job?

[EsbenMoseHansen]

I tried to use ruby for a while, but ended up back with C++. I couldn't live without static typing, as it turned out, and also C++ had more libraries leading to faster development (for me, at least).

C++ is the worst language, excepting every other language I have tried. And I am happy about the new features, they should make coding much nicer.

Re:Is C++ ever the right tool for the job?

[godrik]

I aggree that people tend to do too many things in C++ (me first). However, there are quite some place where C++ should be used. Mainly gaming engines and high performance computing. You NEED low level programming to deal with that. They could be written in C. But numerous C++ programming techniques (mainly template mechanism) makes it much easier to program. You could not get reusable algorithm accross multiple data type with efficient compile-time type checking at no runtime cost without templates. You could do it with macros but you will have terrible compilation problem if you screw up. Or you could use inheritance but will pay the cost at runtime.

Re:Is C++ ever the right tool for the job?

[Monkeedude1212]

No. THIS is a joke.

Two bytes meet. The first byte asks, “Are you ill?”
The second byte replies, “No, just feeling a bit off.”

Re:Is C++ ever the right tool for the job?

[Anonymous Coward]

No offense but you have to be stupid to not know what + does. If it does something unexpected, chances are you wrote it incorrectly yourself, or are using a terrible library that has undocumented operators that are working incorrectly on top of that. It's not the languages fault when programmers code like retards.

Re:Is C++ ever the right tool for the job?

[mswhippingboy]

It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.

IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.

( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )

I disagree on several points. C is great for low level programming, but many times you want to use OO rather than procedural programming. C++ allows you to do exactly the same low level programming you can do in C (including inline-assembler if needed), but also offers the ability to design in OO. I can't think of a good reason not to use C++ rather than C unless it is a simple monolithic (preferably small) project. Mixing languages brings a whole other set of headaches (including staffing issues). Ruby, Python or other languages are fine and have their place, but I can't imagine using them for systems level programming anymore than I would use C++ to build a web application. Languages like Python, Ruby, (errr.. LISP? - there is considerable debate over whether LISP is even a true "programming language" but rather an alternate implementation of a Turing machine, but I digress) are orders of a magnitude too slow to be used as systems programming languages.

Re:Is C++ ever the right tool for the job?

[EvanED]

I used to be a huge C++ fan, though that has waned over the years as I've used better-designed languages and have also seen other people struggle with C++'s testier features.

That said -- I'd still take C++ over plain C for essentially anything in a heartbeat. (Basically the only exception would be stuff like microcontroller programming or other environments where there isn't really a good C++ compiler.) RAII alone is enough to seal that deal.

I don't buy most of the arguments of C over C++. For instance, take your statement that "IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules."

But with modern compilers, I feel it's already very not obvious what the compiler is going to do with your code. What function calls are inlined? What loops are unrolled? For what I think is a reasonably dramatic example of this, take the following snippet:

int main(int argc, char** argv) {
    int y = 50;
    if (argc > 1) {
        y = 100;
    }
    return y;
}

and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)

If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.

In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.

Re:Is C++ ever the right tool for the job?

[Prune]

Indeed, C++ is just as easy as C to use for low-level programming, as not only do you have the option of inline assembly which mixes easily with the rest of your code, but you even rarely need to resort to it as in the major compilers (MSVC, gcc, Intel C++) there is a plethora of compiler intrinsics which almost directly map to assembly instructions while providing a type-safe interface. It's quite easy to write synchronization primitives, for example, using interlocked operation intrinsics--while the same have a nice object-oriented interface. Just because C++ is large and has a multitude of features in no way implies that you need to try to use all of these features. You might as well complain that the library has too many books! It's ultimately a matter of programmer discipline; stop shifting the blame.

Re:Is C++ ever the right tool for the job?

[Spykk]

If you don't like operator overloading then don't use it. I don't see how that has any effect on C++'s usefulness as a low level language. C++ can use inline assembly the same way C can. C++ has all the power of C with the convenience of classes.

There is no mandate that you must use templates or operator overloading in C++. If you are going to complain that it gives you the option then why aren't you complaining about C having goto?

In my experience when someone wants to use C over C++ for a new project it is generally because they don't know C++.

Re:Is C++ ever the right tool for the job?

[derGoldstein]

You moved from portable, scalable, flexible C++ to an architecture-specific assembler? Ah, I see you were modded up. Good, Slashdot is working perfectly today.

Re:Is C++ ever the right tool for the job?

[SanityInAnarchy]

I don't think the point was what sort of optimizations might be employed or what the resulting binary would look like. It's not about implementation, it's about semantics.

For instance, in C, the bit shifting and boolean operators have precise and well-defined meanings. I know that anything which compiles with one of those operators is going to do exactly what that operator says. I personally don't have a problem with operator overloading (and truly miss it in Java), but in C++, the standard library co-opts those operators and perverts them into something else, to the point where when I was first learning C++ (without learning C), I thought data, which means I need bitwise operations to do what they're supposed to do.

Now, I don't think that's actually an argument against C++. If I don't want to be confused by operator overloading, I'm not forced to use it, and I think the benefits (when used properly) far outweigh the problems (when abused) -- and I think that's true of many language features people like to complain about. But I do think that's what GP was getting at -- it's not what physical instruction it might turn into, it's what the actual semantics are.

Re:Is C++ ever the right tool for the job?

[derGoldstein]

C++ allows you to work at a level of abstraction that you need right now, for this function or section/area of the program. It gives you this ability while not forcing you to inline other languages, but you *can* compile C alongside it in cases where there's already a C library that does specifically what you want (and almost all task-specific libs are written in C, across most languages). No other language can boast anything near this level of flexibility. Can it be messy? Definitely. But good software structures will look clean and logical no matter where you look along the spectrum of abstraction ("spectrum of abstraction"... I need to remember that next time I publish something intended for academia...).

Re:Is C++ ever the right tool for the job?

[EvanED]

I'm a pretty big defender of C++ if only because it often gets trashed, but I think "if you don't like operator overloading, don't use it" isn't a particularly helpful or even accurate position to take. The problem is that you basically never write a program in a vaccum; you basically always use libraries. Does one of the libraries you want use operator overloading? If so, then you either have to use operator overloading or find a different library.

Hell, when your language's canonical "hello world" program uses operator overloading, I think it's safe to say that it's just something you'll have to deal with in that language. The standard library uses it all over -- iostreams, containers, etc.

Re:Is C++ ever the right tool for the job?

[derGoldstein]

That's simply the fault of the way (or order) that CS is taught (at some places). Using C++ shouldn't have stopped you from learning about registers, memory blocks, and simply digital logic along with micro-architectures. Did you expect C++ to teach you CS, or expect not to need to learn CS if you used it? You're blaming C++ for a separate problem.

Re:Is C++ ever the right tool for the job?

[EvanED]

So you have to be paranoid and check the class definition just in case.

So I have two responses to your general comment, though they are related.

You don't need to check the class definition at all -- you just need to know that one of the operands is an object. That's all. IMO, that's the only* difference between an overloaded operator call and a normal function call.

Once you're at that point, I don't see any difference between calling the function "+" and calling the function "doSomethingSimple". If you're paranoid enough about the class defining "+" in a way that will cause it to open sockets and thus you have to check the class definition to see if it does, you should be equally paranoid that "doSomethingSimple" will do the same thing and you have to check the class definition anyway.

The second part of my response is this: why do you CARE what "+" does internally? I can think of two reasons.

First, because you're concerned about efficiency. I've already said why I think this is a red herring, especially because I suspect most overloaded operator functions will be inlined to something efficient in general other way.

The second reason is because you want to know whether "+" is a good name for that function. But again I don't see how this differs from normal functions. If I call a function add and write a.add(b) instead of a + b, why are you more suspicious about the latter? I can come up with bad names without operator overloading plenty easily enough. Hell, I come up with bad function names for my non-overloaded functions far more often than bad function "names" for my operators. (And that even neglects the personal opinion that the normal convention of a.add(b) for a + b -- e.g. like what's used in Java's complex class -- feels wrong to me. a.add(b) feels way more like a += b than a + b to me. But again -- this isn't the fault of Java not supporting operator overloading per se, but rather the fault of Sun's function naming.)

* Okay, there is one other difference. Operator overloading is cool and tempting to use. It invites abuse way more than function naming does. But some high-profile cases aside (in particular, the proposal to overload the comma operator or whatever it was to load containers, a la Vector v = 4, 5, 6, 7, 8; or something), it certainly seems to me that, in practice, programmers are actually able to hold their tongues pretty well. Strangely enough, the biggest exception to this, I feel, is the bitshift overloading in iostreams. And IMO, that's easy enough to learn and brings about enough benefits (I/O type safety, non-repetition of type information, and extensibility vs a printf-style interface, and way less syntactic overhead vs repeated function calls) that it's probably the best solution even though it's not entirely satisfactory.

Re:Is C++ ever the right tool for the job?

[firewrought]

If you don't like $FEATURE then don't use it.

I always cringe when I see this statement in a discussion about programming languages. The presence or absence of a particular feature will impact the third-party libraries you use, the code samples and tutorials you come across, and the legacy apps you inherit. Even if you develop in a vacuum, some features can impact you by accident [operator overloading isn't a good example, but implict-conversion-of-numeric-types-to-boolean is].

In $FEATURE desirable or not for a particular programming language? Most always, that's going to be a complex usability/design question answerable by some combination of analysis, research, experience, testing, etc. Read the programming languages weblog or the discussion forums for D, Haskell, etc., to see the level of thought that goes into make these tradeoffs.

Re:Is C++ ever the right tool for the job?

[Prune]

Overly simplistic.
Both the tools and the products are more complex, but the increase in complexity of the former is lower than the increase in complexity of the latter.

Re:Is C++ ever the right tool for the job?

[noidentity]

I disagree on several points. C is great for low level programming, but many times you want to use OO rather than procedural programming. C++ allows you to do exactly the same low level programming you can do in C (including inline-assembler if needed), but also offers the ability to design in OO.

This is why I use C++ instead of C. I can start with basically C code, then mix in whatever C++ features are a benefit to the project, and ignore the rest. Currently I use a pretty small set which provides significant benefits over coding in plain C. Sure, there's unmaintainable C++ code out there, but I'm using the C++ language, not that code, so it's irrelevant to me.

Re:Is C++ ever the right tool for the job?

[ukyoCE]

Overloading can certainly muddle code readability, but it still depends on someone doing something wonky or overcomplicated with an operator instead of a named function. Which you could argue, comes down to "bad code is bad".

In Java on the other hand, I find it totally unpredictable and unreadable. Bad Java code uses operators and tends to have major bugs due to object VS primitive issues. The "better" Java code uses functions everywhere for equality, addition, etc. So instead of being able to quickly tell where doSomething is called, you see extremely wordy nested functions for math that in C++ would actually look like math.

I wasn't very happy with operator overloading in C++, but now that I've used Java, I think I want C++ back.

Re:Is C++ ever the right tool for the job?

[EvanED]

My reply was slightly tongue-in-cheek, but I do think you have to be using a stupidly restrictive definition of "programming language" for it to exclude at least any Lisp from the last four decades or so.

Even that link you gave in the other post to the McCarthy paper includes things right near the top (of that section) that say "[LISP] has been or will be used for the following purposes: ... writing a program to ... writing programs for ... writing programs to ..."

And in your other reply you say "LISP has it's place as a powerful tool for creating domain specific languages and as a macro processor (as used in emacs), in AI and mathematics, but is not and was never intended as a general purpose programming language," which, even if it's technically true of McCarthy's LISP, definitely isn't true of a lot of more modern Lisps. Even if you think that Scheme wasn't intended as a general purpose language and is instead aimed at teaching (something that I would disagree with at least in terms of what it's become), I think it's pretty absurd to argue that Common Lisp, Clojure, and Arc aren't intended as such.

Re:Is C++ ever the right tool for the job?

[h4rm0ny]

Well for mixing some C in with your D, you're laughing, as D supports C's ABI and all of C's fundamental and derived types. For C++, it's partial but you can extern to link to C++ objects. The D community is still quite small, but you'll find it heavily composed of C++ programmers going "wow, I like this." ;)

Re:Too little and too much, way too late

[0100010001010011]

XBMC
GitHub Source.

Make it stop.....

[jythie]

Stop trying to add more redundant features to C++... it is already getting progressively harder for C++ programmers to read each other's code and teach newbies what something means.

All this does is result in yet more more syntactic sugar to teach people in order to accomplish the same tasks they can already do with the older standards, and yet another round of relearning so you can tell what someone who learned a 'neat new trick' is doing. And of course you STILL need to teach the old methods to newbies so they can understand C++ code that they have to maintain.

Seriously.. this really does not help.

Re:Make it stop.....

[EsbenMoseHansen]

Some of us wants them. For you that do not, pass std=c++98 to gcc and be happy. Think of it as a new language :)

Re:Make it stop.....

[lgw]

Well, variable declared at the top of the function are the least evil c-ism. The real problem is a lack of understanding of RAII, and a fear of exceptions. The last time I read Googles C++ coding standards I died a little inside. People just don't "get" C++ for some reason.

Re:Make it stop.....

[shutdown -p now]

And suppose you're going through multiple parallel containers (what python calls "zip")? Then the new sugar doesn't work except for one container.

The sugar is meant for a simple case, just like Python's "for". When you need something more complicated, then - again, as in Python - you use a library solution. In case of zipping two sequences together, you'd use a zip_iterator. In general, you can also simplify many STL patterns by using Boost range library.

And STL is unwieldy mainly because of the need to explicitly spell out types everywhere. With auto in C++0x, most STL operations are much more concise.

Re:Make it stop.....

[EsbenMoseHansen]

Those ARE atrocious, are they not? Personally, my coding standing are usually "types looks like this, member variables like this, code nice".

Of course, the last bit takes a bit for people to learn, but it works nicer than a detailed standard, in my experience.

Re:Make it stop.....

[js_sebastian]

Stop trying to add more redundant features to C++...

Did you even bother to read about what these supposedly "redundant" new features are? Personally, I think these redundant new features will help maintain C++ as one of the 2 or 3 most used programming languages for the next decade. Especially since this time all of the new features already have reference implementations, so the compilers will be very quick to implement them (GCC already supports a long list of them).

I would say the single most important feature is finally having standard support for threading and concurrency. Hopefully, this will gradually lead to a standard library of high-level abstractions for parallel programming as well as concurrent algorithms (did you ever try the parallel mode of the gnu stl? parallel sort on 8 cores is sweet...).

There are also a lot of little tweaks under the hood, that programmers will benefit from even if they never need to know about it, just by using the STL. For instance even if you have never heard of move constructors, they will make some methods of standard containers more efficient and make it possible to have a proper implementation of the new unique_ptr (useful for Resource Acquisition Is Initialization paradigm). And most of the added syntax is straightforward enough that it doesn' t really add complexity:

Initializer lists:

vector<string> v = { "xyzzy", "plugh", "abracadabra" };

Range-based for+auto types:

for (auto x: my_container) {
...
}

Re:Trivial Count: 2

[MrEricSir]

We could add more, it would be a trivial change.

Re:Too little and too much, way too late

[Anonymous Coward]

Not that I disagree with your feelings but QT is a major C++ magnet -- of course you could argue that QT is a language on its own, not really C++.

Re:/puke

[Eudial]

Don't judge a website by the stylesheet.

Interview

[Mongoose Disciple]

I always preferred this interview with Bjarne Stroustrup.

(Yes, I know it's not real, but...)

Re:Interview

[Prune]

I wrote C for about 5 years and then switched to C++ with which I've stuck for the last dozen years. With that perspective, the article you linked to is such a lousy attempt at humor that it made me cringe. C++ has, like many other large entities with significant history, become a bit messy due to the need for legacy support given its huge installed base. This does not mean that you cannot write neat programs with it! It's easy to blame the language instead of the software developer. It is just a matter of a bit of attention and discipline to do great stuff with C++ even while using what some may refer to its more esoteric features like template metaprogramming etc. I could never give up things like multiple inheritance, which may require a bit of care during usage, but I've found to be the way to go in many situations. The majority of the C++0x additions are very welcome as well. What's really needed is a completely modern reference text that minimizes time spent on legacy issues. It's basically the same situation with OpenGL, which has become much larger in the 3.x and 4.x versions, while still supporting all the legacy code--and there is no proper reference so one usually sees a messy mix of 2.x and 3/4.x in most current projects, rather than a clean, organized design following the most recent variant. A proper text (other than the standards document itself) would make a huge difference.

Re:Too little and too much, way too late

[jythie]

I don't know, I see a LOT of C++ job postings. Most desktop and server application (designed for sale) development is still done in C++, and it is pretty common in middleware.

Could they not have named it something sensible?

[LordNacho]

See-plus-plus-zero-ex doesn't really roll off the tongue. How about something a bit easier? Super-C, C-flat, Cmega+ or something lame that people can actually say.

(Here's your queue to explain to me what the proper pronunciation is. AND the reason for picking such a weird name)

Re:Too little and too much, way too late

[JBMcB]

> Games developers, a few corporate app maintainers and...

Most Mozilla project applications including Firefox.. Pretty much all of KDE and some of GNOME. WebKit. Google Chrome. Opera. A good chunk of OpenOffice. Most Adobe applications. Most Microsoft desktop applications including Internet Explorer. CUPS. The Qt toolkit and pretty much everything that uses it. MySQL. Autodesk Maya. Winamp.

I wouldn't say a *few* corporate apps are written in C++, I'd say pretty much every major desktop app that's undergone a major re-write within the last two decades is probably C++.

Re:Too little and too much, way too late

[capnchicken]

I concur with your anecdotal evidence with my own observations and I share your opinions. But it seems like its moot compared to some of the hard data I've seen in the past.. It may be trending down, but it's not down yet.

I believe it is also a regional thing, C# seems to dominate the Mid-Western US with Java domination on the US coasts. With C++ being, well, elsewhere out of my ethnocentric regionalisms. Again, just my own personal anecdotal evidence.

yeah, void* was destroyed

[r00t]

Early C++ introduced void* and it was good. C adopted it.

Then C++ took away the automatic casting, I guess about the time C++ was first standardized. OK, now what is the point? The value of void* is gone. Now we write code with nasty casts. We can even hide the nasty casts in macros. Oh joy.

C remains fairly sane. There haven't been any serious fuckups since the trigraph disaster which no compiler enables by default. C99 is damn nice in fact.

Re:yeah, void* was destroyed

[Kaz Kylheku]

"void *" is a stupid misfeature, which I avoid in all new C code that is written by me.

C++ never took away the automatic conversion from "void *"; it never had such a conversion. C perverted the "void *" idea by adding that conversion. As recently as last week, I ran into a void * bug. Some stupidly defined third party API defined an important handle type like this:

    typedef void *handle_t;

A typedef for void * usually spells trouble. Anyway, one of the functions of this API is like this:

    int api_init(handle_t *phandle);

the cleanup is:

    int api_cleanup(handle_t handle);

The buggy program called both of them as api_init(&handle); and api_cleanup(&handle). Compiled without a peep, of course. C++ wouldn't help with this because this is a conversion to void *, not from void *.

In all new C code that I develop for my own projects, I now use some character type as a generic pointer-to-anything, and have explicit casts everywhere there is an unsafe conversion, in either direction.

The conversion from any pointer to object type to void * (allowed in C and C++) is itself braindamaged, because it gets you halfway to reinterpreting some memory without requiring you to confirm it or leave behind a piece of documentation in the code that can be easily spotted later (the cast).

C was better off before "void *", when malloc returned "char *".

In the Txr project (http://www.nongnu.org/txr/) I developed last year, I introduced "typedef unsigned char mem_t". After that, all generic pointers are "mem_t *". An allocator returns "mem_t *": All pointers other than unsigned char * have to be converted to and from mem_t * with a cast.

This works out beautifully.

Slashdotted, here is article text

[Anonymous Coward]

Interviewer: Well, it's been a few years since you changed the
world of software design, how does it feel, looking back?

Stroustrup: Actually, I was thinking about those days, just before
you arrived. Do you remember? Everyone was writing 'C'
and, the trouble was, they were pretty damn good at it.
Universities got pretty good at teaching it, too. They were
turning out competent - I stress the word 'competent' -
graduates at a phenomenal rate. That's what caused the
problem.

Interviewer: Problem?

Stroustrup: Yes, problem. Remember when everyone wrote Cobol?

Interviewer: Of course, I did too

Stroustrup: Well, in the beginning, these guys were like demi-gods.
Their salaries were high, and they were treated like
royalty.

Interviewer: Those were the days, eh?

Stroustrup: Right. So what happened? IBM got sick of it, and
invested millions in training programmers, till they were a
dime a dozen.

Interviewer: That's why I got out. Salaries dropped within a year,
to the point where being a journalist actually paid better.

Stroustrup: Exactly. Well, the same happened with 'C' programmers.

Interviewer: I see, but what's the point?

Stroustrup: Well, one day, when I was sitting in my office, I
thought of this little scheme, which would redress the
balance a little. I thought 'I wonder what would happen, if
there were a language so complicated, so difficult to learn,
that nobody would ever be able to swamp the market with
programmers? Actually, I got some of the ideas from X10,
you know, X windows. That was such a bitch of a graphics
system, that it only just ran on those Sun 3/60 things.
They had all the ingredients for what I wanted. A really
ridiculously complex syntax, obscure functions, and
pseudo-OO structure. Even now, nobody writes raw X-windows
code. Motif is the only way to go if you want to retain
your sanity.

Interviewer: You're kidding...?

Stroustrup: Not a bit of it. In fact, there was another problem.
Unix was written in 'C', which meant that any 'C' programmer
could very easily become a systems programmer. Remember
what a mainframe systems programmer used to earn?

Interviewer: You bet I do, that's what I used to do.

Stroustrup: OK, so this new language had to divorce itself from
Unix, by hiding all the system calls that bound the two
together so nicely. This would enable guys who only knew
about DOS to earn a decent living too.

Interviewer: I don't believe you said that...

Stroustrup: Well, it's been long enough, now, and I believe most
people have figured out for themselves that C++ is a waste
of time but, I must say, it's taken them a lot longer than I
thought it would.

Interviewer: So how exactly did you do it?

Stroustrup: It was only supposed to be a joke, I never thought
people would take the book seriously. Anyone with half a
brain can see that object-oriented programming is
counter-intuitive, illogical and inefficient.

Interviewer: What?

Stroustrup: And as for 're-useable code' - when did you ever hear
of a company re-using its code?

Interviewer: Well, never, actually, but...

Stroustrup: There you are then. Mind you, a few tried, in the
early days. There was this Oregon company - Mentor
Graphics, I think they were called - really caught a cold
trying to rewrite everything in C++ in about '90 or '91. I
felt sorry for them really, but I thought people would learn
from their mistakes.

Interviewer: Obviously, they didn't?

Stroustrup: Not in the slightest. Trouble is, most companies
hush-up all their major blunders, and explaining a $30
million loss to the shareholders would have been difficult.
Give them their due, though, they made it work in the end.

Interviewer: They did? Well, there you are then, it proves O-O
works.

Stroustrup: Well, almost. The executable was so huge, it took
five minutes to load, on an HP works

Re:Too little and too much, way too late

[mswhippingboy]

There's still a market for low level C programmers, and for Java, C#, Perl, Python, VB, and just about everything else, but who uses C++ these days? Games developers, a few corporate app maintainers and... uh... hang on...

Not sure if you're being facetious or not here, but C++ is consistently in the top 3 languages (the others being C and Java) in terms of popularity and usage. It's well above PHP, C#, Perl, Python, VB, Obj-C, and so on. I realize that stats from Tiobe index, Sourceforge, Langpop and other sources are merely an educated guess as to what people are really using, but the fact that nearly all agree on these three languages as being the top contenders seems to add credibility to their accuracy. It certainly beats the opinion of some individuals who are biased toward their favorite (or least favorite) languages.

kept alive by beardy wierdies and a few caffeine soaked kids who'll burn out and end up writing SQL for banks in a couple of years

Hey wait a minute! I resemble that remark!

Linking

[MrEricSir]

The biggest beef I have with C++ is linking.

Linking to a library that was compiled in a different C++ compiler (or even a different version of the compiler you have) is somewhere between painful and downright impossible; this is because function name mangling was never standardized and the core libraries are often incompatible.

Couldn't they standardize this in C++? It would make life so much nicer for those who deal in binaries.

Re:Linking

[shutdown -p now]

It can't be standardized in the language spec itself, because there's no notion of "object files" or even "linking" in general in the spec - it's not tied to a particular implementation technique. That's why you can actually write a conformant C++ interpreter.

Now a separate standard for C++ ABI is quite possible, and they do, in fact, exist. The trick is getting the compilers to subscribe to them, and the problem is that they already have their existing ABI (usually incompatible with other vendors), and moving to standardized ABI would break compatibility with libraries compiled with older compiler versions. It's not a big deal in Unix world where source code is generally available these days, which is why Unix compilers (e.g. g++ and Intel) converged on a common one; but Windows stuff is still broadly incompatible.

C++0x compiled!

[hackingbear]

According to Wikipedia, "C++0x" is pronounced "see plus plus oh ex". After three rounds of macro preprocessing, four expansions of template substitutions, and reversing five levels of dynamic cast operator overloads, the name is eventually compiled to something readable: C plus plus? Oh, my ex-programming language!.

Re:C++0x compiled!

[Prune]

I often wish Slashdot had an option whereby one could hide all posts moderated as 'Funny'--after all, it's Slashdotters making a judgment of humor...

Re:C++0x compiled!

[harmonise]

Look at your comment preferences. You can change the value that is assigned to comment moderation. Funny is at +1. Just change it to -5 and you'll never see another "funny" post.

Re:Could they not have named it something sensible

[Korin43]

Because it's still just C++. C++0x is just one particular version, like C++98 or C++03. Java 1.6.23 doesn't exactly roll off the tongue either.

Re:Too little and too much, way too late

[derGoldstein]

Let's ask Bjarne the same question: List of C++ Applications
Chop off half of the software applications on that list, at random -- can you still use your computer now? How about the internet?

Re:Multi-processor Extensions

[lgw]

The std::thread and std::async libraries should give you all the tools you need in a plaform-independent way. The popular compiler vendors seem to be eager for C++0x - once the standard is official, Visual Studio will do a patch, and I'm sure G++ will beat them to release. Many of the C++0x features are already there with the -std=gnu++0x option to G++, though I'm not sure if that includes the threading stuff.

Re:The problem with C++ is it's too powerful

[David Greene]

What is it about operator overloading that gets people all tied up in knots? An operator is just a function. It has a name, just like every other function. That name can be helpful or misleading, just like every other function. Operators are just functions. Really.

Re:c++ 1x sucks

[shutdown -p now]

It's a long time before anyone starts to use nullptr.

If you ever ran Visual Studio 2010, you have used a product that uses nullptr in some parts of its source.

(while we're at it, it also has C++0x lambdas)

Re:I Guess...

[shutdown -p now]

I never realized that the standard for C++ hadn't been updated in 13 years...

Actually, the last update was in 2003 - known, surprisingly, as C++03. It's what most C++ compilers these days implement. It was just comparatively minor, mostly bug fixing and clarifying ambiguous points etc. Though some new features sneaked in - e.g. it lets you write new int[10]() to dynamically allocate a default-initialized array.

Re:Too little and too much, way too late

[shutdown -p now]

That there is a code generator there is really an implementation detail. From programmer's point of view, signals and slots are really just a language extension, and could as well be implemented by the compiler directly.

Re:c++ 1x sucks

[jgrahn]

It's a long time before anyone starts to use nullptr. NULL is still shorter to type and too entrenched in the documentation.

In which documentation? "The C++ Programming language" mentions it twice, and says it's a C thing which you should avoid -- just use 0. Which is what I do.

Of course you can still *call* it "the NULL pointer" when you talk about it.

google cache

[WasteOfAmmo]

It is ugly as hell but it is readable... why more sites do not have a printer friendly page is beyond me (or I missed the link)!

Oh yeah, be prepared to scroll down a lot to get to the meat.

Page 1/3:
http://webcache.googleusercontent.com/search?q=cache:http://www.codeguru.com/cpp/misc/article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm&hl=en&client=firefox-a&hs=5K7&rls=org.mozilla:en-US:official&strip=1

Page 2/3:
http://webcache.googleusercontent.com/search?q=cache:http://www.codeguru.com/cpp/misc/article.php/c18357__2/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm&hl=en&client=firefox-a&hs=kN7&rls=org.mozilla:en-US:official&strip=1

Page 3/3:
http://webcache.googleusercontent.com/search?q=cache:http://www.codeguru.com/cpp/misc/article.php/c18357__3/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm&hl=en&client=firefox-a&hs=kN7&rls=org.mozilla:en-US:official&strip=1

Now since I have posted a comment like a good /.er I can go RTFA.

Re:Multi-processor Extensions

[Short Circuit]

Limited to your local desktop's CPU cores, written in C or C++? You probably want to look at OpenMP, probably combined with some compiler intrinsics for vector math. (Or you can use a third-party library which already does things like that.)

I'll note that, limiting yourself to your desktop's CPU cores cripples even the average web-targeted netbook. You'd be much better off delegating the number crunching to your GPGPUs. (Even my desktop's HD3200 integrated video chipset ought to be able to trounce my Phenom 9650 for a problem like that.)

Efficient use of parallel resources depends a great deal on the nature of the problem you want to solve. As the most demanding consumers of parallel resources push for even more capacity, more tools are developed. The more tools that get developed, the more complicated the problem is discovered to be.

There are efforts to take different approaches on the problem, primarily (from what I've seen) in developing alternate programming languages that try to neatly solve those problems that existing programming languages have difficulty with, but they tend to require thinking about problem solving from a vastly different perspective, and have their own systemic complexities and weaknesses.

In other words, in the area of parallel computation, programming is experiencing an even greater tower-of-Babel event than any other area of programming I'm aware of. This extends from libraries to language extensions, to languages and on through models of programming.

Re:Multi-processor Extensions

[scorp1us]

So, I am an unapologetic Qt freak.

It does everything pretty damn easily and extends your C++ compiler by using a MetaObjectCompiler (MOC pre-processor) and gives you most, not all, of what C++0xForever is promising. Platform independently.

Of you don't like Qt, then there is Boost. Both are just C++ libraries.

Re:Multi-processor Extensions

[lgw]

The core Boost classes were written by guys on the C++0x committee - they were written with the intent of becoming part of the standard library eventually. It's nice to have commonly used libraries incorporated into the language standard, especially to standardize cross-platform interfaces to platform-dependent stuff like threads.

But some stuff like Lamba just gets better syntax sugar if you change the language instead of using a library. While I'm not all that happy with the new C++ lambda syntax (what's wrong with making lamba a keyword, guys? same for you C# guys?), is still way easier than the Boost lamba syntax.

And some stuff like move semantics are just an outright fix to the language. Vector will stop requiring that Foo be copyable - finally!

Re:Too little and too much, way too late

[mswhippingboy]

And for a lot of C++ programmers, the word JAVA triggers the thought "Lego coder". It will change, no doubt.

I understand your point, but I would argue that a really good programmer that only knows a single language does not exist. I don't see how one can become a good programmer without a little intellectual curiosity which would drive them to experiment and learn other languages. I started out many moons ago with Assembler, Basic, Fortran and COBOL, tried LISP (didn't like it), moved on to Pascal and PL/I, then picked up C, followed by C++, tried Objc-C (didn't like it) then Java, Perl and later C#, Groovy, Javascript and various scripting languages. I'm now kicking the tires or Scala, Python, PHP, Go and Erlang. Not one of these languages is "unworthy" of me. Every one has it's merits and is interesting for their unique attributes (even the ones I didn't like).

C++ programmers who dismiss others with experience in these other languages are showing their ignorance , inflated ego, or probably both. If a C++ programmer makes statements like "Java scripters are not real programmers", chances are they aren't nearly as good a C++ programmer as they think they are.

Re:c++ 1x sucks

[Homburg]

NULL is defined to be integer 0 in C++, so you have to do these workarounds when you use NULL, as well; indeed, one of the advantages of using 0 is that it serves as a bit of a reminder that you need to keep these workarounds in mind.

Re:Multi-processor Extensions

[SomeKDEUser]

lamba is not a keyword for two reasons:

a) it mostly evokes elvish pastry (properly spelt lembas)

b) lambda (/\), the Greek letter, is very common in scientific code, and making it a keyword would be painful.

Re:Oh God!

[icebraining]

Many games use two languages (C++ for the core, and something like Lua for the game logic) and it works perfectly fine.

Re:Could they not have named it something sensible

[simula]

C++0x is the draft name. If it is published by the ISO in 2011 then it will be C++11.

Re:c++ 1x sucks

[shutdown -p now]

The reason nobody has ever wanted lambdas

Why do you speak for other people? I don't know a single experienced C++ developer who wasn't excited about lambdas. For one thing, they finally make STL algorithms actually usable, because you don't have to write insane amount of boilerplate.

For that matter, consider the fact that someone bothered enough to write Boost.Bind and Boost.Lambda, and that even more people used that. This alone shows that a lot of people wanted lambdas.

they're ugly, confusing, and difficult to maintain.

Ugly is subjective.

Confusing - every mainstream language today except Java has them. Heck, VB - VB of all things! - has them, and VB code monkeys don't find it confusing. Perhaps you should catch up with times?

Difficult to maintain - what, more difficult than hand-written functors with explicit state capture and all that entails? I highly doubt so.

The code is cleaner and better formatted using an actual function.

When comparing lambdas to functions, you miss the crucial point of lambdas, which is the fact that they can capture state - that's what makes them so useful. If you e.g. need a function object to pass to std::find_if, and you need to compare against a value of the local variable in that function object, it's trivial to do with lambda:

int foo(int x1, x2) {
    std::vector<int> xs;
...
    auto iter = std::find_if(xs.begin(), xs.end(), [&](int x) { return x >= x1 && x <= x2; });
...
  }

The above is concise (compared to the old way, anyway; Rubyists would probably chuckle), and perfectly clear in its intent.

On the other hand, you cannot use find_if that way with a plain function at all. You can do it with a handwritten class with overloaded operator(), but then you have to declare the field to save the state, and make sure you initialize it properly. What's worse is that it's tucked away from where it's actually used, so the call to find_if is that much less readable due to need to jump to the definition of the class.

Re:Could they not have named it something sensible

[marcosdumay]

I hope we are not using C++ anymore by 2098...