From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-07-10 15:40:38
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
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).
Oh thanks (I remember the discussion but never noticed it actually
became reality :-) )!
>>>> Where operator() takes a variable number of arguments, forwarded to the
>>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk