Re: [boost] Smart Pointer new/Forwarding Problem Solved (by Force)

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-29 16:39:16

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:

> David Abrahams wrote:
>> David Abrahams <dave_at_[hidden]> writes:
>>
>>> Ulrich Eckhardt <doomster_at_[hidden]> writes:
>>>
>>>> On Wednesday 29 March 2006 08:05, Václav Veselý wrote:
>>>>> I'm confused with syntax. new_<T> always creates auto_ptr<T>. How
>>>>> can I create for example shared_ptr<T>?
>>>>
>>>> You probably can't, but:
>>>>  - std::auto_ptr is much less resource intensive (shared_ptr
>>>> requires an additionally, dynamically-allocated structure to hold
>>>>  some internals) - you don't need to, as auto_ptr converts to
>>>> shared_ptr, there is a special ctor taking an auto_ptr
>>>
>>> Unfortunately for this particular facility, the converting
>>> constructor
>>> is explicit, so you can't do
>>>
>>>    f(new_<T>(a, b, c))
>>>
>>> if f takes a shared_ptr<T>.
>>
> Then isn't it worth generalizing new_<> to all sorts of smart pointer and 
> handles?
>
> Like:
>
>  f( new_< any_smart_ptr<T> >(a, b, c)) ;
>
> As long as there's a way to get the 'element_type' from 'any_smart_ptr' 
> it'll work.

Yes, as I wrote elsewhere in this thread, I did write a version that
makes that possible.

> On top of that there could be the friendlier: make_auto_ptr, 
> make_shared_ptr, etc...

None of that is particularly friendly compared to new_<T>(a,b,c)... as
long if we have the appropriate non-explicit converting constructor
from auto_ptr rvalues in all the other smart pointers.  Peter's
already made that change to shared_ptr and I'm sure it's just a matter
of time before that change is propagated to the other Boost smart
pointers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com