Slashdot Mirror
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."
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.
My wife's sketchblog Blob[p]: Gastrono-me
Shaving off a 'few' rough edges to make it more easy for newbies... It's that what Sun tried to do? (hint: java)
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
.. as to the pronunciation of 'C++0x'. Any suggestions ?
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?
... its embarasing. Compare it to CPAN (perl) or Java. It can't do very much. I wish they could get some real functionality in there. Adding the Boost stuff is nice but. What some something like Java's SWT where you can write an entire GUI using the standard library. Now that would be an improvement for C++.
.h header files. Call it the standard and let vendors code it out. Sweet!
I would be very easy to do. Just "steal" the API spec's from Java. That's what C# did. Just recode the entire Java API into some C++
Why do we need this? D is a beautiful, well-appointed systems programming language. It's got a gcc front-end. It's got garbage-collection if you want, custom memory management if you want. It's got embedded assembly if you want. And it's fast
I thought we were staying with C++ because of all the code that's already written in it...
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
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.
I program in C++ from dawn to dusk, and a few things really irk me about it:
1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.
2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?
3. Operator new and delete were designed by someone on crack. The only way to call a constructor is with placement new, whose syntax looks like: new (var) type(). Placement delete, however, doesn't call the destructor, which must be invoked manually. Furthermore, delete can't take parameters like new. What.
4. There is a "typeid" operator but no "typeof" operator. GCC has an extension for this, but it's not standard C++ I think.
I'm sure there are other language constructs that have annoyed me, and if you don't read my mind and fix them, Bjarne, I will kick you in the pants!
If you say "here goes my karma" I will bite you!!!
In no way. If you read the B.S. writings (and I recommend he favor the world with a middle initial) he is always concerned with teachability of a feature, which is pretty understandable when you consider he's an academic.
Now, what an academic is doing having a successful programming language with real-world applications is another question...
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I won't argue the relative merits of C++ to other languages. For many organizations, switching from C++ (regardless of whether it would make things easier) is often not an option, and not considered as an option. I will also not argue whether that is bad.
... For Great Code!
The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.
I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.
For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).
Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".
Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.
Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.
A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers,
- 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"
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
"I sometimes find distributing an extra 30 MB [the .net run-time] a bit inconvenient."
Please download my new folding bicycle! Its lightweight aluminum frame means it's easily portable and rugged too! when not biking, fold it up and carry it under your arm like a briefcase! The perfect form of personal transportation!*
* Note: lightweight bicycle application is powered by a Soviet-era nuclear submarine, a separate download.
Opinions on the Twiddler2 hand-held keyboard?
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.
I prefer to think of that volume as "The Design Rationalization and Mutation of C++". An astounding amount of it is Stroustrup explaining why one feature or another would have been a good idea, but had to be shelved in favor of something simpler to implement, or requiring fewer keywords to change. It shows the extent to which C++'s design was political in addition to being technical (see Lambda the Ultimate Political Party for how this worked in the Lisp community).
It's a good, informative read, though not always a fun one - I still gnash my teeth every time I read about how they settled on termination semantics for exceptions.
To a Lisp hacker, XML is S-expressions in drag.
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.