Stroustrup on the Future of C++

/ASCII writes "Bjarne Stroustrup, the father of C++, has written an essay [PDF] on the features of the upcoming C++0x standard. In his essay, he argues that new features should whenever possible go into the standard library and not into the language, but that the language needs to shave of a few rough corners to make it easier to use for novices."

Comments

Dynamics in programming languages

[jurt1235]

It is interesting to see how an abstract language like a programming language evolves through time. I would think that in a language like C++ the more userfriendlyness should be in the libraries and not in the language, so I agree with the author on this point. Putting it in the libraries makes it better backwards compatible, and distributable.

a 'few' rough edges

[leomekenkamp]

Shaving off a 'few' rough edges to make it more easy for newbies... It's that what Sun tried to do? (hint: java)

Re:a 'few' rough edges

[leomekenkamp]

Yes, I know these are fundamental changes, that's why I put the word 'few' in between quotes.

Point of fact stays however: c++ has an enormous learning curve. Complexity in the language is imho comparable to Latin: you can almost recognise the author by lookin at the code. That complexity is far, far less in java.

Especially the gc makes life a lot easier for even seasoned programmers.

And by the way: you can be almost as un-OO in java as you can be in c++. Introspection in java is mostly used in 'frameworks', like for instance the serialization API; normally you almost never use it.

Re:a 'few' rough edges

[orthogonal]

Shaving off a 'few' rough edges to make it more easy for newbies... It's that what Sun tried to do? (hint: java)

Java's ok, but a few mistakes were made. Among the worst: over-reliance on the instanceof operator, and the need for something called a MethodNotSupported exception.

Now think about what MethodNotSupported means in the context of Barbara Liskov's Substitution Principle:

We've got a language that supports inheritance. Inheritance makes sense only insofar as Liskov's Principle is followed. Put simply, if class D inherits from class B, any "promises" that B made -- it's interface, both syntactically, in terms of public member names, and semantically, that the member functions really do do some particular thing -- any of those promises must also be kept by D, because we are saying, as Liskov tells us, that D is-a B.

If I hand you an instance of D, and you plug it in place of am instance of B, anything that the B instance does, the D instance must at least do. Otherwise, how can you safely and with confidence substitute a the D in where the B used to be?

But along comes Java, and the MethodNotSupported exception -- a method used by some of Java's core library, including, dismayingly enough, commonly used container classes. It's used so that a derived class can suddenly and at run-time throw it, telling you, "Whoops! Ha ha! Trickled you, I can't in fact really do what B promises! I claim I'm a B, but really, I'm not!"

Now imagine you had a component stereo, and you replaced your tuner with a "better" tuner with all the same jacks as the original. You'd plug it in and expect it to do the same work as the original tuner, just with better reception or fidelity or whatever. Now what if you plugged in the new tuner to the old connections, and suddenly its display read: "Sure, I have a two-plug RCA input, but it's not actually connected to anything, so you can plug in an RCA jack but no sound will come out". That's what having a method that throws MethodNotSupport is like: the jack -- or member function name -- is there, but the implementation is not.

D inherits ("extends") B, it says so right there on the label, but no sound comes out. With Liskov undermined, you don't really have an object oriented language at all. You don't really have true inheritance. What you have is a sham, a sham that can break down on you at run-time because an object is lying to you.

And the upshot is that you don't see enough real object oriented programming by client Java coders. If the core library can get it that wrong, why should clients of that library bother to adhere to a standard?

So you get lots of java code that does RTTI using instanceof and if( p instanceof Foo ) ... else if( p instanceof Bar ) ladders rather than calling p.virtualFunction(). Because coders won't take seriously OO that the language and its core libraries don't take seriously.

Re:a 'few' rough edges

[orthogonal]

"That exception lets you know when you're breaking an API contract -- though a List may have add() methods, if you want that List to be immutable, is it preferable to throw an exception from a mutator or remove the mutator from the subclass completely? Or should we just take add() out of the List interface?"

