On Thu, Jun 27, 2013 at 12:43:54AM +0200, Adam D. Ruppe wrote: > So to try some ideas, I started implementing a simple container with > replaceable allocators: a singly linked list. > > All was going kinda well until I realized the forward range it > offers to iterate its contents makes it possible to escape a > reference to a freed node. [...] > (though if the payload is a reference type, does the container take > ownership of it? How do we indicate that? Perhaps more interestingly, > how do we indicate the /lack/ of ownership at the transfer point?)
Maybe a type distinction akin to C++'s auto_ptr might help? Say we introduce OwnedRef!T vs. plain old T*. So something returning OwnedRef!T will need to assume ownership of the object, whereas something returning T* would just be returning a reference, but the container continues to hold ownership over the object. > This is all fairly easy if we just decide "we're going to do this > with GC" or "we're going to do this C style" and do the whole > program like that, libraries and all. But trying to mix and match > just gets more complicated the more I think about it :( It makes the > question of "allocators" look trivial. Heh. Yeah, I'm started to wonder if it even makes sense to try to mix-n-match GC-based and non-GC-based allocators. It seems that maybe we just have to settle for the fact of life that a GC-based object is fundamentally incompatible with a pool-allocated object, and both are also fundamentally incompatible with malloc-allocated objects, 'cos you need the code to be aware in each instance of what needs to be done to cleanup, etc.. T -- GEEK = Gatherer of Extremely Enlightening Knowledge