On Thu, 03 Jun 2004 07:38:18 +0000, Arcane Jill wrote:

> It says in the D manual: "The operators ., &&, ||, ?:, and a few others will likely never be overloadable".
> 
> I now have a class (Bool) which could really benefit from operator overloads for
> ! ||, and &&.

In C++ it is considered extremely bad practice to overload the logical &&/|| operators. The reason is that it is impossible for an overload to allow short-circuit evaluation. I think this is a good reason to not allow it.

Mike Swieton
__
God made the world and He saw that it was good. Not fair. Not happy. Nor
perfect. Good.
	- Mary Doria Russel, "Children of God"

In article <pan.2004.06.03.22.21.31.708194@swieton.net>, Mike Swieton says...
>
>In C++ it is considered extremely bad practice to overload the logical &&/|| operators. The reason is that it is impossible for an overload to allow short-circuit evaluation. I think this is a good reason to not allow it.

Yep, I agree, as I don't need it now.
Jill

In article <c9no4v$bi2$1@digitaldaemon.com>, Norbert Nemec says...
>
>Arcane Jill wrote:
>
[...]
>>>What's wrong with Matthew's boolean, if you really dislike bit?
>> 
>> boolean b = 1; is not a compile error.
>> Bool b = 1; is.
>
>Is that a practical problem? Strong typing is nice if it serves a purpose. Compiler errors are desirable if they prevent bugs. But writing your own Bool because the simple solution allows too much seems a bit pedantic to me?

In C I've found some bugs when a function that used to return a boolean value was changed to return an aritmetic value (normally from a found/not-found value to an index represented by an int or a pointer). Not all the code that looked like:

if (find(...))
{
..
}

was changed to:

if (find(...) != -1)
{
..
}

thus leading to bugs. The compiler wouldn't notice the change, that is _logical_
rather than _implementative_.
There are many ways to workaround this kind of bugs (such as making the function
return 0 or NULL when it before returned FALSE), but it happened again and again
for various reasons (inexperienced/lazy/uncollaborative programmers, etc), until
we switched to Java.

Ciao

Ok i see. Sorry.

In article <c9nq61$epk$1@digitaldaemon.com>, Arcane Jill says... [...]

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c9mr63$229r$1@digitaldaemon.com...
> Arcane Jill schrieb:
>
> > I now have a class (Bool) which could really benefit from operator overloads
for
> > ! ||, and &&.
>
> Why the hell a CLASS??? Making bool a reference type would make it either nearly unusable, or would be a huge performance penalty! (likely both) You have to make sure you .dup it every time you touch it, unless you want to be changing half of your Bools at random!
>
> What's wrong with bit? What's wrong with bool?
>
> What's wrong with Matthew's boolean, if you really dislike bit?
>
> I'm not sure seem to recall that Bjarne Stroustrup once wrote, that making short-cut operators overloadable was totally useless, or perhaps even dangerous.

That's covered in chapter 30 of "Imperfect C++"! :-)


Martin the Maudlin

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------

In article <c9mkha$1pbr$1@digitaldaemon.com>, Arcane Jill wrote:
> Obviously, ||, && and ?: are shortcut operators. In order to preserve this behavior, it would be necessary for the compiler to rewrite:
> 
>>       (a || b)
> 
> as:
> 
>>       (a ? a : a.opOrOr(b))
> 
> and
> 
>>       (a && b)
> 
> as:
> 
>>       (a ? a.opAndAnd(b) : a)

There must be some reason why they didn't come up with this in C++ and instead went for the scheme that loses the shortcut behavior.

Hmmm...  you'd need a conversion from the overloading type to 'bool' to resolve the ?: operator... at least in a boolean-wise sane language.