If those are the motivations, we should have an ImmutableList class without an add function, and derive the List with an add function from it (in C++, probably by private inheritance, that is, inheritance of implementation). Only the List class with the (working) add should publically inherit from the interface with an add function.

Problem solved.

"I could read stupid C++/D/C/Ruby/whatever code and then blame the language too, you know."

Sure, sure. Don't be touchy. I code Java too, in fact I'm Sun Certified.

What I'm saying is, you tell me you'd "fight" unnecessary uses of instanceof, and I believe you. I'm just trying to make your fight easier. The point is, if your core libraries don't take liberties, your fellow client coders will be less likely to -- or at least less likely to use the bad example ("but the core library does it, why can't I?") when a good java programmer, like you, points out the problem.

Re:a 'few' rough edges

[SerpentMage]

Yes it forces you to do all of the things that make you productive.

Now getting back to C++, you are not forced to do anything except write code like the following:

T & list::iterator::operator* () const
{
return current->data;
}

Yeah I suppose this is obvious, and simple! (NOT)

I completely gave up on C++ about six months ago. Before that I was half in and half out. Having read BS's article I have to say I am glad I gave up on C++.

I have talked to multiple people who regularly develop using Python, C#, Java, etc and they hate the fact you have so many little details in C++. If you look at my little C++ example look how many details a coder is supposed to take care of. It is insane!

Oddly enough, people still like C. I suppose it is a simple and effective language to get low level coding done.

Re:a 'few' rough edges

[Anonymous Coward]

If those are the motivations, we should have an ImmutableList class without an add function, and derive the List with an add function from it

Then you're saying that a List (which is mutable) is an ImmutableList. That's wrong. You could be passed an ImmutableList from other code and be surprised when it changes.

Better to name the superinterface List (which makes no statement about mutability or immutability) and have no mutable operations on it. The subinterface would be named MutableList and add the mutators.

Re:a 'few' rough edges

[Anonymous Coward]

In the case of this List wrapper, you'd want an instance of it, not to derive from it.

It's really a whole in the ideology in the language, not the language itself. It tries to be "the OO language" and fails on a very important point.

That being said, in the real world, it's design by contract and you should never use a method without looking at it's contract (which in java is the javaDoc), which better say "This function will uncoditionally throw a UnssportedOperationException."

Re:a 'few' rough edges

[renehollan]

Boy, that sounds like a slooow way to replace a lookup table. Programmatically it may be more elegant, but certainly not equivalent speed-wise, which is the real purpose of a lookup table.

You appear to miss the point. It may very well be slow, and probably is, but it is slow at compile time, and generates the fast table for you to use at run time.

In practice, I've written some knarly templates, and have not found the compile speed to be all that bad.

Is threading going to be abstraced out ?

[Gopal.V]

Stuff that went into Boost should be in the standard library from now on... Also anyone who has had to use g++filt will agree with me that C++ STL error messages need to look less like the dog's breakfast :)

A better wheel

[Anonymous Coward]

Am I the only one who wonders why we need a successor to C or C++?

I've sat through the past 10 years and watched things like Java and D and Objective C come, but meanwhile most serious OS level and game development continues to be in C or C++. Doesn't this demonstrate that new language are merely a distraction to developers who haven't fully exploited the current set?

Re:A better wheel

[onnel]

No, it's more a signifier that different problems need different solutions. If all you have is a hammer, everything may look like a nail, but if you know c++, perl, php, java and a few others, your toolbox will contain an appropriate solution for a broad range of problems. I write my games in c++, my websites in php and my text parsing utilities in php. Java and python also serve their niches. Anyone who believes that a single language is the best solution to all of the broad range of problems faced by programmers is sorely mistaken. Onnel

Re:Dogma

[Misroi]

C++ is just fine the way it is. If you want a language like java, go with c#.net

