Implementing assign operator ( = )

[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 ?

[Marcus Heege]

It can be useful for plumbing types. See msclr/auto_handle.h for an example.

Marcus

"Edward Diener" <ed*******************@tropicsoft.com> wrote in message
news:en**************@TK2MSFTNGP04.phx.gbl...

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 ?

[Tamas Demjen]

Edward Diener wrote:

Since implement the assign operator for reference types eliminates the
ability to assign a reference object to a reference variable
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.

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

[Edward Diener]

Tamas Demjen wrote:

Edward Diener wrote:

Since implement the assign operator for reference types eliminates the
ability to assign a reference object to a reference variable
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=

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=
This makes sense.

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.

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.

OK, I assume then I will get a compiler error if I try to implement the
assignment error for a value type.

[Tamas Demjen]

Edward Diener wrote:

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

This is different from all other operators. Are you sure this is how the
assignment operator works ?

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.

Yes.

Tom

[Tamas Demjen]

Edward Diener wrote:

This is different from all other operators. Are you sure this is how the
assignment operator works ?

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

[Edward Diener]

Tamas Demjen wrote:

Edward Diener wrote:

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

This is different from all other operators. Are you sure this is how
the assignment operator works ?

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%);

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.

[Tamas Demjen]

Edward Diener wrote:

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 }

};
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.

Yes, I agree.

Tom