What can you "new"

[Cristian Vlasceanu]

>>
>> Do custom-allocated objects live on the GC-ed heap?
>
> Not necessarily, e.g. you can malloc some memory and then create an object 
> there.
>

I was afraid that may be the case, and it is perhaps not a good idea.

Early Managed C++ users found it difficult to deal with pointers to both 
managed and un-managed objects without being able to tell (just by a quick 
glance at the code) which is which -- the language subsequently changed, now 
^ means managed pointer,and * means unmanaged. Managed C++ is a mess IMHO, 
because it tries to counsel into a happy marriage the GC paradigm with the 
old control-over-each-and-every-bit school (you can still get projects done 
in managed C++, but not before you bump into all the legacy boxes in the 
garage).

I find custom allocators being less useful than they used to -- the 
GC-managed heap plus a "tls" storage class should be sufficient for most 
needs.

D 2.0 should abandon the hope of being THE ULTIMATE language and content 
itself with being a good-enough, better than others, language. Otherwise it 
will either succumb into the schizophrenic fate of managed C++, or it will 
perpetually be a moving target, alienating its users.

This is why D .net does not support any of this custom allocator nonsense.


My two Global-Currency / 100

Cristi