Re: [boost] smart_ptr changes

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-18 12:51:23

From: "Darin Adler" <darin_at_[hidden]>
> Things in there that I like, but I'd like to see taken further:
>
>     e) removal of std::swap overload is good, but I'd like to see a
> boost::swap overload added, since that has good effects for standard
library
> algorithms with MSL at least, even if the improvement is not guaranteed by
> the standard

I've removed the std::swap overload only because it's currently illegal, and
I believe that boost should not endorse such practice since many users base
their own designs on the boost implementations.

When shared_ptr goes into std:: the implementors would be free to overload
swap() as appropriate.

>     f) removal of std::less partial specialization and addition of <
> operator is good, but I'd like to either see the other comparison
operators
> or a rationale for why they are not provided

Only operator< is provided since standard algorithms usually don't need the
other versions. Providing the other operators implies that shared_ptr
comparisons are a feature.

> Things missing (no criticism of the proposal is intended here, just a
> comment on the state of what's up there right now):
>
>     g) shared_array needs many of the fixes already in shared_ptr
>     h) documentation

True, this was a work in progress. Also see

http://groups.yahoo.com/group/boost/files/smart_ptr/shared_ptr_updates.zip

that adds arbitrary 'finalizer' support.

> Things in there that I am not sure we want:
>
>     i) removal of "self assignment" feature of reset member -- it's a
> strange feature, but I'm not sure we should remove it

I don't see 'self assignment' as a feature, but if it's deemed essential, it
would be trivial to add.

Note, however, that in the case where shared_ptr accepts a finalizer,
reset() is not a no-op in the self-assignment case, since it reverts to the
default 'delete px' finalizer.

>     k) use of shared_count for implementation -- I don't see any publicly
> exported features in the current version; I think we might want to go the
> other direction and do pool allocation of the count, rather than making
the
> reference count object even bigger

shared_count rationale:

* allows shared_ptr to work when the pointer has been allocated by a DLL but
is destroyed by the application, even when the two use different heaps;

* isolates reference count operations so that a thread-safe implementation
needs only to change shared_count;

* allows shared_ptr<T> to call the correct destructor even when T is not
polymorphic or is void;

* allows finalizer support;

* useful building block for other shared_* classes.

Of course shared_array will reuse shared_count. :-)

--
Peter Dimov
Multi Media Ltd.