Re: R-value reference upper class constructor lookup
On 2011-03-10 01:36, Juan Pedro Bolivar Puente wrote:
Hello,
I am getting strange behaviour in a C++0x example with gcc-4.5
--std=c++0x. I want to ask here to decide wether this is a compiler bug
or not.
The problem is, I have a class with a move constructor that inherits
from another class with a move constructor. In the derived class move
constructor we pass the object to its base class constructor, but
instead of calling the move constructor it calls the copy constructor.
It seems that the compiler prefers to cast deriv&& to const base&
instead of base&&, which is very unintuitive. Even more strange, I can
solve the problem by explicitly doing std::move on the deriv&& value
when passing it upwards.
It was a very important aspect of the original "move" and
rvalue-reference proposal, that moves should not happen silently.
Therefore, it was intended, that user-code should always ensure that an
lvalue is never silently transformed into an rvalue and moved away. In
your example code:
An example:
#include<iostream>
struct base
{
base ()
{ std::cout<< "base default"<< std::endl; }
base (const base&)
{ std::cout<< "base copy"<< std::endl; }
base (base&&)
{ std::cout<< "base move"<< std::endl; }
};
struct deriv : public base
{
deriv ()
{ std::cout<< "deriv default"<< std::endl; }
deriv (deriv&& d) : base (d)
{ std::cout<< "deriv move"<< std::endl; }
... "d" is an lvalue here. We don't want silent moves of lvalues,
therefore you are required to change this to
deriv (deriv&& d) : base (std::move(d)) { ... }
private:
deriv (const deriv&) {}
};
int main ()
{
deriv d = std::move (deriv ());
return 0;
}
This yields:
base default
deriv default
base copy
deriv move
In my opinion, the output should be:
base default
deriv default
base move
deriv move
And I can get this behaviour by changing deriv's move constructor to:
deriv (deriv&& d) : base (std::move (d))
{ std::cout<< "deriv move"<< std::endl; }
Am I understanding r-value references wrong or am I in front of a GCC
implementation bug?
This is *no* implementation bug, but a mains aspect of the move-semantics.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]