About some understanding from a book

[Tony Johansson]

Hello!
I think that this text is complete enough so you can give me an explanation
what they mean with it.

I wonder if somebody understand what this means. It says the following :
"You can't overload assignment operator, such as +=, but these operator use
their simple counterpart, such as +, so you don't have to worry about that.
Overloading + means that += will function as expected.
The = operator is included in this -- it makes little sense to overload
this operator, since it has such a fundamental usage. This operator,
however,
is related to user-defined conversion operator, which you'll look at in the
next section."


//Tony

 

[Ignacio Machin ( .NET/ C# MVP )]

Hello!
I think that this text is complete enough so you can give me an explanation
what they mean with it.

I wonder if somebody understand what this means. It says the following :
"You can't overload assignment operator, such as +=, but these operator use
their simple counterpart, such as +, so you don't have to worry about that..
Overloading + means that += will function as expected.
The = operator is included in this -- it makes little sense to overload
this operator, since it has such a fundamental usage. This operator,
however,
is related to user-defined conversion operator, which you'll look at in the
next section."

//Tony

Hi,

What is what you do not understand?
It's saying that you cannot overload += but you can get the same
effect by overloading + (which makes a lot of sense) imagine how weird
it would be if :
a+= b
would be different than
a= a+ b

 

[qglyirnyfgfo]

Hi,

While we are talking about operator overload, could someone explain to
me how are you supposed to use the “true” and “false” unary operator
overload?

public static bool operator true(SomeClass x)
{
// …
}

public static bool operator false(SomeClass x)
{
// …
}

It’s probably very obvious and I am sure goggling it will shed some
light about how this supposed to work but I figure I post this here
since is somewhat related with the OP question.

Thanks.

 

[Chris Jobson]

If I read the spec correctly, these operators are used when you have a

type that semantically can be thought of as "true" or "false" (that is, it
essentially has some boolean state). You pass in an instance of the type,
and the "true" operator returns the bool "true" if the type is in the
"true" state. The "false" would be the inverse (you're required to define
both, but I expect you'd generally just have one call the other and invert
the result. Any other design could start to get confusing.

I just took a look at the spec out of interest, and it appears that the
"true" operator does not necessarily have to return the inverse of the
"false" operator. Section 11.4.2 of the spec shows a 3-valued type (database
boolean, which can be true, false or null) where operator true means
"definitely true" and operator false means "definitely false". Thus if the
value is null both operators return false. (I don't claim to understand the
logic behind this, but I have hopes that if I read it through a few more
times it will start to make sense!)

Chris Jobson

 

[Chris Jobson]

I just took a look at the spec out of interest, and it appears that the

Sure, that's what I implied, by writing "generally" rather than "this is
always how it'd be done" (I forgot to close my paren, but whatever ).

Fair enough.

....

That said, that brings me back to my previous supposition about how the
compiler would actually use those operators. In particular, in my mind
you'd write code like:

if (myClass)
{
// something we do only when it's "definitely true"
}

if (!myClass)
{
// something we do only when it's "definitely false"
}

But this would rely on the compiler _always_ using the ! operator as an
indicator to use the "false" operator instead of the "true" operator. I'd
have to go back and look at the spec, but unless it _specifically_ say
that the compiler is required to do this, then it's entirely possible a C#
compiler could just ignore the "false" operator and just always invert the
result of the "true" operator when faced with the ! operator.

I've had another look at the spec - I ought to have better things to do -
and AIUI when evaluating
myClass
as a boolean it first looks for an implicit conversion, and if there isn't
one it uses the "true" operator. Thus when evaluating
if (!myClass)
in the absence of an implicit conversion it _must_ invert the result of the
"true" operator.

In that scenario, the DB example would break, unless the compiler is
mandated to behave in a specific way.

The DB example solves the problem by defining its own version of the "!"
operator, so when evaluating
if (!myDBClass)
there's no need to evaluate myDBClass as a boolean and so the rules above
don't come into play.

Interestingly it appears from the spec that the _only_ time the "false"
operator is used is when evaluating
myClass1 && myClass2

Chris