Cristian Vlasceanu wrote:
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
Given those studies which show that dlmalloc out-performs all custom
allocators except in some limited cases, aren't we better just limiting
custom allocators to those special cases?