and you can also code c++.net, which has the option to use the .net framework and the .net garbage collector.

my personal opinion is c++ should stay exactly like it is. The more libraries the better. if you want some high level language, use c#.net. If you want a headache go with c++.net.

What we need is "Smoothed out" people...

[brockbr]

Every time a cost of entry is reduced and the expected prerequisites are thrown aside, the result is a truly less capable *person*, not a more capable tool.

Agreed - There are some things that need smoothing, but I for one am tired of dealing with people who lack a fundamental understanding of the *systems* as a whole. Examples of this are the folks coming out with CS degrees who aren't even capable of following a thought, let alone starting an actual career designing and developing software.

For them, a tool like Java offers an entry level that is acceptable given there current capabilities - A tool geared towards THAT user (and a fine one at that).

But C (and C++) can be leveraged by people who know the tool and *use* the tool for what it can do, even with it's high(er, intellectually) cost of entry.

Expected release date

[thammoud]

2020. Good luck getting all the stuff in. Long live open standards.

Syntactic candy.

[mcc]

This is mere unnecessary conveniences. What exactly are they giving us here? Well, if I'm reading this right, "C++0x"* will give us:

• Some cases where you can type ; where previously {} was necessary, saving as many as two keystrokes.
• The lexer ambiguity where a<b<c>> and a<b<c> > meant entirely different things is fixed, saving as many as one keystroke.
• EVEN MORE "free" constructors which may or may not work quite the way you wanted them to in practice.
• More "fancy cast" operators, which sounds nice until you remember that if there's ever a time you find yourself using the C++ "fancy cast" operators, then there is a damn good chance that it's because you're doing something unwise enough it really would be a better idea to refactor the code to make the "fancy cast" unnecessary.

...in the meantime the fundamental issues with C++ remain not only unresolved, but unaddressed. The template system is still not a generics system, but an ugly cut & paste macro system which can incidentally be used for generics, with some caveats. The class system is still fundamentally brittle and unfriendly to simple things such as upgrading a DLL or determining at runtime if two objects are of the same type. The syntax is still a forest of features whose features interact in ways so crazy and unpredictable it approaches Perl in its chaos; references are still gimped; the distinctions in behavior and use between static and dynamic objects remain awkward and newbie-unfriendly. The features that people obviously desire to have in the language as demonstrated by their tendency to hack them in with third-party libraries (like BOOST) are-- they tell us-- a good thing, and they tell us we should continue to hack them in with libraries (like BOOST). That's nice. You know, that would be a lot easier though if we had a macro system** capable of anything smarter than blind code cut and paste-- or at least a macro system** fundamentally designed to be used for anything at all other than generics.

Meanwhile, it appears if I'm reading this right that the most important differences in C++0x will be changes to the standard library. Great. The STL was defined how many years ago, and it's only just in the last few years that compliant implementations have become commonplace? How many decades will it be before the "C++0x" library changes have become common in a cross-platform compatible way?

C++ is an extremely useful language, and making an update to C++ which changes as little as possible so as to follow some kind of "if it aint broken don't fix it" principle is an idea which makes a whole lot of sense. However it seems likely to me from reading this that C++0x will offer so little significant difference from C++ as to make itself simply redundant.

* ("C++0x". Were they specifically trying to come up with a name less convenient than "C#"? Ah well, I guess we can call it "COX" or "cocks" for short.)
** "Template system"

Re:Syntactic candy.

[NFLFan]

# Some cases where you can type ; where previously {} was necessary, saving as many as two keystrokes. # The lexer ambiguity where a> and a > meant entirely different things is fixed, saving as many as one keystroke.

I don't think it is about saving one from typing but preventing errors. An expierenced C++-er knows to avoid >> with templates but does a beginner? The error messages can be less than great with templates- so avoiding one is all the better. The error message that g++ now seems to give is helpful but so annoying saying something like "you used >> where you wanted > > ... [c++ template garble]."

