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."
... 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;"
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!!!
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,
So tell me, what really is wrong with C#?
So the language is responsible for the perversions that retarded coders put it through?
If you use instanceof more than once every, say, 10000 lines of code, I will fight you. That's no lie. It's a sop, and we, the loyal Java programmers of the world, know it's a sop. People who don't know what they're doing can turn it into a crutch. But those of us who DO know what we're doing know that using instanceof should be an automatic hint to rethink the design.
As for MethodNotSupportedException -- yes, it's kind of a hack. But the thing is, perfect designs don't translate to reality very well, and Java, for all its good points, isn't perfect. 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? Point is, it's a hack, but it's a lot better than the alternatives. And what it DOES do very well is say, "Look, genius, you're saying two different things about this object. Figure out what you mean and then say it."
I could read stupid C++/D/C/Ruby/whatever code and then blame the language too, you know.
"Honey, it's not working out; I think we should make our relationship open-source."
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.