Re: Article on possible improvements to C++
* sfuerst:
Hello, I've written an article at http://locklessinc.com/articles/10_problems_with_c++/
that is unfortunately way too long to post here, detailing ten
perceived problems with C++, together with some possible solutions.
The list kind of looks like the typical one brought up by novices,
He he, it certainly does. :-)
But kudos (speling?) to you for writing it up.
For that can both help you and help many others.
complaining about things like exceptions and multiple inheritance.
However, the actual issues discussed tend to be more subtle and low-
level than what you are probably thinking. In particular, none of the
"problems" are complaints about the existence of features, just on
their current syntax, or typical underlying implementation.
The 10 problems are:
1) The "new" keyword.
OK, there's much wrong.
First, "Unfortunately, the new keyword doesn't allow [...] an override." is
wrong. You override the allocation aspect by defining operator new (and/or
operator new[], which is the allocation function, which can be overridden per
class as well as overriding the global default (where, to boot, you can override
the action taken on allocation failure via set_new_handler). And you can
"override" the initialization action by defining suitable constructors.
Second, this is wrong: "A second problem with the new keyword is that it
combines two different operations in one. The first is to allocate memory, the
second is to initialize it. This combination means that initializing an array is
impossible to do with anything other than the default constructor."
'new' is designed to very strongly couple allocation and initialization, with
automatic rollback. It's extremely tricky to do manually, that is, to do it
correctly without language support. If C++ didn't have 'new' to do it, it would
need some other mechanism to do it, which would then be used instead of 'new'.
Also, it's wrong that it's impossible to initialize an array in other ways than
using a default constructor.
For example,
std::vector<int> a( 42, 999 );
Third, this is wrong: "Similarly, destructing an array with the delete[]
operator is inefficient.". delete[] is designed for maximal efficiency. The
trade-offs made to achieve that efficiency, in particular that the programmer
must supply the knowledge of whether it's delete or delete[] (just in order to
save a byte or two of memory!) is a problem, but the efficiency is not. :-)
Now, to your (rhetorical) question, "If all backwards compatibility were thrown
out, how could construction, initialization, and memory allocation be better
done, (paying particular attention to orthogonality)?"
This is addressed in C++0x, which unfortunately seems to be a long way from
ratification, but still.
It's an initialization syntax based on curly parentheses initializers.
2) Exceptions
3) Implementations of Multiple Inheritance
4) Member Pointers and Member Function Pointers
5) 0 is NULL
6) Operator Overloading
7) Template Syntax
8) The "export" Keyword
9) Classes verses Structs
10) Barriers
Unfortunately, some of the solutions aren't particularly good. (The
worst one probably is a replacement syntax for the new keyword.)
However, constructive criticism has to start somewhere.
Any comments, or flames are welcome. :-)
I skimmed the section on Exceptions, it is also full of misconceptions. But
those are more arguable, questions more of design than how things work
technically. However, others will probably chime in for the rest (also about
what's wrong with section 2), and I hope my comments on section 1 help.
Cheers,
- Alf