EVEN MORE "free" constructors which may or may not work quite the way you wanted them to in practice.

That sounds like a very ignorant argument. I used this constructor but it does not do what I want it to, is it wrong?

More "fancy cast" operators, which sounds nice until you remember that if there's ever a time you find yourself using the C++ "fancy cast" operators, then there is a damn good chance that it's because you're doing something unwise enough it really would be a better idea to refactor the code to make the "fancy cast" unnecessary.

I assume the current fancy C++ cast operators you are talking about are static_cast and dynamic_cast. With the lack of multi-methods and it being an error to downcast an object c-style I think the need for static_cast and dynamic_cast are clear. The only good clue to maybe needing to refactor an hierarchy is when it is unsafe to use static_cast in place of dynamic_cast (when you know the type), times when you have virtual base classes and other goofy instances.

How about a module system?

[putko]

More powerful languages like ML, CAML and some Schemes have a module system. This allows the programmer to control the meaning of identifiers (e.g. what function they mean). E.g. what gets imported (and with what name), what gets exported.

Often there is a separate notation for the modules -- it says what files contain the things, what's exported/imported etc.

That's very useful for encapsulation.

C++'s namespaces are a crappy attempt to get the benefits of a module system -- that's likely where he got the idea from.

Hygienic macros would be a good step too.

Re:C++... always the ugly step-kid

[NDSalerno]

Here here! In the realm of native application development I have programmed in C++, Delphi, and Eiffel. Each language has its pros and cons. C++ is no doubt the most popular and most successful of the three. However, I have been most productive and had the most fun with Eiffel and Delphi. Some might be quick to say I am not experienced enough with C++ or that I haven't learned the idioms. I have programmed in C++ for many years. I have read all the books written by Stroustrup, Scott Myers, Herb Sutter, Andrei Alexandrescu, etc. I regularly read the newsgroups and paid attention to Sutter's Guru of the Week articles. With all that under my belt I still make mistakes. Why? In Eiffel and Delphi a statement of code can do one or two things. In C++ a statement of code can do several things, some of which incur side effects of their own. If you don't understand these behaviors then you write buggy code. Or, in other words, C++ is complex.

The hardcore crowd will tell you that ultimately you are better off going with C++ because of speed and power (implying that every other is a step above Visual BASIC). NONSENSE! Delphi is on par with C++. In certain situations C++ is more efficient than Delphi. In other situations Delphi is more efficient than C++. In the long run they are both the same. The only thing Delphi can't do is metaprogamming. Big deal. I can write my number crunching algorithm in C++ templates and wrap it in a library that Dephi can call. Problem solved. You know what C++ can't do elegantly? GUI development. It's tortuous. C++ Builder doesn't count because the language is modified and is not ANSI C++, which should really tell you that there is truth in the statement that C++ lacks some features. Qt has always been my favorite ANSI compliant GUI library. However, even Qt is a testament to the needed addition to C++. The meta-object compiler?? As if my compile times weren't long enough?

I have debated on the C++ newsgroups about accepting Borland's C++ extensions to the language, namely properties, closures, and reflection (advanced RTTI). I admit that boost does have a way to implement closures as template classes. They work and are efficient. My only dislike is that the syntax is too cumbersome. But I'll let that go. However, it has been argued and proven that properties CAN NOT be implemented as a class library without overhead. They simply must be a feature of the language. Combine that with better RTTI support (reflection capabilities) and you will have some powerful new tools to make elegant designs. And no, I am not advocating using RTTI for general development. Obviously if you have to test your base class pointer to discover the actual child type then your design is flawed. But that does not mean RTTI is as evil as goto statements. Properties and reflection is superior in the domain of GUI frameworks. GTK++, MFC, Qt, etc., should be proof enough that GUI libraries are too cumbersome without properties and reflection.

