Re: [boost] Re: shifted_ptr review

From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2003-10-01 11:33:07

On Wed, 1 Oct 2003 cppljevans_at_[hidden] wrote:

> On 10/01/2003 10:52 AM, David Abrahams wrote:
> > Gregory Colvin <gregory.colvin_at_[hidden]> writes:
> >
> [snip]
> >>>
> >>>  template<typename T> shifted_ptr<T> make_shifted_ptr(cont T& t) {
> >>>      return shifted_ptr(new(so) T(t));
> >>>  }
> >>>
> >>>  ... make_shifted_ptr(Stuff()) ...
> >>>
> >>>are compilers allowed to optimize away the copy and construct the
> >>>Stuff in place?
> >
> [snip]
> > Oh, wait.  You meant the copy of Stuff()?  It's not meant to be a T
> > neccessarily.  It's just any old argument to T's constructor.  You
> > need a bunch of overloads for make_shifted_ptr to make the example
> > complete.
> >
> Why couldn't the shifted_ptr(T*) be replaced with
> shifted_ptr(make_shifted_ptr<T>&), where make_shifted_ptr<T> is
> simply derived from auto_ptr but has no make_shifted_ptr(T*) CTOR?
> No copy is needed and it simply turns over the T* to shifted_ptr<T>.
> Just as David points out, there would need to be a bunch of
> overloads for every T CTOR or at least those which
> the user wants to put into shifted_ptr.

Or one could be cute:

  shifted_ptr<T> foo(new_<T>(arg1, arg2, arg3...));

Then new_ is a function that returns an object containing the construction
arguments (the type to construct, T, could even be optional), and
shifted_ptr is free to do the allocation however it feels.

Heck, with the types of syntax we're discussing, where we move the actual
memory allocation into the library, shifted_ptr could become an
implementation detail of shared_ptr. We'd get the efficiency benefits of
shifted_ptr without the safety problems.

        Doug