>> >> 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