A lot of people ask for C++ to have some kind of GUI library but I do agree with Stroustrup's rationale for why that is not possible. There is no common denominator of design that would make sense for every platform and would appease everyone (whom has their own opinions on the design of a GUI framework, which are radically different). It is better for C++ to rely on third party libraries that deal with GUI development. That is fine for me. What I ask for is that we improve the language to allow better development for these third party GUI libraries.

Outside of GUI development, properties can be useful. The hardcore group, however, always argues against syntactic sugar because it is somehow pointless. This may be true for computer scientists. It is not true for software engineers. I always welcome any kind of help in reducing bugs. Syntactic sugar can actually help. To say it briefly, Delphi and Eiffel read like English. C++ reads like machine language. Guess which group of developers is going to have a higher defect rate?

Nicholas

Re:Waiting for C++ 2007 lite ANSI standard

[grahamlee]

I think the OP would have got on better with "mindshare" than market share...but that's just an aside. I agree that C++ and C#/Java/Objective-C object models cannot be considered supersets or subsets of each other, and think that a language which was "C++ but with C# inheritance" would not be a useful language. At least it wouldn't be a language offering anything significant that others already don't - it would be like Objective-C with static compile-time method lookups. I've never particularly got on with multiple inheritance (I'm an ObjC protocol/Java interface man) but it has its uses to a lot of people - I think it seems like a first go at aspects. Get rid of it and whatever you end up with may be of use to someone, but C++ it isn't. My particular issue with C++ is that which BS seems to be warning against - unlike him I already think there's far too much in the C++ language that should properly have gone into the standard library. For me, OO languages should be like Ruby or ObjC - give me a way to manipulate objects, then give me a bucketload of objects. On the other hand, it's possible to go too far in the opposite direction and end up with a designed-by-committee API like Java which bloats with every new release, because someone somewhere didn't like a particular package and decided it needed a complete reimplementation (but we can't deprecate the existing one for another release or so).

Re:The future of C++...

[Nasarius]

... is extinction. Just stating a fact here.

Obviously. The same goes for any language. But what do you propose to replace it? The vast majority of "modern" languages are not compiled to machine code. For the moment, C++ is a good balance between the efficiency of C and the user-friendliness of higher-level languages. It fills a niche (resource-gobbling 3D games, operating systems, compatibility with C/C++ libraries, etc) that no other language does.

Re:How about...

[CptNerd]

..we wait for people to actually understand amd implement the current C++ standard?

Unfortunately, because the spec is so convoluted, you can implement some aspects in completely incompatible ways, and still be "implementing the standard."

I've been in the profession for over 20 years, and I've seen the same thing happen to certain "standards". Something new and innovative will come along, and within a decade, features will be added that will make it unusable, and foster the demand for "something like X but easier/simpler/faster/cleaner". Most of the feature creep is driven by large corporate interests and the demands of their programming staffs to add features that they claim they can't develop without.

Not many people remember X Window 10R4, but the entire Xlib documentation took up a half-inch thick stack of single-sided pages, and described a basic networked window system that was useful enough to develop distributed systems with. The protocol was easy to implement, straightforward, and clean. But that wasn't good enough for the wonks at Apollo, DEC, HP, Sun, AT&T, and the researchers at MIT. So, once everyone added their "must have" requirements to X Window (we have to have font servers or we can't write good systems!) you ended up with a monstrosity of an Xlib spec that took up a thousand or so pages of documentation, added thousands of new points of failure, and spawned an entire bookshelf from O'Reilly just to try to explain how to use X.

I saw the same thing happen to C++. In the early days it was what it set out to be, a simple, easy to implement extension to C that let you do basic object oriented programming. Sure, it wasn't Smalltalk or Scheme, but it was good enough for 90% of the tasks that really needed simple lightweight objects. But, certain vested software interests demanded that the spec be extended to include things like templates and virtual this and that, all designed to save some corporate programming group some design time, at the expense of creating a spec that required Talmudic scholars to interpret.

