|
Re: The Positive Legacy of C++ and Java
|
Posted: Mar 19, 2009 9:25 AM
|
|
> To understand how the language can be both unpleasant > and complicated, > and well designed at the same time, you must keep in mind > the primary > design decision upon which everything in C++ hung: > compatibility with > C. > > Funny, but Objective C had the same goal, held to it > better, and the language doesn't suck. Why? Because > Stroustrup's fundamental mistake, the core error, the > basic screwup, was not to stay compatible with C (which he > didn't do nearly as good a job of as Objective C). His > fundamental mistake from which all pain flowed was to > conflate structs with objects. This was, in retrospect, > the stupidest decision in the history of language > development and the root cause of most of C++'s ugly > little quirks.
I have to disagree. Stroustrup's main goal was performance. Objective-C dynamic dispatch method call will never be as fast as a C++ non-virtual/virtual method call. The run-time environment of C++ and many of the choices make perfect sense from a performance point of view.
What are the most important problems of C++? I'd say, the following, in no particular order:
1) uninitialized variables. Stroustrup thought (and maybe it is true on embedded systems) that not initializing variables automatically would have a performance cost. Should he have chosen safety first, he could have made variables always initialized except if not explicitly marked so.
2) array and ptrs equality. Again, for performance reasons, this has remained from C. The correct choice should have been to make arrays different from ptrs, and only treat them equal only when explicitly marked so.
3) lack of array bound checking. Same as above. Array access should be bounds-checked by default, except when explicitly not desired.
4) manual memory management. This is a big huge problem for the language, not because manual memory management is not feasible, but because it does not scale well. The solution here is not optional collection (as some might suspect from reading the above), but compile-time struct introspection: if the programmer was able to visit struct members at compile-time, safe generic precise collection could have been introduced as a library.
5) untyped new and delete operators. Without access to the type of the allocated object, the operators new and delete can not do enough magic to help in the problem of memory management.
6) header files. Big problem from the development point of view. Much effort is spent in synchronizing header and implementation files.
There is a good programming language struggling to come out from C++, especially with templates/type traits. Whoever does it, will put his name into the history books.
|
|