On Wed, 25 M9ar 2009 11:55:14 +0300, Cristian Vlasceanu <crist...@zerobugs.org>
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
Having a custom memory pool is usually a good idea. At work, our game engine is
split into a few separate sub-systems (particle system, physics, animations
etc). Since most of them are completely independent (we keep track on their
dependencies and trying to cut them as much as possible), it makes sense to
have custom memory pools for each of them.
More over, if object references don't escape that pool we could have a custom
per-pool garbage collector!
For example, I am responsible for a sound system in our company. In the system I
designed, all the allocations made inside sound system are done through a custom memory
pool (so that our sound designer don't go mad and uses all of the memory available for
SFXs :)). Although it can't be statically proven (in C++), none of the object references
escape that pool ever. That's because all the communication is done via a value type
called SoundSource, which is struct wrapper around an "int id;". This ensures
that all the object references are kept internal to that pool and thus an independent
garbage collector is possible for this pool.
