Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-07-10 15:40:38

David Abrahams wrote:
> on Tue Jun 19 2007, Tobias Schwinger <> wrote:
>> David Abrahams wrote:
>>> on Sun Jun 17 2007, Tobias Schwinger <> 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).
> 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at