[boost] Re: move_ptr

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-01-20 20:20:58

"Daniel Wallin" <dalwan01_at_[hidden]> wrote in message:

> I'm moving this to a new thread.
>
> Not every smart pointer has to handle every possible case. If you
want
> custom deleters, use shared_ptr<>.  The extra storage needed for the
> deleter IMO just isn't justified for something as simple as an
ownership
> transfer utility. What I do find interesting though is the ability
to
> delete incomplete types, IOW at some level capture of type at
> construction.
>
> I'm attaching the implementation that I believe should be pushed
> further.
>

This is definitely an improvement over your earlier version! I like
the idea of zero overhead for non-customized deletion.

I had an idea today to add a policy parameter to the move_ptr which
would determine the 'deleter storage policy'. It would be NEITHER a
deletion policy, NOR a storage policy for the pointer; it would just
determine how (and whether) a deleter is stored:

    template< typename T,
                    typename DeleterStorage = no_storage>
    class move_ptr;

1. move_ptr<T> ( aka move_ptr<T, no_storage>) would be your new
move_ptr.

I have in mind three other storage policies, which all allow user
supplied stateless deleters:

2. move_ptr<T, kozicki> (the name needs work -- no offense Bronek :-)
This would be (my version of) Bronek's pointer, with two pointers
extra overhead and essentially no runtime overhead.

3. move_ptr<T, linked_storage>. This is NOT a reference linked
implementation. This would have one pointer overhead for the deleter,
and very little runtime overhead in common cases.

4. move_ptr<T, hashed_storage> A slightly different version of
linked_storage.

Note, in 3 and 4, the linked or hashed data structures would typically
not need to be consulted -- they would be used in 'unusual cases'.

With this approach, we could run tests comparing the performance of
the various implementations, and get people's appraisals of the
overhead involved in each case.

If in the end, people agree with your current opinion that the extra
storage needed for the deleter isn't justified for an ownership
transfer utility, then move_ptr<T, no_storage> will become the
'official' move pointer, and we can get rid of the second template
parameter. On the other hand, if enough people feel a custom deletion
facility to be useful, and if one of (2) -(4) above turns to be
clearly better than the others (not including (1)), we could have two
move_ptrs.

I haven't written the implementation yet. I'll try to do it late
tonight.

Anyway, good work on your move_ptr!

Jonathan