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: boost::make_ptr<object_type>(boost::make_tuple(a)); 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); or 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? Best, Oleg Abrosimov.