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;"
Because sometimes you want to write something quickly without having to worry about managing memory, pointers, etc. If you're writing an application where every clock cycle counts, then yes, use C or C++, but in most cases you can get away with a little bit more CPU usage with the benefit of code maintainability. I suppose if you really had a section of code where minimal CPU usage was important, you could write that in C++ and import it into Java as a native interface library.
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.
"Okay, I'll buy that. However, nothing prevents you from creating your own ImmutableList wrapper around a List instance and not exposing any mutators."
;) )
Sure. No argument from me on that. Nothing prevents me from creating my own class that doesn't throw NoSuchMethod.
But the whole point of libraries, you'll agree, is to save the client programmer from having to roll his own, design his own, test his own, code his own -- and then make it interoperate with your code or his code.
And it's his code (not yours, not mine) where the problem sneaks in. (It's always his code, not mine.
Say I'm using Joe's Nifty Library O' Functions. Joe, being a good programmer, doesn't try to roll his own container code -- he knows that no one wants to read up on how his JoeArray or JoeInterator or JoeList are different from the standard, so Joe -- and he's right to do this -- uses standard Java core library classes.
So far so good. But to be good, Joe has to use java.util.List. That's actually an interface, so Joe uses List as his public contract and java.util.ArrayList as the actual implementing class. He uses it as a public member of Joe's Own Nifty Widget with Lots O' Features.
Now you use Joe's library in your code, and you routinely use Widget.getObserverList() like this: myWidget.getObserverList().add( myCallback ) and all is well.
But at some point Joe adds Lenny's Luscious Library to his own code, because it adds all sorts of new functionality to Joe's stuff. But Lenny's library requires that Jow use Lenny's List class. It also implements the java.util.List interface, so Joe -- rather than copy stuff back and forth between lists, just replaces the ArrayList with a LennyList. Joe's code still works, and he releases Joe's Library 2.0.
You upgrade to Joe 2.0, to take advantage of all the new functionality he's added -- in fact, your 2.0 release leverages and relies on lots of the new functionality in Joe's library, and there's no way you could roll your own version in time to meet your client's deadline. And the compiler never complains about your upgrade, because all the interfaces are right, no method calls are made to functions that don't exist.
But at runtime, your code fails. Because Lenny's List has an add function, but never implements beyond throwing an exception. Incredibly enough, Lenny's List is a special proxy listinstanceof too often, they'll just say "see, I told you, object oriented code and using exceptions just ain't reliable."
Of course, the problem is that in using NoSuchMethod, Java isn't actually being object oriented, but after the code throws, try explaining that to the converted C programmers doing java. (Again, not you, not anyone who has read this far -- but we all know and have worked with someone like this, no?)
Now of course, these sort of problems won't arise on small projects. But they'll inevitably arise when your JSP library is calling your Java App server's code which is calling, via RMI, your Distributed Business Object which is calling, via JSQL either an Oracle database (for your domestic operations) or a Sybase database (for the European subsidiary).
Opinions on the Twiddler2 hand-held keyboard?