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

[Peter Duniho]

On Thu, 12 Jun 2008 10:24:44 -0700, Tony Johansson
<jo*****************@telia.comwrote:

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

Well, the words seem reasonably self-evident. Basically, they are calling
out the operators that can't be overloaded, and pointing out why. So,
what exactly about it don't you understand?

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

On Jun 12, 1:24*pm, "Tony Johansson" <[e-mail]>
wrote:

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.

[Peter Duniho]

On Thu, 12 Jun 2008 11:41:20 -0700, <qg**********@mailinator.comwrote:

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?

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.

You can take advantage of this to allow boolean operations on such a type,
even though you can't overload && and ||. By overloading & and |, as well
as "true" and "false", you allow the compiler to infer the correct && and
|| behavior. Paraphrasing the C# spec, where you have variables "x" and
"y" of a type T as described above, the expression "x && y" would be
evaluated as "T.false(x) ? x : T.&(x, y)" and the expression "x || y"
would be evaluated as "T.true(x) ? x : T.|(x, y)".

Since the type T would have the "true" and "false" operators overloaded,
the compiler can take the results from the & and | operators and convert
that from an instance of the type T to values of the actual "bool" type.
So the expressions above, which actually return a value of type T, could
then be run through the "true" or "false" operator, as appropriate to
whatever the final expression really is (I assume the compiler would use
the "true" operator for a plain expression and the "false" operator if
you've also used the negation operation !, but of course it could just
always use "true" and then perform whatever necessary logic on that
boolean after).

I don't know for sure why the language is like this. However, I can see
how designing it like this ensures that there is logical consistency
between the &&/|| operators and the &/| operators, any time the type
author decides they want their type to support both (it won't always make
sense for a type to support both, but in some cases it does).

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.

I don't think it's necessarily obvious at all, and for sure the MSDN docs
could do a much better job of elaboration. However, I definitely would
recommend that if these are questions you're curious about, you download
the C# spec, as it does generally answer these kinds of questions.

Of course, if you hadn't asked it, I never would have bothered to look at
the spec myself, and of course assuming my interpretation is useful, this
newsgroup would never have benefitted from having the question answer
posted here. So maybe it's better to just ask the question. :)

Pete

[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

[Peter Duniho]

On Thu, 12 Jun 2008 14:27:29 -0700, Chris Jobson
<ch**********@btinternet.comwrote:

>[...] (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.

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 :) ).
My point being that doing it in some other way could be confusing. That
said, the DB example you give seems reasonable (I didn't notice it when I
was looking at the spec). BUT! I by "reasonable" I just mean
"justified". I still think the design itself would be more confusing,
even in that example.

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!)

If I may:

The point would be that code that cared about "definitely true" would
check for "true"-ness, while code that cared about "definitely false"
would check for "false"-ness. I would guess that in most cases, it's not
so much that you'd check for "false" from both operators, but that you'd
have different code keying off of "true" results from either.

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.

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

Maybe if I get interested enough, later I'll look at what the spec says
about that. :)

Pete

[Chris Jobson]

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

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

[Peter Duniho]

On Fri, 13 Jun 2008 09:51:32 -0700, Chris Jobson
<ch**********@btinternet.comwrote:

[...]
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.

Interesting. That seems dangerous.

>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

And IMHO that would be a very bad time for the "false" operator to not
just be the opposite of the "true" operator. In particular, if you can
have both "false" and "true" return "false", maybe there's also some
scenario where you'd have both of them return "true". In which case
"myClass1 && myClass2" would be false, even though the expression could be
logically thought of as true.

I admit, the likelihood of it coming up seems exceedingly small. But it's
an odd gap in the spec for a language that otherwise seems to go to great
lengths to limit the opportunities to shoot oneself in the foot to those
where it's relatively obvious you're doing so. :)

Anyway, thanks for checking that out.

Pete