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 <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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk