Fernando Cacciola wrote:
David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
Ulrich Eckhardt <doomster@knuut.de> 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