I've been on the outside of Java, watching it since it was first described, and I've seen the changes and additions to the language spec over the years. The same thing is happening to Java that I saw happen to X and C++, and I predict that in 10 years or so someone will come out with a language "that does what Java does without all the overhead". I knew Java was doomed to follow the C++/X path when they announced namespace support in the language. Sorry, Javaheads, but that was the tipping point, and you're all on that long slide into obfuscation and bloat that many derided C++ for.

I know many who actually read this post won't believe it, will argue that "Java is different" somehow, but mark my words, Java will bloat into uselessness within 10 years, just like C++ did.

Two important additions

[ardor]

1. signals & slots. These *must* be introduced. Event handling is a breeze with them.

2. make it mandatory for allocations to be deallocated in the heap they were allocated, that is, for example if you allocate memory with new or malloc() in a DLL, and you deallocate it with delete or free(), then the deallocation must be done in the DLL. This could be done with some tables storing the heap for each allocation. This is *very* important if you work with several DLLs in your project, since if you deallocate something that was allocated in a different module, the system crashes because you try to deallocate in the wrong heap. Especially STL containers cause a lot of trouble with DLLs.
Well, this can be solved by overloading the new & delete operators; also, choosing "multithreaded DLL" as CRT in VisualC is a solution, since then all "multithreded DLL"-Modules share the same heap. Nevertheless, this is something that should be dealt with in the language.

Template madness

[Anonymous Brave Guy]

Stuff that went into Boost should be in the standard library from now on...

Oh God, please, no!

