Compiler bug in g++ -std=gnu++0x

[4z0M4iN6]

This bug isn't important, because normally nobody would write such code. But maybe a bug should be corrected. I don't know, whom to contact for fixing. Maybe you know.

The history: I found a bug in VC8, which still exists in VC10 and VC11.

Consider this code:

Object5 = CompilerTest("UsedObject");

Very foolish, what the MS compilers did. Used the copy assignment operator.
g++ behaved very well. Said error, because no fitting assignment operator.
Then I implemented the copy- and the move- assignment operator.
And the behavior of the compiler was correct: used the move assignment operator.

Then I wanted to know this, nobody would write it, but it's a bug:

Object5 = CompilerTest("UsedObject") = Object2;

And what did I see? For both assignments the compiler used the copy assignment operator:

Result: deallocation of memory of Object2 couldn't be disabled by the move assignment operator.

Not important bug, but maybe it should be written into a bug list for fixing.

[Cubbi]

Object5 = CompilerTest("UsedObject");
used the move assignment operator.

From this I assume that CompilerTest is a function call that returns a value

Object5 = CompilerTest("UsedObject") = Object2;

And what did I see? For both assignments the compiler used the copy assignment operator:

That's exactly correct:

Object2 is an lvalue expression (name of an existing object). Therefore, "CompilerTest("UsedObject") = Object2" selects the lvalue reference overload of the assignment operator.

The assignment operator returns lvalue reference to the 'this' object. Thefore, "Object5 = (x = y)" also selects the lvalue reference overload of the assignment operator.

If you want rvalue overloads to be selected, use std::move

[Peter87]

The move assignment operator was added in C++11 so I wouldn't call it a bug if a compiler doesn't support it yet. No compiler has implemented all of C++11 yet.

Object5 = CompilerTest("UsedObject") = Object2;
I'm not sure it's a bug.

This part CompilerTest("UsedObject") = Object2 should probably use the copy assignment operator. If you have implemented the copy assignment operator to return a lvalue reference then Object5 will be assigned with the copy assignment operator as well because the move assignment operator should only be used when passed a rvalue reference.

I don't know how, if possible, to implement a copy assignment operator returning a rvalue reference or lvalue reference depending on the object being assigned to.

EDIT: Ninja'd!

[4z0M4iN6]

I think, there don't need to be any discussion, about whether this is a bug or not. If somebody knows whom of the g++ developers to contact, for telling this bug, and if he or she does so, this would be enough.

Please be appreciative, if I don't take part in this discussion. If somebody thinks, he or she should mark this topic as resolved, then he or she should do it.

[kbw]

Very foolish, what the MS compilers did...g++ behaved very well

If I had a penny for every time I heard this comment ...

I think, there don't need to be any discussion, about whether this is a bug or not.

It's worth listening to what Cubbi and Peter87 said. They know what they're talking about. And you would listen to them if you had to pay for their advice.

[Cubbi]

Peter87 wrote:

I don't know how, if possible, to implement a copy assignment operator returning a rvalue reference or lvalue reference depending on the object being assigned to.

If you have clang++, you can try, I think, using ref-qualifiers for this

Something like

T&& operator=(T&& arg) && {
    data = std::move(arg.data);
    return *this;
}

(I don't know of other compilers that support them yet)

[1vRz3TCk]

dadabe wrote:

If somebody knows whom of the g++ developers to contact, for telling this bug, and if he or she does so, this would be enough.

Try: http://gcc.gnu.org/bugs/

[4z0M4iN6]

Thank you CodeMonkey. Then I will do it