Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-07-26 13:24:17

At 01:31 PM 7/26/2001, Greg Colvin wrote:
>From: Beman Dawes <bdawes_at_[hidden]>
>> At 09:09 AM 7/26/2001, Peter Dimov wrote:
>> >From: "Philip Nash" <philip.nash_at_[hidden]>
>> >> Agreed. Sorry, I wasn't suggesting that the finalizer function be
>> dropped
>> >> from your proposal,
>> >
>> >There's nothing wrong with suggesting that. I am not entirely
>> >that
>> >adding this finalizer support to shared_ptr is a good idea. I simply
>> >demonstrated that it can be done; this doesn't mean that it must be
>> I think that is a really important point. There are lots of advantages
>> a small, very stable, shared_ptr. I really think that many of the
>> "improvements" should be explored in the context of a completely new
>> design, along the lines of Andrei Alexandrescu's smart pointer policy
>> classes.
>I agree. But that new design will be a long time coming, so I am
>looking for the smallest set of improvements to shared_ptr that
>will satisfy the most complaints, soon. The lack of a dynamic
>cast facility is one long-standing complaint, and Peter has a fix
>for that. The question is whether this is a good time to fix
>some other complaints, and if so which ones.

That makes sense.

>A large number of complaints come down to not being able to use
>any memory management besides new/delete. This makes shared_ptr
>useless for COM-style cross-dll use, for memory obtained from
>C libraries and system calls, for objects obtained from the
>standard and custom allocators, and so on. Being able to specify
>a finalizer function is the best way I can see to solve this
>problem. I especially like that in Peter's solution the choice of
>finalizer does not affect the type of the shared pointer. This
>makes it easy for functions that create objects and return a
>shared_ptr to hide their memory management implementation, and to
>change it without forcing a recompilation of their callers. So I
>am very much in favor of accepting Peter's shared_count.

A strong endorsement. I'll try to look at it in the next day or so.

>A second set of complaints come down to wanting the shared_ptr
>interface with a different implementation, such as intrusive
>counts, linked lists, or garbage collection. This can be handled
>now by cutting and pasting. It could also be handled with a
>parameterized base class like this
> template<typename T,class Base=shared_ptr_base<T> >
> struct shared_ptr : Base
>or even like this
> template <
> typename T,
> template<typename U> class Base=shared_ptr_base >
> struct shared_ptr : Base<T>
>I'm less sure whether this is worth the trouble, as I have had a
>hard time designing a good base class. But I remain open to
>suggestions, as having such a base class would make it easier
>for others to provide alternative implementations.

I'm not very enthusiastic about it.

>A third set of complaints is the lack of thread safety, which I
>suspect we should postpone until Boost::threads is ready. But
>perhaps Peter's shared_count class could be exposed as a default
>parameter to the shared_ptr template, so that those needing
>thread safety now can provide their own implementations. Of
>course if we go with the parameterized base class then those
>needing more thread safety could do so by providing their own
>base class.

Boost.Threads is very close to being ready for review. Let's wait until it
is finished, then revisit thread safety.


Boost list run by bdawes at, gregod at, cpdaniel at, john at