Hi,
I also found it incorrect to keep move semantic in basic template while
was working on my adaptation of SmartPtr. Let's look on auto_ptr for
example. It's basically scoped_ptr with added move semantics. The same need
may arise with almost any SP: one with custom deleted or special checking
policy. So I argue that there always exist valid regular (non movable) SP
that correspond to the movable one I need; and movable is always a
"metafunction" of non movable one. Lets call this "metafunction"
make_movable. So IMO what we need is to implement this make_movable
"metafunction". It could be either
template<typename SP>
make_movable {
typedef ... type;
}
or
template<typename Policy1,typename Policy2,...> here we list policies of SP
make_movable {
typedef ... type;
}
What I am currently have is inheritance. Though I am not sure it's best
solution:
template <typename T,
typename StoragePolicy,
....
>
class auto_smart_ptr : public smart_ptr<T,StoragePolicy,...>
{
public:
// here we implement everything that make it movable
// the rest is inherited from smart_ptr
};
class template smart_ptr does not know anything at all about movable
semantic.
Regards,
Gennadiy.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
