Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-01-28 00:50:51


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk