[boost] smarter auto_ptr

From: Bronek Kozicki (brok_at_[hidden])
Date: 2004-01-17 11:21:19

Dear Boosters

I want to ask you to take a look at file ext_auto_ptr_07.zip (size 3KB)
, which is available in files section of boost YahooGroup . If you are
not happy downloading file from Yahoo, you may get it from my own WWW :
http://b.kozicki.pl/cpp/ext_auto_ptr_07.zip .

Actually ext_auto_ptr_07.zip contains two files: T191.hpp and T191.cpp
(both files are available standalone under http://b.kozicki.pl/cpp/ ) .
File T191.hpp contains improved auto_ptr (placed in namespace
boost::ext), file T191.cpp is simple application using its new features
(tested under MSVC71 and MINGW - GCC 3.3.1).

This auto_ptr is based on Rani Sharoni proposal to improve standard
std::auto_ptr. Rani's idea is to use SFINAE in smart way and remove
auto_ptr_ref from standard (as there is no longer need for it). Whole
story can be found here:
http://groups.google.com/groups?threadm=3fc75686%40news.microsoft.com

Preliminary FAQ:

Why improve auto_ptr?
There are few reasons:
* shared_ptr has support for deleters, while current std::auto_ptr does
not.
* shared_ptr can be safely used to store pointers to derived classes,
without using virtual destructor. Currently auto_ptr cannot be safely
used this way
* support for conversion to bool which could be used in "if
(my_pointer)"
Because shared_ptr will possibly be included in future versions of C++
standard, I wanted to improve auto_ptr , to make it compatible with
features available in shared_ptr .

What does it cost?
Very little. There is no additional heap allocation (as in shared_ptr),
and on special CPU overhead. There is however memory overhead: smarter
auto_ptr stores 3 pointers instead of 1. Added pointers are: pointer to
deleter function (ie. function called to release owned pointer) and
pointer to owned pointer cast to void * (this pointer will be passed to
deleter function). As first pointer is actually using template function
(ie. trampoline), there is also potential for code bloat and slightly
longer compilation time.

Is it compatible with std::auto_ptr ?
You may use it safely whenever you used std::auto_ptr. There is one case
when you may encounter compilation error, as a result of adding
conversion to bool. This problem was best described by Rani Sharoni:

http://groups.google.com/groups?selm=[e-mail]
> Nevertheless since it's a relaxation we must be careful about backward
> compatibility issues.
> Consider the following:
> char* f(auto_ptr<B>);
> long* f(bool);
>
> auto_ptr<D> dp;
> char* p = f(dp);
>
> Without the implicit conversions to bool the above code is (read
suppose to
> be) well formed. The relaxed auto_ptr will yield ambiguity since there
are
> two user defined conversions with the same rank. Notice that this
problem is
> only related to bool parameters (i.e. change bool to int in the above
code
> and the problem will disappear).
> Adding additional tie break parameters (e.g. char and int) will lead
to
> well-formed code with different meaning. same problem with template vs
> non-template.

Does it accept deleters as used in shared_ptr?
Yes, but with one important limitation: there is no separate instance of
deleter object for each instance of auto_ptr. Basicaly smarter auto_ptr
is using static function (class function) named "free" which takes
pointer being released. There are two template classes "del_functor" and
"del_bind" which allow use of functor object: first one will create
single (static) instance of this object and call it whenever pointer has
to be released, the other one will use object with external linkage you
point to (ie. pointer to deleter object is second parameter of template
class).

Really no support for deleters as used in shared_ptr?
This support is possible, I just want to discuss it with you before I
add it. The one solution that comes to my mind is to use multiple
inheritance:
your class     deleter class
    ^              ^
object managed by auto_ptr
this way deleter object is contained within managed pointer. It's
possible to store pointer to deleter class (as fourth pointer) in
auto_ptr, thus allowing access to it, but I do not know how to make it
type-safe (without extra CPU cost).

Why it's named auto_ptr ?
Becasue it's improved auto_ptr. If you do not like this name, we can
discuss some other name for this template class, like "smart_auto_ptr"
or "auto_ptr_ext" . In the meantime feel free to rename it (just
search&replace in T191.hpp will do). BTW: you are invited to rename
T191.hpp to something else, and share this new name with others :)

I hope you enjoy it, and I'm eagerly awaiting your opinion.

B.