|
Boost : |
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-03-29 16:28:44
Fernando Cacciola wrote:
> 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)) ;
this might be worth persuing (see below)
> As long as there's a way to get the 'element_type' from 'any_smart_ptr'
> it'll work.
>
> On top of that there could be the friendlier: make_auto_ptr,
> make_shared_ptr, etc...
That would generate *a lot* of code to parse for the compiler.
It is better that new_<T>(...) produces an unspecified type
that has a templated conversion operator, eg.:
template< class T >
struct new_return
{
std::auto_ptr<T> new_;
new_return( T* new_ ) : new_(new_)
{ }
template< class SP >
operator SP() const
{
return SP( new_.release() );
}
operator std::auto_ptr<T>() const
{
return new_;
}
};
Or something
-Thorsten
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk