Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-02 08:20:45


From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> Speaking of shared_ptrs, has anyone considered how annoying it is to have
to
> _construct_ a shared_ptr using new, when someone is sticking with the
> reference-counted paradigm?

Yes.

> (I bring this up because I was thinking about the behavior of supporting
> assignment to a pointer, which can probably be done as a policy, but I
don't
> think the copy constructor can.)

Sorry, I don't understand what you mean by this.

> I considered having some global method that would be overloaded to take
the
> constructor parameters of an object and return a new shared_ptr like
> New<int> (2);
>
> The problem I had with that is the fact that I may want to force my class
to
> be used on the heap, non-copyable, etc, so I could privitize all
> constructors, but make New<> a friend.

The typical solution is

class X
{
private:

    X(...);

public:

    static shared_ptr<X> create(...); // (de)allocation details hidden
}

> However, New<> is best done as a
> class that to have a single friend statement (instead of one per
> constructor). With that change, New <int> (3) is a temporary instance of
> New<>, not a shared_ptr that is returned. This can be a hassle (the same
> hassle with new ()) when having to use a constructor of a shared_ptr to
make
> sure it is the right type -- though generally not a problem if shared_ptr
> could be constructed with a New<>.

A possible solution is

template<class T> class New
{
public:

    operator shared_ptr<T> () const;
}

> Since I've written New<>, I've used it almost everywhere. I can't think of
a
> situation where I would want a shared_ptr, unless I wanted some other kind
> of boost::*_ptr. There is potential for some policies as additional
> parameters to the New<> class.

Sorry, the next to last sentence doesn't make sense to me. You wouldn't want
a shared_ptr unless you want some other kind of ptr?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk