Re: [boost] Re: Re: Re: smarter auto_ptr

From: Bronek Kozicki (brok_at_[hidden])
Date: 2004-01-20 04:33:32

Jonathan Turkanis <technews_at_[hidden]> wrote:
> The problem I ran into (I assume its the same one Bronek Kozicki
> alluded to in his source) has to do with multiple iheritance.Suppose

Exactly. I did not found it myself, it was Ben Hutchings who pointed it
out
http://groups.google.com/groups?selm=slrnbtriet.1qo.do-not-spam-benh%40tin.bwsint.com

> You might be able to save a byte or two by storing an offset, but this
> relies on implementation defined behavior, and would not be able to
> handle really huge objects.

This will give no gain at all in architecture with alignment size equal
to (or larger than) pointer size (which is rather popular, I guess). I
was thinking to compute and save this offset in compile time, but then
there's no way to store it in auto_ptr and pass in compile time while
passing ownership to another auto_ptr. We could think to add another
template parameter for this purpose, but I'm all against it - this will
create many disctinct types, with the same type of managed pointer. We
could also compute and store this offset in trampoline function, but
then there's no way to reach this information in compile time. The one
solution I see is to create "chain" of trampoline functions, where each
will return its own offset if called with NULL pointer argument, thus
the last one will be able to find correct offset and correctly delete
maneged pointer. But this will slow down whole deletion process, so
basicaly we just exchange one pointer for unknown (and unlimited) number
of function calls. I think it's bad deal, and I'm not sure it's doable -
but I'm sure it's fragile.

B.