(On the other hand, you wouldn't have to write Bool in that language.)

_But_ then you could write funny boolean classes for (for instance)
fuzzy truth values.

And D language would probably be the first language to feature shortcut && and || on a _fuzzy_ truth value!

Now how cool is that!

-Antti

(P.S. I'm only partially joking.)

In article <slrncc756f.pd5.jsykari@pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?= says...
>
>In article <c9mkha$1pbr$1@digitaldaemon.com>, Arcane Jill wrote:
>> Obviously, ||, && and ?: are shortcut operators. In order to preserve this behavior, it would be necessary for the compiler to rewrite:
>> 
>>>       (a || b)
>> 
>> as:
>> 
>>>       (a ? a : a.opOrOr(b))
>> 
>> and
>> 
>>>       (a && b)
>> 
>> as:
>> 
>>>       (a ? a.opAndAnd(b) : a)
>
>There must be some reason why they didn't come up with this in C++ and instead went for the scheme that loses the shortcut behavior.
>
>Hmmm...  you'd need a conversion from the overloading type to 'bool' to resolve the ?: operator... at least in a boolean-wise sane language.
>
>(On the other hand, you wouldn't have to write Bool in that language.)
>
>_But_ then you could write funny boolean classes for (for instance)
>fuzzy truth values.
>
>And D language would probably be the first language to feature shortcut && and || on a _fuzzy_ truth value!
>
>Now how cool is that!
>
>-Antti
>
>(P.S. I'm only partially joking.)

I think the logic goes like this:

A && B .. becomes opAndAnd(A,B);

A is evaluated.
B is evaluated.

opAndAnd is executed:

A is false... oops, too late to shortcut, we already evaluated B!

Function parameters are evaluated before the function is run.  "&&" and "||" are flow control operators.  Trying to write opAndAnd() is like having a function that evaluates "half-inside" an if statement.

---

Now, this could still be done... But it requires a complete reinvention of the function to allow it to call back somehow when it needs the second parameter. In other words, opAndAnd() would tell the language when it was done with B, and the code to evaluate B would be called back, then control returns to opAndAnd. Would doing so break all C and C++ call-compatibility?  What if B is a complex function?  What if B throws an exception.  Also, evaluation of B really has to be done in the original stack frame.

It's easy to see why C++ designers just said No, once you understand the implementation issue.

A more practical technique is to evaluate A in a "boolean context", whatever that is defined to mean, then shortcut (or not), then evaluate B in a boolean context:  this isnt really a "custom" opAndAnd.

Kevin

In article <slrncc756f.pd5.jsykari@pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?= says...
>
>In article <c9mkha$1pbr$1@digitaldaemon.com>, Arcane Jill wrote:
>> Obviously, ||, && and ?: are shortcut operators. In order to preserve this behavior, it would be necessary for the compiler to rewrite:
>> 
>>>       (a || b)
>> 
>> as:
>> 
>>>       (a ? a : a.opOrOr(b))
>> 
>> and
>> 
>>>       (a && b)
>> 
>> as:
>> 
>>>       (a ? a.opAndAnd(b) : a)
>
>There must be some reason why they didn't come up with this in C++ and instead went for the scheme that loses the shortcut behavior.
>
>Hmmm...  you'd need a conversion from the overloading type to 'bool' to resolve the ?: operator... at least in a boolean-wise sane language.
>
>(On the other hand, you wouldn't have to write Bool in that language.)
>
>_But_ then you could write funny boolean classes for (for instance)
>fuzzy truth values.
>
>And D language would probably be the first language to feature shortcut && and || on a _fuzzy_ truth value!
>
>Now how cool is that!
>
>-Antti
>
>(P.S. I'm only partially joking.)

I think the logic goes like this:

A && B .. becomes opAndAnd(A,B);

A is evaluated.
B is evaluated.

opAndAnd is executed:

A is false... oops, too late to shortcut, we already evaluated B!

Function parameters are evaluated before the function is run.  "&&" and "||" are flow control operators.  Trying to write opAndAnd() is like having a function that evaluates "half-inside" an if statement.

---

Now, this could still be done... But it requires a complete reinvention of the function to allow it to call back somehow when it needs the second parameter. In other words, opAndAnd() would tell the language when it was done with B, and the code to evaluate B would be called back, then control returns to opAndAnd. Would doing so break all C and C++ call-compatibility?  What if B is a complex function?  What if B throws an exception.  Also, evaluation of B really has to be done in the original stack frame.

It's easy to see why C++ designers just said No, once you understand the implementation issue.

A more practical technique is to evaluate A in a "boolean context", whatever that is defined to mean, then shortcut (or not), then evaluate B in a boolean context:  this isnt really a "custom" opAndAnd.

Kevin