Assignment operator

[maluk]

What would happen if the overloaded assignment operator returns an object by value rather than by reference?

Meaning, the 'operator=' is implemented like below:

// Assume there is class named 'B' with a single member
// variable named 'int i'

B B::operator=( const B& b )
{
    B my_b ;
    
    my_b.i = b.i ;
    
    return ( my_b ) ;
}

rather than like this:

B& B::operator=( const B& b )
{
    // checking for self-assignment ommitted
    this->i = b.i ;
    return *this ;
}

What is it's impact to the program aside from the fact that is is poorly designed?


Rome did not create a great empire by having meetings, they did it by
killing all those who opposed them.

- janvier -

 

[uolj]

The assignment operator is meant to assign a value to the object. It's return value is mostly irrelevant. The important part is assigning the data members of "this" to the values in the passed in object.

In your first code example, you aren't assigning anything to "this", you are only changing the temporary object you created inside. That is why your first code is wrong.

Now, assuming that you meant for both code examples to assign and for the only difference to be the return value, then again, it doesn't matter quite so much, but returning a reference is likely to be more efficient (since it doesn't make an extra copy). Scott Meyers has an entire item (15) in Effective C++ about why to return a reference to "*this". Basically, the idea is to mimic the behavior of built-in types.

 

[maluk]

In your first code example, you aren't assigning anything to "this", you are only changing the temporary object you created inside. That is why your first code is wrong.

Thanks for the reply!

I know that the code returning by value rather than by reference is wrong when implementing assignment operators. I did a little test. I tried to implement an assignment operator that returns by value rather than by reference then implemented a copy constructor.

// Assume there is class named 'B' with a single member
// variable named 'int i'

B::B( const B& b )
{
    this->i = b.i ;
}

B B::operator=( const B& b )
{
    B my_b ;
    
    my_b.i = b.i ;
    
    return ( my_b ) ;
}

Basically, I think the code above does almost the same thing as when implementing the assignment operator by returning a reference to [tt]*this[/tt] since the copy constructor is called upon returning from [tt]operator=[/tt] thereby assigning the value to [tt]this[/tt]. However, I agree with you that this is inefficient and is a bad code design.



Rome did not create a great empire by having meetings, they did it by
killing all those who opposed them.

- janvier -

 

[uolj]

Basically, I think the code above does almost the same thing as when implementing the assignment operator by returning a reference to *this since the copy constructor is called upon returning from operator= thereby assigning the value to this.

No, you are not correct (at least I don't think so based on what I understand you to be saying).


The copy constructor is called, but it is called for a temporary object, not the actual object you are assigning to. The assignment operator is wrong, not because of the return value, but because you are not assigning the passed in value to the object. You are assigning it to a temporary object only.

Here are two implementations of an assignment operator. Both are legal (I believe). The first returns a reference, the second returns a value.

B& B::operator=( const B& b )
{
    // checking for self-assignment ommitted
    this->i = b.i ;
    return *this ;
}

B B::operator=( const B& b )
{
    // checking for self-assignment ommitted
    this->i = b.i ;
    return *this ;
}

That is the real comparison. Your example should be ignored completely because it is completely wrong, not just bad style.

 

[PerFnurt]

> Both are legal (I believe).

No. The assignment operator shall return a reference.

Consider:

void someFunction(A& a)
{
   // Do something with the a
}
...
{
  A a1;
  A a2;
  ...
  someFunction(a1 = a2);
}

Without reference, what A is passed to the function? Not a1 as one would expect. Whatever someFunction does to a will be lost in space...

/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[uolj]

> No. The assignment operator shall return a reference.

Is that according to the standard?

I don't see anything wrong with your example. It's basically the same as the following:

void someFunction(A& a)
{
   // Do something with the a
}
A someFunc2()
{
    A aTmp;
    return aTmp;
}
...
{
  A a1;
  A a2;
  ...
  someFunction(someFunc2());
}

Just because it doesn't make sense doesn't mean its illegal for someFunc2 to return by value.

 

[PerFnurt]

>Is that according to the standard?

Eh, no. According to me

> It's basically the same as the following

Basically yes, with the difference that you have certain expectations on a thing like

someFunc(a = 3);

Perhaps its just me that expects a and nothing else but a (no matter what type a is) to be passed to someFunc if it takes a ref. as input. If so, ignore my remarks as inane babbling.

Naturally, what you pass along to someFunction in

someFunction(someFunc2());

depends in someFunc2's signature and it'd be silly to have any other expectations on it.

/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[uolj]

Ok, cool. I agree with you. The assignment operator should return a reference. I have not heard a good reason not to. Your example gives a good reason to return by reference instead by value. It is more natural, since that is how built-in data types work.