Re: rvalue references and default constructors

[Frank Bergemann]

So my question is: will the rvalue-copy-constructor and the
rvalue-copy-operator be automaticall generated or will we have to write it
on our own?

Using gcc-4.3.0 it silenty(!) invokes the Test::operator= (Test const&
t) for

Test a;
Test b = std::move(a);
Test c = std::moved(T()) ;

- if i disable the Test::operator= (Test&& t) in source file.
(But uses Test::operator= (Test&& t) if it is availabled.)

Though using std::move() might be considered to be an explicit request
for rvalue reference argumented function.
Moreover:
One MUST use std::move(t) for explicit invocation of
Base::operator= (Base&& rhs) in Test::operator= (Test&& t)

Test &operator=(T est &&t)
{
Base::operator= (std::move(t)); // HERE
a = std::move(t);
return *this;
}

Otherwise it calls Base::operator= (Base const& rhs) silently again.

Using member functions with rvalue reference arguments seems just to
be a "fits better" for the compiler.
Member functions with rvalue reference type arguments attract for
applying actual rvalue references to some overloaded member function
set - as forced by std::move().

Worse in my view is, that inside those functions itself- which have
rvalue reference arguments - those types are treated like lvalue
references again (see the need for explicit std::move(t) in
Test::operator= (Test&& t).
I guess the reason is that it MIGHT be given some lvalue reference as
well - for invocation
(For test you can also do the other way around: provide rvalue
reference member functions and drop/disable the old "Test const& t"
images.)
So it falls back to that restriction level - unless you explicitly
recover rvalue reference conditions (using std::move() again).
This is feels like sapping type-safety.
Or let me say: if i declare a rvalue reference argument for my member
function i would like to keep treating it as rvalue reference inside
that function.

rgds!

Frank