why allocators are not discussed here

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jun 26 16:01:07 PDT 2013


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


More information about the Digitalmars-d mailing list