What can you "new"

Denis Koroskin 2korden at gmail.com
Wed Mar 25 06:01:19 PDT 2009


On Wed, 25 M9ar 2009 11:55:14 +0300, Cristian Vlasceanu <cristian at 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.



More information about the Digitalmars-d mailing list