Le 29/12/2015 17:47, Rob Stewart a écrit :
On December 29, 2015 4:38:34 AM EST, "Vicente J. Botet Escriba"
wrote: Le 25/12/2015 18:38, Bjorn Reese a écrit :
If I have a class T that always must be created as a shared_ptr (e.g. because it relies on enable_shared_from_this<T>), then I can ensure that the class can only be constructed via the factory by making the constructor of T private, and let the factory be a friend of T. This works fine if my factory is a static T::create(args...) function, but not when using make_shared<T>(args...) because in practice it uses internal helper functions that I cannot make friends of my class.
I believe there is a place for this kind of classes and to have an associated factory. The question is how to recognize these kind of classes.
My library would only help you to overload make_custom so that you can write
shared_ptr<T> ptr = make<T>(args...);
make_custom will replace your T::create(args...).
Even if the library wouldn't help you a lot (as you need to customize), would you prefer make<T>(args...) to T::create(args...)?
Maybe inheriting T from a specific class could help to identify this kind of classes and so the customization. Can't his specialization of your customization point be a friend of his class, thereby having access to the private constructor? Yes of course. Does the customization point specify the return type so he can get his shared_ptr?
Currently it is determined by the the following overloads
// make overload: requires a type with a specific underlying type,
don't deduce the underlying type from Xs
template
::type make(Xs&& ...xs) { return make_custom(meta::id<M>{}, std::forward<Xs>(xs)...); }
But it could be
// make overload: requires a type with a specific underlying type,
don't deduce the underlying type from X
template
::type make(Xs&& ...xs) { return make_custom(meta::id<M>{}, std::forward<Xs>(xs)...); }
Vicente