Re: Article on possible improvements to C++
On Nov 20, 12:52 am, "Alf P. Steinbach" <al...@start.no> wrote:
* sfuerst:
[...]
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.
Not to mention all the things that can be done using placement
new.
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'.
FWIW: you can separate the two actions, by calling the operator
new function and using placement new for initialization. New
was introduced, however, precisely because it was felt that the
separation is a bad thing---it means that you can end up with
raw memory, that the compiler thinks is a constructed object.
In all but very exceptional, low level code, this is an error.
Also, it's wrong that it's impossible to initialize an array
in other ways than using a default constructor.
That could be considered a default. I'm not sure, but perhaps
the new initialization syntax in C++0x addresses this as well.
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.
Yes, but it doesn't really affect new that much (except for
array new---but I've never found a use for that anyway).
Probably because it wasn't felt that new was broken.
--
James Kanze