C++ desperately needs some basic functionality in its standard library: concurrency, GUI, maybe things like sockets. (Alas, by the standards committee's own admission, some of these -- particularly the GUI one -- are unlikely to happen.)

What C++ doesn't need is for its relatively simple but useful standard library to be overwhelmed by every template freak and his brother's pet ideas, which is very much the direction a lot of the "in crowd" and a lot of Boost contributors are tending towards at present.

By all means, let library designers use whatever language features are useful in whatever ingenious ways they can, but please let the interface for anything that actually gets into the standard library be simple and effective, not infinitely customisable but massively over-complex. That means some parts of Boost would be excellent additions, but others certainly would not.

Re:wait a moment...

[Kurt Granroth]

Not when it's God talking

Speaking of which, did anybody else notice the author description in that article?

"Bjarne Stroustrup is the College of Engineering Professor in Computer Science at Texas A&M University"

What!? Isn't that like saying the George Bush is a businessman from Texas? It's technically true, but completely misses the point on what matters.

This makes even less sense when you try to find the target audience. If the person reading the article already knows who Bjarne is (by which I mean every single C++ programmer), then I could see them omitting the entire "creator of C++" description because, well, they already know... but then why have a description at all?

If the person doesn't already know who this "Bjarne" is and they are reading the article, don't you think they'd want to know that he created the thing and therefore might have some relevant opinions on that matter?

Very odd...

Re:Yeah about that standard library...

[MobyDisk]

You are frustrated because you misunderstand the definition of a programming langauge. Programming languages don't provide APIs. Let me quote from the Wikipedia:

A programming language...is a standardized communication technique for expressing instructions to a computer. It is a set of syntactic and semantic rules...to precisely specify what data a computer will act upon, how these data will be stored/transmitted, and precisely what actions to take under various circumstances.

This definition does not include GUIs, graphics, or sound, or networking, or even file I/O. A language is used to describe allocating memory, and performing if/then/else logic, and describing data structures. Some examples of programming languages are: C, C++, Fortran, LISP, COBOL, TCL, Prolog, and shell scripts. Java is only a programming language if you remove the libraries.

What you are looking for is often called a platform. The Java platform ships with the Java language + a series of libraries that give you graphics and sound and networking.

If you treat C++ as a platform, you will be forever frustrated. If you are looking for a platform based on C++, I recommend C++ + POSIX + GTK. Most of the time I use C++ + Win32 as my platform. Try this, and you will be far less frustrated.

Oh, and just to make it clearer: If you want, you can use C++ + AWT or C++ + Swing if you want. The Java APIs are fully callable from C/C++. I don't recommend it because it defeats the purpose of using an low-level language like C++ if you then include a big virtual machine, but if you like the Java APIs, you can do it.

Strostrup is in denial

[Animats]

C++ is in deep trouble, and Strostrup is in denial about it.

C++ is the only major language with extensive abstraction but without memory safety. All other major languages are either memory-safe or don't hide the underlying machinery. (Java, C#, VB, Perl, Python, etc. all have automatic memory management. Some use garbage collection; some use reference counts. C is unsafe, but hides nothing.) This fact is responsible for millions of program crashes every day. Most security holes in C++ code come from this problem. Java and C# were invented primarily to eliminate the safety problems of C++. The open source community has generally stayed with C, where at least you can see by examination what's going on. C++ is losing market share to Java.

And Strostrup denies this is a problem.

This has happened before. Last time, it was Wirth. Wirth designed Pascal, Modula, and Modula II, but refused to admit that each had serious problems. He fought external compilation in Pascal. He fought extensions to the language. He even fought compile-time arithmetic. In the end, he took Pascal from a major language to a historical footnote.

Serious systems programming was once done in Pascal, but not in Wirth's version of it. The original Macintosh and Lisa software was written in nonstandard versions of Pascal. And much of the DOS era was built on Turbo Pascal. But proliferating nonstandard versions of Pascal caused another set of problems.

C++ has been in decline for years. "Evans Data has found that the percentage of developers using C++ has steadily declined over the last six years--from 76 percent in the spring 1998 to 46 percent in fall 2004." Strostrup also denies that.

The C++ committee has been taken over by template fanatics. Most of the committee's effort revolves around obscure template features that few will use, and which no responsible programming manager would allow on a mission-critical project. There's very little interest in language safety, and a vocal minority that insists language safety is undesirable or impossible.

All is not well in the C++ world. Claming otherwise is irresponsible.

Re:Strostrup is in denial

[I judge you]

C++ is the only major language with extensive abstraction but without memory safety

And for that, I thank C++.

C++ has been in decline for years

Who cares? It's not dying. It's more an effect of the mass over-hyping of C++ in the 90's. When the crowd moved onto Java, the C++ scene gained...

vocal minority that insists language safety is undesirable

The tradeoffs involved make it undesirable. It's a fundamental architectual choice of the langauge, with undeniable performance implications. If you want safety above performance, go use another language.

I juge you: ass

Re:Strostrup is in denial

[Anonymous Coward]

Automatic memory management, as in reference counted smart pointers, are in boost right now, and will be in the standard. The 'obscure template features' are actually used to create these things. There is lots of interest in language safety, and templates are used to create the means for this.

The main problem with C++ is that everybody thinks it's C and the 'class' keyword. templates and the STL seem too scary and too bloated. Well, they are not. Learn them. *Test* if they are bloat. Find out they are not. AFter that, learn C++ as it is meant to be. I know what I am saying here, as I had to do this myself.

The problem with nice words...

[devphil]

...is that they're already in use.

Remember that, when the language syntax was designed, the idea was that every conforming C program would also be a conforming "C With Classes" program. Identifiers like "abstract" and "interface" were already in use as user variables, types, functions, etc.

I think you would be pretty pissed off if the next revision of your dawn-to-disk programming language suddenly made "foo" or "i" a reserved keyword. :-)

Time has passed and the two languages no longer fit together like that. Hell, they barely resemble each other anymore. But even ignoring C, now there are valid C++ programs which use "abstract" and "interface" as identifiers, so the problem remains.

Re:Dogma

[Deviant Q]

