Nick Sabalausky wrote:
"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message
news:hl9n50$2f9...@digitalmars.com...
There are many problems with custom allocators. They hook the syntax and
do something that's unbecoming. new T must place T on the
garbage-collected heap, period. That gives the guarantee that the object
has infinite lifetime and therefore dependable behavior. If the same
syntax can be used to implement various other semantics, you can't count
on anything in generic code.
Sounds to me like the exact same argument for eliminating operator
overloading: "If we allow it, then someone could hijack '+' to do something
unbecoming and then you can't count on anything in generic code". Generic
code (at least in D) naturally comes with a risk of duckiness.
It's not the same argument, but I can't afford the time to debate that.
The whole point of custom allocators is to allow something to get the same
result (get a new instance) through a different implementation. And as for
the infinite lifetime guarantee: I don't think I see any risk of a
custom-allocated object getting yanked out from under generic code unless
you did something *really* bizarre and obviouly pointless like lauch a
thread that randomly marks elements in an object pool as unused.
My point is that custom new is not transparent at all. One typical
example of class-specific new and delete is using malloc as a backend.
So then you have some types for which you need to pair new and delete,
and some for which you don't. Not good.
All that's needed is the ability to create an object at a given address,
and the ability to destroy a given object. This is what the language
must provide. All the rest can and should be built via regular facilities.
Andrei
