Re: [boost] Re: shifted_ptr review

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-09-30 12:09:22

Given

   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?

If so, do they?

On Tuesday, Sep 30, 2003, at 10:45 America/Denver, Powell, Gary wrote:
>> Powell > I'm a little concerned that it appears you can create bad 
>> pointers for
>> Powell > this class by inadvertently not using placement new. I'd 
>> feel better
>> Powell > about it if there was some way to prevent this.
>>
>> Abrahams >Generic smart pointer factories are the right way:
>>
>> Abrahams >   shifted_ptr<U> p = make_shifted_ptr<T>(arg1, arg2, arg3, 
>> ref(arg4));
>>
>> So you are saying remove the constructor,
>>
>>    template<class U>
>>       shifted_ptr( U *);
>>
>> and replace it with one that takes a temporary that is created only 
>> by make_shifted_ptr?
>
> Abrahams >No, I was suggesting making the constructor private, making
> Abrahams >make_shifted_ptr a friend, and have make_shifted_ptr<T>(...) 
> return a
> Abrahams >shifted_ptr<T>.
>
> Abrahams >Your approach seems very complicated.  Is there a reason to 
> do it
> Abrahams >that way?
>
> Well depends whether you prefer and can compile.
>
> template<class T>
>   class  shifted_ptr {
> public:
>   template<class U, class Arg1>
>        friend shifted_ptr<T> make_shifted_ptr();
>
>   template<class U, class Arg1>
>        friend shifted_ptr<T> make_shifted_ptr(Arg1 &);
>
>   template<class U, class Arg1, class Arg2>
>        friend shifted_ptr<T> make_shifted_ptr(Arg1 &, Arg2 &);
> ....
> };
>
>  Or the other way. If I remember correctly not all compilers used to 
> be able to handle template friends. On the other hand the previous 
> approach could have been due to a lack of caffeen.
>
> So after looking at this for all of 5 minutes, if the friend 
> make_shifted_ptr works, it looks easier to maintain. But in all cases 
> taking raw pointers is to be avoided.