Today the battle is between Java and C++ and Java wins. Not because it's faster, because it is more convenient.

Actually, I'd urge anyone who thinks this is the case to consider C#. Yes, I know it's Microsoft, and yes, I know there's .NET involved, but...

I just love that language. It's a pleasure to code in; it fixes everything (IMO) that Java did wrong; it's very powerful and intuitive at the same time; the .NET framework class library is absolutely wonderful... I could go on and on. It's just awesome.

The only thing that pissed me off about it was the lack of templates, which (just like in Java) gives you some crazy boxing/unboxing issues like int i = (int)myArrayList[0];, but with templates ("generics") in 2.0 that's all fixed. It's beautiful.

Balance between ease of use and features

[Mingco]

The perfect balance of ease of use and richness of features for C++ is defined thusly:

If any novice is able to pick up Bjarne Stroustrups' The C++ Language and beat him within an inch of his life... but no more, then the book is perfectly balanced between ease of use and richness of features.

As it currently stands, I believe that every second or third novice would easily be able to beat Bjarne to a messy, bloody pulp almost as ugly as the code his language engenders.

It's far too late

[pammon]

"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -Tom Cargill

The largest problem with C++ is its complexity. It is not just too complicated, it is *unmanageably complicated.* Some of the symptoms are:

• The STL has inexplicable omissions. For example, there's no portable way to seed the built-in PRNG in the random_shuffle algorithm, rendering it useless.
• Guruhood isn't good enough. Consider the seemingly simple task of creating a stack that works correctly with exceptions. It's extraordinarily difficult even for a guru.
• Language features interact in nonintuitive ways, producing a combinatorial explosion. For example, if you overload a function in a class, you don't have to use the scope resolution operator, and if you override a function, you don't have to use it either - but if you do both, you DO have to use the scope resolution operator or else you get a compile error!

Insofar as the new C++ standard adds stuff, instead of simplifying, this will only get worse. Since it's unreasonable to expect a new standard to remove features, the problem is unfixable. The result will be that programmers carve out their separate comfort zones, compiler vendors will not implement all features, and the monolithic C++ language will fragment into a Venn diagram of sublanguages. More so than today.

The article looks like a promotional prop...

[iskander]

and Bjarne sounds as if he were rehearsing his pitch on the eve of a product launch. As if C++ needed to be re-launched! I wonder whether he does this because he fears people's reaction to the new standard. In any case, it seems he hopes to preempt a good deal of criticism by manipulating our view of the standard's gestation ahead of the release. We've seen this kind of thing before, haven't we?

Technique Before the launch, persuade clients to believe that the product's development was/is governed by core values they already hold. Result After the launch, clients are less likely to look at the product critically and dispassionately because they are already satisfied that it respects their core values.

But maybe that's what a language creator ends up having to do if he wants changes to be widely accepted and (more importantly) adopted so that the language does not become stale. Yes, "the end justifies the means" and all that jazz. That might account for the delay in the delivery of Perl 6 and the endless series of Exegeses and Apocalypses and Ecclesiastes and whatnot.

What I don't fully understand, then, is why Bjarne spoils an otherwise excellent pamphlet by indulging in the pointless denunciation of enumerations as an "odd and isolated feature" born of or comparable to (it's not clear from the phrasing) a "random extension" that was included in the standard due to operational deficiencies in the standards process. Is this flamebait, tossed our way to draw attention to his article and to the standards process? Certainly, he isn't trying to discredit the process by acknowledging the inevitability of incorporating "random extensions" that would later become "odd and isolated" features, is he?

Re:C++0x? D!

[jma05]

There are a LOT of things better in D than C++. D is far better language (not library) enhancement over C++ than Java/C#. Take a look at language comparison at http://www.digitalmars.com/d/index.html I do not use D however. I don't do much of systems programming and I fancy IDEs but language wise, D is perhaps the best imperative, native compiling language out there at the moment.