Thread: assignment operator

Since i_Value is a reference member, I am inclined to disable the copy assignment operator by declaring it private and not implementing it, but it looks like that is not an option for you.

You could still use the copy and swap idiom: implement a swap member function that swaps the i_myData member pointers, then implement the copy assignment operator using the copy constructor, swap member function and destructor.

It's impossible to reseat a reference.

If you want to produce that output, you'll need to replace the reference member with a pointer member.

Originally Posted by anon

It's impossible to reseat a reference.

If you want to produce that output, you'll need to replace the reference member with a pointer member.

Never "really" used a reference type variable, but can't you just change the object it references to like:

Code:

int* tmp = &i_Value;
*tmp = 100;

?

Originally Posted by laserlight

Since i_Value is a reference member, I am inclined to disable the copy assignment operator by declaring it private and not implementing it, but it looks like that is not an option for you.

You could still use the copy and swap idiom: implement a swap member function that swaps the i_myData member pointers, then implement the copy assignment operator using the copy constructor, swap member function and destructor.

Huh? (an example will be appreciated)

In a class I saw recently that contained a reference member, the assignment operator simply asserted that both references referred to the same object, and then assigned the remaining members. Perhaps you can do that?

You really need to know how the i_myData variable gets its value to complete this though, otherwise there is no way to know if whatever you implement is correct. It may be malloc'd new'd, new[]'d, be allocated from some special memory pool, just point to a global object, point to one of its own members, or a hundred other possibilites.
If this is all you are given then there is pretty much no right or wrong answer.

Originally Posted by C_ntua

Never "really" used a reference type variable, but can't you just change the object it references to like:

Code:

int* tmp = &i_Value;
*tmp = 100;

?

What that code snippet does is this: get the address of what i_Value refers to, e.g., i and store it in tmp. Set what tmp points to to 100, e.g., i is set to 100. The reference named i_Value still refers to i.

Originally Posted by C_ntua

Huh? (an example will be appreciated)

Basically, this:

Code:

class TFoo
{
public:
    // ...

private:
    // ...

    void operator=(const TFoo& other);
};

or this:

Code:

class TFoo
{
public:
    // ...

    TFoo& operator=(const TFoo& other)
    {
        TFoo temp(*this);
        swap(temp);
        return *this;
    }

    void swap(TFoo& other)
    {
        using std::swap;
        swap(i_myData, other.i_myData);
    }

    // ...
};

Of course, looking carefully at the desired sample output, I believe that what acosgaya wants to do cannot actually be done within the constraints for the reason that anon stated: references cannot be rebound.

Originally Posted by iMalc

In a class I saw recently that contained a reference member, the assignment operator simply asserted that both references referred to the same object, and then assigned the remaining members. Perhaps you can do that?

It is an option, but then the sample code would then cause the assertion to fail since foo1.i_Value and foo2.i_Value do not refer to the same object. My suggestion would cause a compile error in the first case and wrong output in the second case, but I cannot see a way around the wrong output without changing the reference to a pointer.

There is actually a technique, but it is strongly discouraged.

Code:

TFoo & operator= (TFoo & other) {
    if (this != &other)
    {
          this->~TFoo();
          new (this) TFoo(other.i_Value);
    }

    return *this;
  }

Generally, if such techniques are required, they are a warning sign indicating a badly broken class design.

This technique means that TFoo should never be used as a base class. Effectively, the assignment operator of derived classes (whether written by programmer, or compiler generated) will slice the object in different ways, depending on how users of the class do things.

More directly, since the constructor of TFoo takes a non-const reference to int, that it is necessary to remove the const qualifier from the "other" argument of the assignment operator. In other words, an assignment operation is allowed to modify the right hand side operand - in itself, this is (almost invariably) a positive indicator of a broken class design.

If the right hand side must be const, the implementation can be done as.

Code:

TFoo & operator= (const TFoo & other) {
    if (this != &other)
    {
          this->~TFoo();
          new (this) TFoo((const_cast<TFoo &>(other)).i_Value);
    }

    return *this;
  }

which is really just a sleight of hand: the specification of the assignment operator promises not to change other, but the implementation of the function does not honour that promise. Another indicator of a broken design.....

In the first, you are essentially destroying your object and re-creating it while your object is doing some work. grumpy also mentions other problems, and the problem is basically that new will always have the same type as the class it is in, whether or not that is a base class. So if a derived class uses that class as a base class, the object will destroy itself and create a new instance of the base class, and not the derived class, causing all sorts of problems.

As for the second, there is the problem of the assignment operator modifying the right-hand side. When you say x = y, then you expect x to equal y, but you also expect y to be unmodified. If y is then modified, it's usually a sign of a broken design. Therefore, the assignment operator typically takes a const type.

The last example is just as broken in that it works essentially the same. Only instead of taking a non-const type, it simply casts away the constness, which is even worse. It would allow code that would otherwise not compile to actually compile, causing all sorts of weirdness at runtime.