David Abrahams wrote:
on Tue Jun 19 2007, Tobias Schwinger <tschwinger-AT-isonews2.com> wrote:
David Abrahams wrote:
on Sun Jun 17 2007, Tobias Schwinger <tschwinger-AT-isonews2.com> wrote:
Interface draft: ================
factory<T> // constructs X and returns it by value factory<T*> // uses operator new, returns a pointer auto_ptr, please. Generic algorithms won't 'get' it.
You have generic algorithms that expect to get ownership of a dynamically-allocated pointer?
At least there are generic algorithms that might as well move pointers to dynamic memory: instances.reserve(args.size()); // throws now, if out of memory transform(args.begin(),args.end(),back_inserter(instances), bind( factory<something*>(), 123, _1) ); One could argue that 'instances' should be a boost::ptr_vector - but it isn't needed that badly in cases like this one.
In this light, it seems better to have a separate template for pointers, so you clients can specify what they want, explicitly:
new_< T* > new_< auto_ptr<T> > new_< special_smartie<T> >
(Seems tricky to deduce T but it might be doable).
boost::pointee<X>::type
Oh thanks (I remember the discussion but never noticed it actually became reality :-) )!
Where operator() takes a variable number of arguments, forwarded to the constructor.
Isn't in-place construction the most general case? It sure is, but not necessarily the most handy. How to tell e.g. std::transform to allocate memory for the transformed elements?
Not sure I really got your point, here.
Just that you might want to support the general case and build the others on top... if possible.
That's essentially allocator support, isn't it? I doubt that STL-style allocators are too well-suited for this purpose, however... What's the interface you had in mind? Regards, Tobias