Re: Why doesn't new return a reference?
References can't be NULL. How would the reference exist after a delete
call? What state? Are you also pointing to changing the meaning of a C+
+ reference?
You can have all thos problems today:
X *px = new X();
X &rx = *px;
delete px;
// in what state is rx?
You are correct: that is a problem. However it is due to the poor
choices made by the programmer. Consider, however, if new and delete
operated on references. Then it would be a problem caused by the
language itself, and not just a bad programmer. Let's take this
pointer code:
void bar(X * x);
void foo()
{
X * x(new X);
//...
if (should_delete_for_some_reason()) {
delete x;
x = 0;
}
bar(x);
}
Fine, it's clear and straight forward. Bar must be allowed to accept
a null pointer, but it's a common idiom for functions taking pointers
to check them for nullness. (Unless they're documented to require
valid pointer arguments.) Now consider the same problem in terms of a
langauge that returned references:
void bar(X const & x);
int foo()
{
X & rx = new X();
bool deleted = false;
// ...
if (should_delete_for_some_reason()) {
delete rx;
deleted = true;
}
if ( ! deleted) {
bar(rx);
}
else {
// ??????????? how can I call bar?
}
}
The problem is obvious: once a reference, there is no way to change
the value to which it refers, even if the object really has been
destroyed. There is no way to call bar, even if we know the reference
was deleted, because we have to pass a reference to *something*, and
rx is a dangling reference and will be harmful to bar to pass it.
Perhaps we could have an overload of bar(void) or possibly bar(x&,
bool deleted), but now the book-keeping is maintained externally to
the data, and is much more awkward to use.
If we make a class to hold the reference and the valid flag, for
purposes of book-keeping we've basically re-invented a pointer, though
it's still less flexible since the internal reference cannot be
rebound. (We'll ignore the placement-new tricks that can accomplish
this by doing an end-run around the intent of C++ rules.)
Thus, we've lost some ability to express our program code, and have a
more limited, error prone language. I think the negative stigma that
raw pointers have is well earned, but their complete elimination would
not only unfeasible, but harmful to the langauge.
Chris
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]