Boost logo

Boost :

From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-03-30 13:01:52

I want to share my ideas inspired by this topic.

1) the naming scheme. I like naming after std:make_pair
boost::make_ptr<object_type>(a, b, c);

2) this facility should provide a way to specify creation and deletion
policies (malloc/free for example) It is absolutely must for real life
programming. Consider dealing with windows API handlers in exception
safe manner.
it can be specified like
boost::make_ptr<ptr_type>(boost::make_tuple(a, b, c), free, malloc); //
all params (template and function arguments) are optional

ptr_type defaults to std::unique_ptr
reason: to support custom deletion
in this case the type of object to be actually created is specified as a
template parameter:
boost::make_ptr<object_type>(boost::make_tuple(a, b, c), free, malloc);
it means that this function needs to be specialized for each supported
smart_ptr to avoid duplication like:
boost::make_ptr< object_type, smart_ptr<object_type>
>(boost::make_tuple(a, b, c), free, malloc);

this function is specialized for boost::shared_ptr
(std::tr1::shared_ptr) to provide optimization like in
make_shared_ptr<T>( a, b, c ) function mentioned by Peter Dimov

creation/deletion defaults to new/delete

unfortunately, we can not have overload of boost::make_ptr function that
can be used in the simplest scenario:
boost::make_ptr<object_type>(a, b, c);
because the constructor of object_type can have a tuple as a first
argument and/or function pointers as second/third, etc.
conclusion: the make_tuple syntactic overhead couldn't be avoided. It is
a consequence of providing creation/deletion policy.

the "simplest" case would be:

another possibility would be variations of the following approach:
in advanced use case we'll have
boost::make_ptr<ptr_type>(a, b, c)(free, malloc);
boost::make_ptr<ptr_type>(free, malloc)(a, b, c);
if it would be easier to implement

and in the simplest use case it would be
boost::make_ptr<object_type>(a, b, c);

It's a win, but it costs.
Personally, the flexibility of the last approach with additional
parentheses is very attractive for me. the syntactic overhead is minimal
even in the most advanced case, and no overhead at all in simple cases.
I can live with it.
What about you?

Oleg Abrosimov.

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