Re: Reasons for not standardizing policy based smart pointers
On Jun 1, 7:27 pm, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
In a blog entry I read recently, Herb Sutter states:
One of the primary reasons (but not the only one) why policy-based
smart pointers didn't make it into C++09 was usability: Although
Loki::SmartPtr can express shared_ptr easily as just one of its
configurations, the user has to type lots of weird stuff for the
policy parameters that is hard to completely hide behind a simple
typedef, and so the user would be less inclined to use the
feature:
shared_ptr<int>::type p;
shared_ptr<int> p;
Too bad we didn't have template aliases then, because now we could
have our cake and eat it too:
// Legal in C++09
//
template<typename T>
using shared_ptr =
Loki::SmartPtr<
T,
RefCounted, NoChecking, false, PointsToOneObject,
SingleThreaded, SimplePointer<T>
>;
shared_ptr<int> p; // using the alias lets us
// have a completely natural syntax
I wonder: what were the other reasons Herb hints at? Though he says
that they are not "primary" I hope they are still very serious for
"falling back" to a supposedly inferior alternative in a standard
which will set the shape of what we'll use for the next 20 years.
--
Gennaro Prota -- C++ Developer, For Hirehttps://sourceforge.net/projects/breeze/
This is assuming that the only way to have a policy based smart
pointer is to have tons of template arguments that an app developer
need to deal with every time they want to use it. Or that the only way
to make new kinds of templates is by template aliases.
Rather, a better way to look at policy based smart pointers is a way
for an app programmer to easily specify a family for use in her
program. For example:
namespace lib{
template<class T,class PolicyBlob>
struct basic_shared_ptr{
//get policies out of PolicyBlob, i.e. checking, threading etc
//implememnt all shared_ptr functions, minus constructors in terms of
PolicyBlob
};
}
now define end user template
namespace user{
struct detail{
typedef RefCounted countpolicy;
typedef NoChecking checkpolicy;
bool const noninstrusive=false
//....
};
template <class T>
struct shared_ptr:lib::basic_shared_ptr<T,detail>{
//implement all constructors
};
}//namespace
Of course, the "implement all constructors" part is a hassle. What I
do in practice is to use some helper macros. It looks like this:
namespace foo{
#define POLICY_CLASS \
refcounted_detail::shared_count<
T,detail::shared_countPointerMgr >
MYLIB_SHARED_PTR_DEFINITION_HELPER_BEGIN(shared_ptr,POLICY_CLASS)
MYLIB_SHARED_PTR_DEFINITION_HELPER_END(shared_ptr)
MYLIB_WEAK_PTR_DEFINITION_HELPER_BEGIN( weak_ptr , shared_ptr)
MYLIB_WEAK_PTR_DEFINITION_HELPER_END(weak_ptr)
MYLIB_SHARED_PTR_ENABLE_SHARED_FROM_THIS_HELPER(shared_ptr)
MYLIB_SHARED_PTR_CAST_FUNCTION_HELPERS(shared_ptr)
}
And now I have
foo::shared_ptr,foo::enable_shared_from_this,foo::weak_ptr, etc, all
parameterized from the POLICY_CLASS used to make the shared_ptr.
Furthermore, I can do this:
MYLIB_SHARED_PTR_DEFINITION_HELPER_BEGIN(shared_ptr,POLICY_CLASS)
bool operator==(shared_ptr const&)const;//do something different?
MYLIB_SHARED_PTR_DEFINITION_HELPER_END(shared_ptr)
if I so wanted.
template aliases would make this easier, but I have to use what I
have, not what I wish for.
I can use the library like this
foo::shared_ptr<int> fooint(new int); // special for foo
bar::weak_ptr<int> barwint; // special for bar
//barwint=fooint;//wont compile
template<class T>
struct alias{
operator()(void*)const{}
alias(T const&_a):t(_a){}
private: T t;
};
bar::shared_ptr<int> barint(fooint.get(),alias(fooint));
barwint=barint;
//now fooint will live as long as barint does
but I have found in practice that this alias technique is not usually
required.Familiies of shared pointers stay together.
So now I have one code base (on Sun WS6U2, IBM xlc8, gnu, and MSVC
7.1./8) that does intrusive pointers, nonintrusive pointers using
shared memory allocators,nonintrusive pointers identical to the boost
distribution, etc. And they are all 100% standard compatible.
Lance
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]