[boost] Re: smarter auto_ptr

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-20 08:50:26

"Bronek Kozicki" <brok_at_[hidden]> writes:

> 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.

AFAICT this stuff was solved already by Philippe Bouchard's
shifted_ptr:

http://article.gmane.org/gmane.comp.lib.boost.devel/27276
http://news.gmane.org/find-root.php?message_id=%3cbnaaef%24ti2%241%40sea.gmane.org%3e
http://thread.gmane.org/gmane.comp.lib.boost.devel/25901

Maybe if someone writes to him to express interest he'll finish the
docs ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com