Boost logo

Boost :

Subject: Re: [boost] C++03 unique_ptr emulation
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-01-08 12:42:32


Howard Hinnant wrote:
> * The move-only class author must know about boost::detail::rv
> (unique_ptr demonstrates use). The move-only class client needs to know
> only about boost::move and boost::forward.

Porting Interprocess to this move emulaton I have realized that a move
function like

template <class T>
typename enable_if_c
     !detail::is_convertible<T, detail::rv<T> >::value,
move(T& t)
     return t;

is quite problematic for container implementation. With the old
emulation (that returned detail::rv<T>) this was possible:

class vector
   void push_back(const value_type &);
   void push_back(boost::detail::rv<value_type>);

value_type v;

value_type v;

but this is not possible with this emulation. Moreover, for emplace
functions, they could be implemented like this:

template<class T1, class T2, class T3, ...>
void emplace_back(const T1 &t1, const T2 &t2, const T3 &t3,....)

The "rvalueness" was forwarded with detail::rv with some preprocessor
tricks. Sadly, changing the return type from T to
boost::detail::rv<value_type> works with Visual 7.1 but not with GCC 4.3:

movable function(movable m)
    return movable(boost::move(m));

//this works both with Visual 7.1 and GCC 4.3
movable m;
movable m2(boost::move(m);

//this only works with visual
movable m3(function(boost::move(m2));

With GCC 4.3 (surely more standard conforming that Visual 7.1)
boost::detail::rv<> -> T conversion don't work when passing arguments in
function calls. To solve this we need to explicitly call:

movable m3(function(movable(boost::move(m2)));

which is ugly. But not having a way to distinguish a pseudo-rvalue
reference and a reference I think causes more harm than good.

If we could somehow find a way to avoid writing


while maintaning boost::detail::rv<T> as the result of move() that would
be perfect.



Boost list run by bdawes at, gregod at, cpdaniel at, john at