Re: Another approach to forward/move issues
On Mar 5, 1:44 pm, "Daniel Kr?gler" <daniel.krueg...@googlemail.com>
wrote:
On Mar 5, 3:12 pm, "W Karas" <wka...@yahoo.com> wrote:
On Feb 20, 12:38 pm, "W Karas" <wka...@yahoo.com> wrote:
Add this ?pseudo? class template
to the std namespace:
template <typename T>
class rvalue;
For any type X, the types X and rvalue<X>
would be distinct but have exactly the
same interface/size/alignment. For
value/reference/pointer conversion, both
would convert to ?const X? implicitly, but
conversion between them would require a static cast.
Anonymous, compiler-generated temporary instances
(r-values) would be of type rvalue<X>. This seems
to solve the forwarding problem, because
template type deduction would capture the
difference between a const reference and a
temporary (without changes to the deduction
rules).
A named instance of rvalue<X> would save one cast
in a swap:
std::rvalue<X> t = static_cast<std::rvalue<X> &>(a);
a = static_cast<std::rvalue<X> &>(b);
b = t;
It would be nice, if you could explain your reasons,
why your proposed class template rvalue is better
than the current rvalue proposal? The most recent
document is here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
This one corresponds to the primary proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html
and these are some intermediates, which explain also library
impact:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1770.htmlhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html
It's unfortunate that there is not an up-to-date, comprehensive
written description (ideally including a tutorial) of the rvalue
reference proposal.
It's clear that both rvalue references and rvalue types would
interact with existing features of C++ in complex ways. I
think it's very possible that rvalue types would be somewhat
less complex. I don't have time to really investigate
this. But maybe someone else does, so I put out the
suggestion.
At the cost of adding a new reserve word, "rvalue" could
become a type modifier like "const" and "volatile".
This seems more intuitive, and presents an obvious
solution to how to declare member functions where
the instance itself is expected to be an rvalue:
void foo(void) rvalue;
analogous to:
void foo(void) const;
What is the advantage of an rvalue-function foo? What should
it do that should not be done for const, volatile, or not-cv-not-
rvalue
types?
I read in some posting that a problem with the rvalue
reference proposal was how to declare a member function
that could only be called when the class instance was
an rvalue.
The rvalue proposal allow selected member functions to support
move-semantic, e.g.
struct C {
C(C&& rhs);
void swap(C&& other);
};
Isn't this sufficient?
'swap(rvalue C &other)' seems more intuitive to me. For
function template type deduction:
template<typename T>
void foo(T &x) ...
if I call foo passing an rvalue of type X, it seems more
intuitive to deduce T to be 'rvalue X' rather than 'X &'.
---
[ 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 ]