Implementing assign operator ( = )

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

Since implement the assign operator for reference types eliminates the
ability to assign a reference object to a reference variable of the same
type or base class of that type, I assume that implementing the assign
operator ( = ), to assign the value of a type from one object to another
rather than the reference, should only be done for value types. Is there
any other reason for implementing the assign operator for a type ?
 
It can be useful for plumbing types. See msclr/auto_handle.h for an example.

Marcus
 
Edward said:
Since implement the assign operator for reference types eliminates the
ability to assign a reference object to a reference variable
Click to expand...

I don't think so. Assigning handles is like assigning pointers in
unmanaged code. operator= should be implemented to work on references.

MyRefClass^ object1;
MyRefClass^ object2;
object1 = object2; // assigns handles, does not copy the object
*object1 = *object2; // this calls operator=

With the stack syntax, you can assign objects in a more comfortable manner:

MyRefClass object1, object2;
object1 = object2; // this calls operator=

Either way, it only works in languages that support operator overloading
(such as C++/CLI).
to assign the value of a type from one object to another
rather than the reference, should only be done for value types.
Click to expand...

No, the opposite. It can only be done to ref classes. You can't have an
assignment operator for a value type, just like you can't have a copy
constructor either. Value types in .NET are like PODs in C++. When you
assign a value type, the framework does a raw memory memcpy. You can't
have custom assignment behavior there.

Tom
 
Tamas said:
I don't think so. Assigning handles is like assigning pointers in
unmanaged code. operator= should be implemented to work on references.

MyRefClass^ object1;
MyRefClass^ object2;
object1 = object2; // assigns handles, does not copy the object
*object1 = *object2; // this calls operator=
Click to expand...

This is different from all other operators. Are you sure this is how the
assignment operator works ?
With the stack syntax, you can assign objects in a more comfortable manner:

MyRefClass object1, object2;
object1 = object2; // this calls operator=
Click to expand...

This makes sense.
Either way, it only works in languages that support operator overloading
(such as C++/CLI).


No, the opposite. It can only be done to ref classes. You can't have an
assignment operator for a value type, just like you can't have a copy
constructor either. Value types in .NET are like PODs in C++. When you
assign a value type, the framework does a raw memory memcpy. You can't
have custom assignment behavior there.
Click to expand...

OK, I assume then I will get a compiler error if I try to implement the
assignment error for a value type.
 
Edward said:
This is different from all other operators. Are you sure this is how the
assignment operator works ?
Click to expand...

Yes, if it's implemented correctly. In ISO C++ it should be
T& operator=(const T&);

In C++/CLI it should be
T% operator=(T%);
or
T% operator=(const T%);

const is optional here. Since you can't declare a const member function,
passing arguments by const makes little sense (unfortunately). You would
be forced to cast the const-ness out quite frequently.

But that's irrelevant. The input argument is a T%, not a T^. Just like
in native C++, you don't write operator=(const T*). You don't want to
override the "copy a pointer" behavior. A pointer (or handle) is always
a value type, and making a copy of that should not involve any side
effects or custom behavior. If you're about to define
T^ operator=(T^);
then your original statement is correct, that would be very confusing,
and should be avoided. You don't want to do that, you don't want to
assign a custom behavior to a simple "pass by pointer" syntax.
OK, I assume then I will get a compiler error if I try to implement the
assignment error for a value type.
Click to expand...

Yes.

Tom
 
Edward said:
This is different from all other operators. Are you sure this is how the
assignment operator works ?
Click to expand...

I don't see how it's different from ISO C++. I just tried this:

ref class MyRefClass
{
public:
MyRefClass% operator=(MyRefClass% source)
{
Console::WriteLine("MyRefClass::operator=");
return *this;
}
};

int main(array<System::String ^> ^args)
{
MyRefClass^ object1 = gcnew MyRefClass;
MyRefClass^ object2 = gcnew MyRefClass;
object1 = object2;
}

There's no operator= called. But if I change the last line to *object1 =
*object2, it gets called as expected. Just like in native C++, except
replace handles with pointers.

I also tried to shoot myself in the foot, but the compiler didn't let me:

ref class MyRefClass
{
public:
MyRefClass^ operator=(MyRefClass^ source)
// malformed operator=
{
Console::WriteLine("BAD MyRefClass::operator=");
return *this;
}
};

int main(array<System::String ^> ^args)
{
MyRefClass^ object1 = gcnew MyRefClass;
MyRefClass^ object2 = gcnew MyRefClass;
object1 = object2;
}

operator= is not called, the compiler doesn't let you overload the
handle assignment operator. A handle is a value type, and its assignment
can't be overloaded. In this case you don't get an error -- the
malformed operator= simply won't be called.

Tom
 
Tamas said:
Yes, if it's implemented correctly. In ISO C++ it should be
T& operator=(const T&);

In C++/CLI it should be
T% operator=(T%);
or
T% operator=(const T%);
Click to expand...

OK, I understand this.

By analogy are you also saying that other operators should act the same
? So that for a + operator for a ref class I should have:

ref class X
{
public: static X% operator + ( X% first, X% second ) { // some code
returning a tracking reference to a new X }

// rather than

public: static X^ operator + ( X^ first, X^ second ) { // some code
returning a handle to a new X }

};

and the user should be doing:

X^ first;
X^ second;
X^ result;

*result = *first + *second;

rather than

result = first + second;

This is what I meant by the operator = being different from other
C++/CLI operators. In your assignment operator with a ref class you are
taking tracking references and returning a tracking reference, whereas
the second set of syntaxes above for my hypothetical operator + in a ref
class takes handles and returns a handle, while the first acts like your
assignment operator.
 
Edward said:
By analogy are you also saying that other operators should act the same
? So that for a + operator for a ref class I should have:

ref class X
{
public: static X% operator + ( X% first, X% second ) { // some code
returning a tracking reference to a new X }

// rather than

public: static X^ operator + ( X^ first, X^ second ) { // some code
returning a handle to a new X }

};
Click to expand...

You are right, in this case both operators are valid.
This is what I meant by the operator = being different from other
C++/CLI operators.
Click to expand...

Yes, I agree.

Tom
 
Back
Top