Why isn't there a logical XOR operator?

Of course one can get the effect with appropriate use of existing
operators, but a ^^ operator would make for nice symmetry (as well as
useful to me in something I'm working on). Am I the only one who
would find it useful?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Christopher Benson-Manica <ataru@nospam.cyberspace.org> scribbled the following:[color=blue]
> Of course one can get the effect with appropriate use of existing
> operators, but a ^^ operator would make for nice symmetry (as well as
> useful to me in something I'm working on). Am I the only one who
> would find it useful?[/color]

You mean an operator that returns 1 if exactly one of its operands is
nonzero, and 0 otherwise? Yes, that would be useful. But forget about
the short-circuit semantics. Think about it and you'll see why.

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/

Joona I Palaste <palaste@cc.helsinki.fi> scribbled the following:[color=blue]
> Christopher Benson-Manica <ataru@nospam.cyberspace.org> scribbled the following:[color=green]
>> Of course one can get the effect with appropriate use of existing
>> operators, but a ^^ operator would make for nice symmetry (as well as
>> useful to me in something I'm working on). Am I the only one who
>> would find it useful?[/color][/color]
[color=blue]
> You mean an operator that returns 1 if exactly one of its operands is
> nonzero, and 0 otherwise? Yes, that would be useful. But forget about
> the short-circuit semantics. Think about it and you'll see why.[/color]

Also if there were an unary ^ operator, we could write Japanese smileys
into our code. For example:
sashimi ^=^ kawaii;

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"War! Huh! Good God, y'all! What is it good for? We asked Mayor Quimby."
- Kent Brockman

Christopher Benson-Manica wrote:
[color=blue]
> Of course one can get the effect with appropriate use of existing
> operators, but a ^^ operator would make for nice symmetry (as well as
> useful to me in something I'm working on). Am I the only one who
> would find it useful?
>[/color]
If you write your conditions to be all logical (that is avoid the if ( x )
style idioms), then using the existing xor operator would achieve exactly
the same thing as your proposed ^^, wouldn't it? I mean, there can be no
short-circuit evaluation of an xor operator.

-nrk.
--
Remove devnull for email

Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:
[color=blue]
> You mean an operator that returns 1 if exactly one of its operands is
> nonzero, and 0 otherwise? Yes, that would be useful. But forget about
> the short-circuit semantics. Think about it and you'll see why.[/color]

Hm, that's true. A ^^ B would have to evaluate A and B... I hadn't
thought of that, and I suppose that was a greater good than &/&&
and |/|| symmetry. Interesting.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:
[color=blue]
> Also if there were an unary ^ operator, we could write Japanese smileys
> into our code. For example:
> sashimi ^=^ kawaii;[/color]

This assumes, of course, that C authors are familiar with the Japanese
emoticon paradigm ^_~

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

"nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
news:maPTb.47$EH5.13@nwrddc01.gnilink.net...[color=blue]
> Christopher Benson-Manica wrote:
>[color=green]
> > Of course one can get the effect with appropriate use of existing
> > operators, but a ^^ operator would make for nice symmetry (as well as
> > useful to me in something I'm working on). Am I the only one who
> > would find it useful?
> >[/color]
> If you write your conditions to be all logical (that is avoid the if ( x )
> style idioms), then using the existing xor operator would achieve exactly
> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
> short-circuit evaluation of an xor operator.
>[/color]

(a ^^ b) would be something like ((!!a) != (!!b)). Could
be macrotized rather easily? Could the double bang be
reduced to a single bang on each side?

xarax <xarax@email.com> scribbled the following:[color=blue]
> "nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
> news:maPTb.47$EH5.13@nwrddc01.gnilink.net...[color=green]
>> Christopher Benson-Manica wrote:[color=darkred]
>> > Of course one can get the effect with appropriate use of existing
>> > operators, but a ^^ operator would make for nice symmetry (as well as
>> > useful to me in something I'm working on). Am I the only one who
>> > would find it useful?
>> >[/color]
>> If you write your conditions to be all logical (that is avoid the if ( x )
>> style idioms), then using the existing xor operator would achieve exactly
>> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
>> short-circuit evaluation of an xor operator.[/color][/color]
[color=blue]
> (a ^^ b) would be something like ((!!a) != (!!b)). Could
> be macrotized rather easily? Could the double bang be
> reduced to a single bang on each side?[/color]

Yes, ((!!a) != (!!b)) is equivalent to ((!a) != (!b)).

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd

Christopher Benson-Manica wrote:[color=blue]
>
> Of course one can get the effect with appropriate use of existing
> operators, but a ^^ operator would make for nice symmetry (as well as
> useful to me in something I'm working on). Am I the only one who
> would find it useful?[/color]

if (!!a ^ !!b) ....

c = !!a ^ !!b;

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

xarax wrote:
[color=blue]
> "nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
> news:maPTb.47$EH5.13@nwrddc01.gnilink.net...[color=green]
>> Christopher Benson-Manica wrote:
>>[color=darkred]
>> > Of course one can get the effect with appropriate use of existing
>> > operators, but a ^^ operator would make for nice symmetry (as well as
>> > useful to me in something I'm working on). Am I the only one who
>> > would find it useful?
>> >[/color]
>> If you write your conditions to be all logical (that is avoid the if ( x
>> ) style idioms), then using the existing xor operator would achieve
>> exactly
>> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
>> short-circuit evaluation of an xor operator.
>>[/color]
>
> (a ^^ b) would be something like ((!!a) != (!!b)). Could
> be macrotized rather easily? Could the double bang be
> reduced to a single bang on each side?[/color]

Yes, as x xor y is the same as x' xor y'. However, while this is pretty
neat, I think it makes the code harder to comprehend than using a straight
xor operation on the logical conditions (maybe its me that gets confused
when seeing negation all over the place).

And for those who believe that the xor shouldn't be used in combining
logical conditions, there is one situation where I have found this to be
eminently useful: when processing command line arguments where two
different options are mutually incompatible, but atleast one of them must
have been specified.

-nrk.

--
Remove devnull for email

In <bvodmk$3pe$1@chessie.cirr.com> Christopher Benson-Manica <ataru@nospam.cyberspace.org> writes:
[color=blue]
>Of course one can get the effect with appropriate use of existing
>operators, but a ^^ operator would make for nice symmetry (as well as
>useful to me in something I'm working on).[/color]

Because ^ is good enough, given the fact that a logical XOR operator
couldn't have any shortcircuiting semantics. !a ^ !b yields exactly
the same result as the hypothetical ^^ operator. If a and b are already
logical expressions (i.e. expressions that evaluate to 0 or 1), a ^ b is
enough.
[color=blue]
>Am I the only one who would find it useful?[/color]

Are you still convinced that it would be useful?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

On 3 Feb 2004 16:04:18 GMT, Joona I Palaste <palaste@cc.helsinki.fi>
wrote:
[color=blue]
>xarax <xarax@email.com> scribbled the following:[color=green]
>> "nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
>> news:maPTb.47$EH5.13@nwrddc01.gnilink.net...[color=darkred]
>>> Christopher Benson-Manica wrote:
>>> > Of course one can get the effect with appropriate use of existing
>>> > operators, but a ^^ operator would make for nice symmetry (as well as
>>> > useful to me in something I'm working on). Am I the only one who
>>> > would find it useful?
>>> >
>>> If you write your conditions to be all logical (that is avoid the if ( x )
>>> style idioms), then using the existing xor operator would achieve exactly
>>> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
>>> short-circuit evaluation of an xor operator.[/color][/color]
>[color=green]
>> (a ^^ b) would be something like ((!!a) != (!!b)). Could
>> be macrotized rather easily? Could the double bang be
>> reduced to a single bang on each side?[/color]
>
>Yes, ((!!a) != (!!b)) is equivalent to ((!a) != (!b)).[/color]

Huh? That's saying !!a is equivalent to !a. I think not.
Applying de Morgan's Theorem,
((!!a) != (!!b))
can be rewritten as:
! (!a == !b)
though.
-leor


Leor Zolman
BD Software
leor@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

[color=blue][color=green]
>>
>>Yes, ((!!a) != (!!b)) is equivalent to ((!a) != (!b)).[/color]
>
>Huh? That's saying !!a is equivalent to !a. I think not.[/color]

Oops, pounced too quick, sorry. Actually they're _all_ equivalent ;-)
-leor
[color=blue]
>Applying de Morgan's Theorem,
> ((!!a) != (!!b))
>can be rewritten as:
> ! (!a == !b)
>though.
> -leor
>
>
>Leor Zolman
>BD Software
>leor@bdsoft.com
>www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
>C++ users: Download BD Software's free STL Error Message
> Decryptor at www.bdsoft.com/tools/stlfilt.html[/color]

Leor Zolman
BD Software
leor@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

Leor Zolman wrote:[color=blue]
> Joona I Palaste <palaste@cc.helsinki.fi> wrote:
>[/color]
.... snip ...[color=blue][color=green]
> >
> >Yes, ((!!a) != (!!b)) is equivalent to ((!a) != (!b)).[/color]
>
> Huh? That's saying !!a is equivalent to !a. I think not.
> Applying de Morgan's Theorem,
> ((!!a) != (!!b))
> can be rewritten as:
> ! (!a == !b)
> though.[/color]

Huh? Look again. Write out a truth table or Karnaugh map.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

In <i8iv10tm9gtl9q1iduapaeggrdjrgjd9bt@4ax.com> Leor Zolman <leor@bdsoft.com> writes:
[color=blue]
>On 3 Feb 2004 16:04:18 GMT, Joona I Palaste <palaste@cc.helsinki.fi>
>wrote:
>[color=green]
>>xarax <xarax@email.com> scribbled the following:[color=darkred]
>>> "nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
>>> news:maPTb.47$EH5.13@nwrddc01.gnilink.net...
>>>> Christopher Benson-Manica wrote:
>>>> > Of course one can get the effect with appropriate use of existing
>>>> > operators, but a ^^ operator would make for nice symmetry (as well as
>>>> > useful to me in something I'm working on). Am I the only one who
>>>> > would find it useful?
>>>> >
>>>> If you write your conditions to be all logical (that is avoid the if ( x )
>>>> style idioms), then using the existing xor operator would achieve exactly
>>>> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
>>>> short-circuit evaluation of an xor operator.[/color]
>>[color=darkred]
>>> (a ^^ b) would be something like ((!!a) != (!!b)). Could
>>> be macrotized rather easily? Could the double bang be
>>> reduced to a single bang on each side?[/color]
>>
>>Yes, ((!!a) != (!!b)) is equivalent to ((!a) != (!b)).[/color]
>
>Huh? That's saying !!a is equivalent to !a. I think not.
>Applying de Morgan's Theorem,
> ((!!a) != (!!b))
>can be rewritten as:
> ! (!a == !b)
>though.[/color]

And, guess what? ! (!a == !b) can be rewritten as !a != !b. However,
given that the OP wanted a logical XOR operator, !a ^ !b reflects his
intention better.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

"nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
news:vJPTb.336$9a7.228@nwrddc02.gnilink.net...[color=blue]
> xarax wrote:
>[color=green]
> > "nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
> > news:maPTb.47$EH5.13@nwrddc01.gnilink.net...[color=darkred]
> >> Christopher Benson-Manica wrote:
> >>
> >> > Of course one can get the effect with appropriate use of existing
> >> > operators, but a ^^ operator would make for nice symmetry (as well as
> >> > useful to me in something I'm working on). Am I the only one who
> >> > would find it useful?
> >> >
> >> If you write your conditions to be all logical (that is avoid the if ( x
> >> ) style idioms), then using the existing xor operator would achieve
> >> exactly
> >> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
> >> short-circuit evaluation of an xor operator.
> >>[/color]
> >
> > (a ^^ b) would be something like ((!!a) != (!!b)). Could
> > be macrotized rather easily? Could the double bang be
> > reduced to a single bang on each side?[/color]
>
> Yes, as x xor y is the same as x' xor y'. However, while this is pretty
> neat, I think it makes the code harder to comprehend than using a straight
> xor operation on the logical conditions (maybe its me that gets confused
> when seeing negation all over the place).
>
> And for those who believe that the xor shouldn't be used in combining
> logical conditions, there is one situation where I have found this to be
> eminently useful: when processing command line arguments where two
> different options are mutually incompatible, but atleast one of them must
> have been specified.[/color]

If you think that's bad, try the following with
A,B:{0,1}. First column is the intended operation.
Middle column is the arithmetic equivalent. Last
column is an alternative logical expression. The
variables A,B have values from the set {0,1}.


NOT(A): 1-A
A AND B: A*B : NOT(NOT(A) OR NOT(B))
A NAND B: 1-A*B : NOT(A) OR NOT(B)
A OR B: A+B-A*B : NOT(NOT(A) AND NOT(B))
A NOR B: 1-A-B+A*B : NOT(A) AND NOT(B)
A == B: 1+2*A*B-A-B : A XNOR B
A <> B: A+B-2*A*B : A XOR B
A < B: B-B*A : NOT(A) AND B
A > B: A-A*B : A AND NOT(B)
A <= B: 1-A+A*B : NOT(A) OR B
A >= B: 1-B+A*B : A OR NOT(B)

nrk <ram_nrk2000@devnull.verizon.net> writes:[color=blue]
> Christopher Benson-Manica wrote:[color=green]
> > Of course one can get the effect with appropriate use of existing
> > operators, but a ^^ operator would make for nice symmetry (as well as
> > useful to me in something I'm working on). Am I the only one who
> > would find it useful?
> >[/color]
> If you write your conditions to be all logical (that is avoid the if ( x )
> style idioms), then using the existing xor operator would achieve exactly
> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
> short-circuit evaluation of an xor operator.[/color]

The result will be an expression that breaks the first time you feed
it an operand that doesn't have the value 0 or 1. This will happen at
the most inconvenient possible time.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Keith Thompson wrote:
[color=blue]
> nrk <ram_nrk2000@devnull.verizon.net> writes:[color=green]
>> Christopher Benson-Manica wrote:[color=darkred]
>> > Of course one can get the effect with appropriate use of existing
>> > operators, but a ^^ operator would make for nice symmetry (as well as
>> > useful to me in something I'm working on). Am I the only one who
>> > would find it useful?
>> >[/color]
>> If you write your conditions to be all logical (that is avoid the if ( x
>> ) style idioms), then using the existing xor operator would achieve
>> exactly
>> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
>> short-circuit evaluation of an xor operator.[/color]
>
> The result will be an expression that breaks the first time you feed
> it an operand that doesn't have the value 0 or 1. This will happen at
> the most inconvenient possible time.
>[/color]

Read carefully. What I meant was that, you couldn't write:
if ( x ^ y ),
but you could write:
if ( (x != 0) ^ (y != 0) )

-nrk.
--
Remove devnull for email

Dan Pop wrote:[color=blue]
>
> In <i8iv10tm9gtl9q1iduapaeggrdjrgjd9bt@4ax.com> Leor Zolman <leor@bdsoft.com> writes:
>[color=green]
> >On 3 Feb 2004 16:04:18 GMT, Joona I Palaste <palaste@cc.helsinki.fi>
> >wrote:
> >[color=darkred]
> >>xarax <xarax@email.com> scribbled the following:
> >>> "nrk" <ram_nrk2000@devnull.verizon.net> wrote in message
> >>> news:maPTb.47$EH5.13@nwrddc01.gnilink.net...
> >>>> Christopher Benson-Manica wrote:
> >>>> > Of course one can get the effect with appropriate use of existing
> >>>> > operators, but a ^^ operator would make for nice symmetry (as well as
> >>>> > useful to me in something I'm working on). Am I the only one who
> >>>> > would find it useful?
> >>>> >
> >>>> If you write your conditions to be all logical (that is avoid the if ( x )
> >>>> style idioms), then using the existing xor operator would achieve exactly
> >>>> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
> >>>> short-circuit evaluation of an xor operator.
> >>
> >>> (a ^^ b) would be something like ((!!a) != (!!b)). Could
> >>> be macrotized rather easily? Could the double bang be
> >>> reduced to a single bang on each side?
> >>
> >>Yes, ((!!a) != (!!b)) is equivalent to ((!a) != (!b)).[/color]
> >
> >Huh? That's saying !!a is equivalent to !a. I think not.
> >Applying de Morgan's Theorem,
> > ((!!a) != (!!b))
> >can be rewritten as:
> > ! (!a == !b)
> >though.[/color]
>
> And, guess what? ! (!a == !b) can be rewritten as !a != !b. However,
> given that the OP wanted a logical XOR operator, !a ^ !b reflects his
> intention better.[/color]

However, (!a != !b) reflects the intent of the code,
which is the logical relationship between a and b, better.

In any situation where I could write
if (!a ^ !b) {
I think I would rather write
if (!a != !b) {

Would you ever even write
if (!a ^ !b) {
?

That's the sort of thing that you would rather express as
if ((!a ^ !b) != 0) {
isn't it ?

--
pete

I officially nominate this question as a FAQ, and request that the first
update to the FAQ since February 7, 1999 be made.


--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

On 3 Feb 2004 16:09:18 GMT, Dan.Pop@cern.ch (Dan Pop) wrote:[color=blue]
>Are you still convinced that it would be useful?[/color]

Yes, for the same reason as || and &&, albeit there's no shortcutting. It
makes it *obvious* that a purely boolean expression is involved. !a ^ !b
isn't obviously purely boolean; the central operator is not boolean.


--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

Em Tue, 03 Feb 2004 17:05:14 +0000, CBFalconer escreveu:
[color=blue]
> Christopher Benson-Manica wrote:[/color]
<snip>
[color=blue]
> if (!!a ^ !!b) ....
>
> c = !!a ^ !!b;[/color]

Why !!a ? Doesn't this have the same effect of a? Like
if (a ^ b) ....
c = a ^ b;

Could you enlighten us?

--
Quidquid latine dictum sit altum viditur

On Tue, 3 Feb 2004, Dan Pop wrote:[color=blue]
>
> Christopher Benson-Manica writes:[/color]
[re: introducing a logical XOR operator][color=blue][color=green]
> >Of course one can get the effect with appropriate use of existing
> >operators, but a ^^ operator would make for nice symmetry (as well as
> >useful to me in something I'm working on).[/color]
>
> Because ^ is good enough, given the fact that a logical XOR operator
> couldn't have any shortcircuiting semantics. !a ^ !b yields exactly
> the same result as the hypothetical ^^ operator.[/color]

Possibly dumb, and possibly OT, question: What if 'a' and/or 'b' are
doubles with the IEEE value NaN, that screws up comparisons? Does
the !a^!b <==> a^^b equivalence still hold? (Or do NaN semantics already
make nonsense of certain operations?)
[color=blue]
> If a and b are already
> logical expressions (i.e. expressions that evaluate to 0 or 1), a ^ b is
> enough.
>[color=green]
> >Am I the only one who would find it useful?[/color]
>
> Are you still convinced that it would be useful?[/color]

Well, a logical xor operator wouldn't add anything to the capabilities
of the language, but then neither does having a special operator for
subtraction. I have, on occasion, run across situations where an XOR
operator would have been useful. Christopher mentioned command-line
argument parsing, such as:

[...]
switch (argv[i][j]) {
case 'K': KNRStyle = 1; break;
case 'A': AnsiStyle = 1; break;
}
[...]
if (KNRStyle ^^ AnsiStyle)
process(infp, outfp);
else
do_error("You must specify exactly one of -K, -A!\n");

Here the ^^ operator would capture the spirit of the condition better
than the != alternative, as well as being slightly more robust. The
suggested alternative,

if (!KNRStyle != !AnsiStyle)

is IMO so obfuscated as to be actually worse than simply enumerating
the cases:

if (KNRStyle && !AnsiStyle || AnsiStyle && !KNRStyle)


I also submit for consideration, as I've done before, the usefulness
of logical operators when dealing with pointers:

struct btnode {
int value;
struct btnode *left;
struct btnode *right;
};

int bt_IsUselessBranch(struct btnode *p)
{
return (p->value == 0) && (p->left ^^ p->right);
}

versus

return (p->value == 0) && (!(p->left) != !(p->right));

Of course, both cases are pretty ugly, here. But I haven't yet
come up with a good example. ;-)
And while I think it would have been cool if C had been designed
with a ^^ operator from the start, IMHO it's much too late now to
try adding it to the standard language. C doesn't need any more
syntax, and even if it did, I don't think the new syntax would find
many willing users. A new version of C would IMHO suffer the same
problems as C99 still suffers w.r.t. market share, only worse.
Now, a *new* language... :-)

-Arthur

José de Paula <jose_de_paula@ig.com.br> scribbled the following:[color=blue]
> Em Tue, 03 Feb 2004 17:05:14 +0000, CBFalconer escreveu:[color=green]
>> Christopher Benson-Manica wrote:[/color]
> <snip>[color=green]
>> if (!!a ^ !!b) ....
>>
>> c = !!a ^ !!b;[/color][/color]
[color=blue]
> Why !!a ? Doesn't this have the same effect of a? Like
> if (a ^ b) ....
> c = a ^ b;[/color]
[color=blue]
> Could you enlighten us?[/color]

No, it's not the same effect. The outcome is mostly the same, but
there are differences.
Suppose a is 1 and b is 2. a ^ b will now be 3, which is different
from 0, and thus C considers it true.
However !!a will be 1, and !!b will also be 1, so !!a ^ !!b will be
0, and thus C considers it false.
The ! operator is defined as returning 1 if its operand is 0, or
returning 0 if its operand is anything other. !! is two ! operators
together, they return 0 if their operand is 0, or 1 if their operand
is anything other.
This is often used as a neat trick to "force" non-zero values to 1,
making sure bitwise operators work right in place of logical operators.

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Make money fast! Don't feed it!"
- Anon

On Tue, 3 Feb 2004, [iso-8859-1] José de Paula wrote:[color=blue]
>
> Em Tue, 03 Feb 2004 17:05:14 +0000, CBFalconer escreveu:[color=green]
> > Christopher Benson-Manica wrote:[/color]
>[color=green]
> > if (!!a ^ !!b) ....
> >
> > c = !!a ^ !!b;[/color]
>
> Why !!a ? Doesn't this have the same effect of a? Like
> if (a ^ b) ....
> c = a ^ b;
>
> Could you enlighten us?[/color]

What is the value of 42?
What is the value of !!42?
What is the value of 42 ^ 6?
What is the value of !!42 ^ !!6?

-Arthur,
rhetorically

José de Paula wrote:
[color=blue]
> Em Tue, 03 Feb 2004 17:05:14 +0000, CBFalconer escreveu:
>
>[color=green]
>>Christopher Benson-Manica wrote:[/color]
>
> <snip>
>[color=green]
>> if (!!a ^ !!b) ....
>>
>> c = !!a ^ !!b;[/color]
>
>
> Why !!a ? Doesn't this have the same effect of a? Like
> if (a ^ b) ....
> c = a ^ b;
>
> Could you enlighten us?[/color]


Assume
a = 2;
b = 7;

Then
a ^ b == 2 ^ 7
== 5

which evaluates false in an if() statement

However
!a == 0

!!a == ! (!a)
== 1

!b == 0

!!b == ! (!b)
== 1

!!a ^ !!b == 1 ^ 1
== 0

which evaluates true in an if() statement


--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

Gak!! Another fingercheck/brainfart

Lew Pitcher wrote:
[color=blue]
> José de Paula wrote:
>[color=green]
>> Em Tue, 03 Feb 2004 17:05:14 +0000, CBFalconer escreveu:
>>
>>[color=darkred]
>>> Christopher Benson-Manica wrote:[/color]
>>
>>
>> <snip>
>>[color=darkred]
>>> if (!!a ^ !!b) ....
>>>
>>> c = !!a ^ !!b;[/color]
>>
>>
>>
>> Why !!a ? Doesn't this have the same effect of a? Like
>> if (a ^ b) ....
>> c = a ^ b;
>>
>> Could you enlighten us?[/color]
>
>
>
> Assume
> a = 2;
> b = 7;
>
> Then
> a ^ b == 2 ^ 7
> == 5
>
> which evaluates false in an if() statement[/color]
which evaluates /true/ in an if() statement
[color=blue]
>
> However
> !a == 0
>
> !!a == ! (!a)
> == 1
>
> !b == 0
>
> !!b == ! (!b)
> == 1
>
> !!a ^ !!b == 1 ^ 1
> == 0
>
> which evaluates true in an if() statement[/color]
which evaluates /false/ in an if() statement

--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

Arthur J. O'Dwyer wrote:[color=blue]
>
> On Tue, 3 Feb 2004, Dan Pop wrote:[color=green]
> >
> > Christopher Benson-Manica writes:[/color]
> [re: introducing a logical XOR operator][color=green][color=darkred]
> > >Of course one can get the effect with appropriate use of existing
> > >operators, but a ^^ operator would make for nice symmetry (as well as
> > >useful to me in something I'm working on).[/color]
> >
> > Because ^ is good enough, given the fact that a logical XOR operator
> > couldn't have any shortcircuiting semantics. !a ^ !b yields exactly
> > the same result as the hypothetical ^^ operator.[/color]
>
> Possibly dumb, and possibly OT, question: What if 'a' and/or 'b' are
> doubles with the IEEE value NaN, that screws up comparisons? Does
> the !a^!b <==> a^^b equivalence still hold? (Or do NaN semantics already
> make nonsense of certain operations?)
>[color=green]
> > If a and b are already
> > logical expressions (i.e. expressions that evaluate to 0 or 1), a ^ b is
> > enough.
> >[color=darkred]
> > >Am I the only one who would find it useful?[/color]
> >
> > Are you still convinced that it would be useful?[/color]
>
> Well, a logical xor operator wouldn't add anything to the capabilities
> of the language, but then neither does having a special operator for
> subtraction. I have, on occasion, run across situations where an XOR
> operator would have been useful. Christopher mentioned command-line
> argument parsing, such as:
>
> [...]
> switch (argv[i][j]) {
> case 'K': KNRStyle = 1; break;
> case 'A': AnsiStyle = 1; break;
> }
> [...]
> if (KNRStyle ^^ AnsiStyle)
> process(infp, outfp);
> else
> do_error("You must specify exactly one of -K, -A!\n");
>
> Here the ^^ operator would capture the spirit of the condition better
> than the != alternative, as well as being slightly more robust. The
> suggested alternative,
>
> if (!KNRStyle != !AnsiStyle)
>
> is IMO so obfuscated as to be actually worse than simply enumerating
> the cases:
>
> if (KNRStyle && !AnsiStyle || AnsiStyle && !KNRStyle)
>
> I also submit for consideration, as I've done before, the usefulness
> of logical operators when dealing with pointers:
>
> struct btnode {
> int value;
> struct btnode *left;
> struct btnode *right;
> };
>
> int bt_IsUselessBranch(struct btnode *p)
> {
> return (p->value == 0) && (p->left ^^ p->right);
> }
>
> versus
>
> return (p->value == 0) && (!(p->left) != !(p->right));
>
> Of course, both cases are pretty ugly, here.[/color]

.... without the extra parentheses:
return (p->value == 0) && (!p->left != !p->right);

explicit comparisons ...
((p->left == NULL) != (p->right == NULL));

With explicit comparisons against NULL,
as long as you have an odd number of nots, it's all the same.

((p->left == NULL) != (p->right == NULL));
((p->left != NULL) != (p->right != NULL));
((p->left != NULL) == (p->right == NULL));


--
pete

Em Tue, 03 Feb 2004 21:36:42 +0000, Joona I Palaste escreveu:[color=blue]
><snip>[/color]

I'm enlightened, thanks!

--
Quidquid latine dictum sit altum viditur
José - Threading The Long Path to Nerdvana

Christopher Benson-Manica <ataru@nospam.cyberspace.org> wrote:
# Of course one can get the effect with appropriate use of existing
# operators, but a ^^ operator would make for nice symmetry (as well as
# useful to me in something I'm working on). Am I the only one who
# would find it useful?

#define logical_equiv(p,q) (!(p)==!(q))
#define logical_xor(p,q) (!(p)!=!(q))
#define logical_implies(p,q) (!(p)<=!(q))

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I have no respect for people with no shopping agenda.

Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> wrote in message news:<gdvv10hto31sv0jddv85pf1rikaqiv0723@4ax.com>. ..[color=blue]
> I officially nominate this question as a FAQ, and request that the first
> update to the FAQ since February 7, 1999 be made.[/color]

I agree.

Kevin D. Quitt <KQuittUNMUNG@ieeincunmung.com> wrote:[color=blue]
>
> Yes, for the same reason as || and &&, albeit there's no shortcutting. It
> makes it *obvious* that a purely boolean expression is involved. !a ^ !b
> isn't obviously purely boolean; the central operator is not boolean.[/color]

Then use the other exclusive-or operator: !a != !b.

-Larry Jones

I don't need to improve! Everyone ELSE does! -- Calvin

nrk <ram_nrk2000@devnull.verizon.net> writes:[color=blue]
> Keith Thompson wrote:[color=green]
> > nrk <ram_nrk2000@devnull.verizon.net> writes:[color=darkred]
> >> Christopher Benson-Manica wrote:
> >> > Of course one can get the effect with appropriate use of existing
> >> > operators, but a ^^ operator would make for nice symmetry (as well as
> >> > useful to me in something I'm working on). Am I the only one who
> >> > would find it useful?
> >> >
> >> If you write your conditions to be all logical (that is avoid the if ( x
> >> ) style idioms), then using the existing xor operator would achieve
> >> exactly
> >> the same thing as your proposed ^^, wouldn't it? I mean, there can be no
> >> short-circuit evaluation of an xor operator.[/color]
> >
> > The result will be an expression that breaks the first time you feed
> > it an operand that doesn't have the value 0 or 1. This will happen at
> > the most inconvenient possible time.[/color]
>
> Read carefully. What I meant was that, you couldn't write:
> if ( x ^ y ),
> but you could write:
> if ( (x != 0) ^ (y != 0) )[/color]

Yeah, that would work. (I think it's ugly, but it would work.)

If I really had a need for logical xor, I'd probably use a macro,
something like:

#define XOR(a, b) (!(a) ^ !(b))

(I think that's right.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Keith Thompson <kst-u@mib.org> spoke thus:
[color=blue]
> #define XOR(a, b) (!(a) ^ !(b))[/color]

Finding an XOR in code would be rather annoying (to track down the
header file where it's defined), I would think.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> writes:
[color=blue]
> I officially nominate this question as a FAQ, and request that the first
> update to the FAQ since February 7, 1999 be made.[/color]

For what it's worth, I've added a page to my own personal FAQ
list:
http://www.msu.edu/~pfaffben/writing...gical-xor.html
Anyone have anything to add or dispute?
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein

On Tue, 3 Feb 2004, Ben Pfaff wrote:[color=blue]
>
> For what it's worth, I've added a page to my own personal FAQ
> list:
> http://www.msu.edu/~pfaffben/writing...gical-xor.html
> Anyone have anything to add or dispute?[/color]

Nit: "Far more rarely useful"? :) How about "far less often"?

And I would appreciate a clarification about how !a != !b interacts
with doubles, and some newbie no doubt would appreciate a clarification
about how it interacts with pointers. (!NULL == (int)1, !foo == (int)0;
but I am still waiting for someone more often correct than I to address
the question of !NaN.)

-Arthur

"Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> writes:
[color=blue]
> On Tue, 3 Feb 2004, Ben Pfaff wrote:[color=green]
>>
>> For what it's worth, I've added a page to my own personal FAQ
>> list:
>> http://www.msu.edu/~pfaffben/writing...gical-xor.html
>> Anyone have anything to add or dispute?[/color]
>
> Nit: "Far more rarely useful"? :) How about "far less often"?[/color]

Yes, that's much better phrasing. I will update it.
[color=blue]
> And I would appreciate a clarification about how !a != !b interacts
> with doubles, and some newbie no doubt would appreciate a clarification
> about how it interacts with pointers. (!NULL == (int)1, !foo == (int)0;
> but I am still waiting for someone more often correct than I to address
> the question of !NaN.)[/color]

I'm not sure what you'd like me to say about those cases. It
seems to me that, with the possible exception of NaN, they work
out okay.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell

Ben Pfaff wrote:
[color=blue]
> "Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> writes:
>[color=green]
>> On Tue, 3 Feb 2004, Ben Pfaff wrote:[color=darkred]
>>>
>>> For what it's worth, I've added a page to my own personal FAQ
>>> list:
>>> http://www.msu.edu/~pfaffben/writing...gical-xor.html
>>> Anyone have anything to add or dispute?[/color]
>>
>> Nit: "Far more rarely useful"? :) How about "far less often"?[/color]
>
> Yes, that's much better phrasing. I will update it.
>[color=green]
>> And I would appreciate a clarification about how !a != !b interacts
>> with doubles, and some newbie no doubt would appreciate a clarification
>> about how it interacts with pointers. (!NULL == (int)1, !foo == (int)0;
>> but I am still waiting for someone more often correct than I to address
>> the question of !NaN.)[/color]
>
> I'm not sure what you'd like me to say about those cases. It
> seems to me that, with the possible exception of NaN, they work
> out okay.[/color]

I am not sure if its in the C standard, but I believe NaN is to compare
unequal to any other number and even to NaN itself. Since ! yields 0 if
the operand is not equal to 0, if the above were true, one would expect
!NaN to yield 0.

-nrk.

--
Remove devnull for email

Ben Pfaff <blp@cs.stanford.edu> writes:[color=blue]
> Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> writes:
>[color=green]
> > I officially nominate this question as a FAQ, and request that the first
> > update to the FAQ since February 7, 1999 be made.[/color]
>
> For what it's worth, I've added a page to my own personal FAQ
> list:
> http://www.msu.edu/~pfaffben/writing...gical-xor.html
> Anyone have anything to add or dispute?[/color]

Other than the URL, there's no mention of the common abbreviation "xor";
there probably should be.

Another thing I just noticed: <iso646.h> defines the following
macros:

and &&
and_eq &=
bitand &
bitor |
compl ~
not !
not_eq !=
or ||
or_eq |=
xor ^
xor_eq ^=

The "and", "or", and "not" macros refer to the logical operators, but
the "xor" macro refers to the bitwise operator. If a logical-xor "^^"
operator were added, the asymmetry would be painful.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

> Ben Pfaff <blp@cs.stanford.edu> writes:[color=blue][color=green]
> > Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> writes:
> >[color=darkred]
> > > I officially nominate this question as a FAQ, and request that the first
> > > update to the FAQ since February 7, 1999 be made.[/color]
> >
> > For what it's worth, I've added a page to my own personal FAQ
> > list:
> > http://www.msu.edu/~pfaffben/writing...gical-xor.html
> > Anyone have anything to add or dispute?[/color][/color]

You say that logical xor is used much more rarely than logical and/or.
Question: Has anybody _ever_ found a situation where they would have
wanted a logical xor?

Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
[color=blue][color=green]
> > Ben Pfaff <blp@cs.stanford.edu> writes:[color=darkred]
> > > Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> writes:
> > >
> > > > I officially nominate this question as a FAQ, and request that the first
> > > > update to the FAQ since February 7, 1999 be made.
> > >
> > > For what it's worth, I've added a page to my own personal FAQ
> > > list:
> > > http://www.msu.edu/~pfaffben/writing...gical-xor.html
> > > Anyone have anything to add or dispute?[/color][/color]
>
> You say that logical xor is used much more rarely than logical and/or.
> Question: Has anybody _ever_ found a situation where they would have
> wanted a logical xor?[/color]

Yes. I often use the bits of an `unsigned int' struct member to
represent a number of two-state attributes of an object, and
to test for (a combination of) attributes, I use the idiom

if (x->flags & FLAG_FOO) ...
if ((x->flags & FLAG_BAR) || (y->flags & FLAG_BAZ)) ...

where the tokens starting with FLAG_ are macros that expand to an
unsigned int constant expression with one and only one bit that is
set to 1. For symmetry reasons, I would prefer it if I could also
write

if ((x->flags & FLAG_BLAH) ^^ (y->flags & FLAG_BLUBB)) ...

IMHO, that would look nicer (i.e., more like similar expressions
involving && or ||) than the alternatives.

Martin

In article <bvqf8i$3sm$01$1@news.t-online.com>,
Martin Dickopp <expires-2004-03-31@zero-based.org> wrote:
[color=blue]
> Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
>[color=green][color=darkred]
> > > Ben Pfaff <blp@cs.stanford.edu> writes:
> > > > Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> writes:
> > > >
> > > > > I officially nominate this question as a FAQ, and request that the
> > > > > first
> > > > > update to the FAQ since February 7, 1999 be made.
> > > >
> > > > For what it's worth, I've added a page to my own personal FAQ
> > > > list:
> > > > http://www.msu.edu/~pfaffben/writing...gical-xor.html
> > > > Anyone have anything to add or dispute?[/color]
> >
> > You say that logical xor is used much more rarely than logical and/or.
> > Question: Has anybody _ever_ found a situation where they would have
> > wanted a logical xor?[/color]
>
> Yes. I often use the bits of an `unsigned int' struct member to
> represent a number of two-state attributes of an object, and
> to test for (a combination of) attributes, I use the idiom
>
> if (x->flags & FLAG_FOO) ...
> if ((x->flags & FLAG_BAR) || (y->flags & FLAG_BAZ)) ...
>
> where the tokens starting with FLAG_ are macros that expand to an
> unsigned int constant expression with one and only one bit that is
> set to 1. For symmetry reasons, I would prefer it if I could also
> write
>
> if ((x->flags & FLAG_BLAH) ^^ (y->flags & FLAG_BLUBB)) ...
>
> IMHO, that would look nicer (i.e., more like similar expressions
> involving && or ||) than the alternatives.[/color]

Yes, but have you actually needed it? In a real life program? Has it
happened that you wanted to take some action if exactly one of the flags
was set, but not both?

(A relatively common case would be where you believe that two conditions
that look different should have the same truth values and you use an
assert to either confirm this or find errors in the program or your
understanding of the program. But in this case I would prefer == or !=
because they express this clearer. For example, you might have two
pointers src and dst, and you know that if one is not NULL then the
other is not NULL as well, so you might write assert ((src != NULL) ==
(dst != NULL)) .)

Christian Bau wrote:[color=blue]
>[color=green]
> > Ben Pfaff <blp@cs.stanford.edu> writes:[color=darkred]
> > > Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> writes:
> > >
> > > > I officially nominate this question as a FAQ, and request that the first
> > > > update to the FAQ since February 7, 1999 be made.
> > >
> > > For what it's worth, I've added a page to my own personal FAQ
> > > list:
> > > http://www.msu.edu/~pfaffben/writing...gical-xor.html
> > > Anyone have anything to add or dispute?[/color][/color]
>
> You say that logical xor is used much more rarely than logical and/or.
> Question: Has anybody _ever_ found a situation where they would have
> wanted a logical xor?[/color]

(!(a) != !(b)) is adequate for the situation.

unsigned char bit_rev(unsigned char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;
lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask > lo_mask);
return byte;
}

--
pete

Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
[color=blue]
> In article <bvqf8i$3sm$01$1@news.t-online.com>,
> Martin Dickopp <expires-2004-03-31@zero-based.org> wrote:
>[color=green]
> > Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
> >[color=darkred]
> > > > Ben Pfaff <blp@cs.stanford.edu> writes:
> > > > > Kevin D. Quitt <KQuittUNMUNG@IEEIncUNMUNG.com> writes:
> > > > >
> > > > > > I officially nominate this question as a FAQ, and request that the
> > > > > > first
> > > > > > update to the FAQ since February 7, 1999 be made.
> > > > >
> > > > > For what it's worth, I've added a page to my own personal FAQ
> > > > > list:
> > > > > http://www.msu.edu/~pfaffben/writing...gical-xor.html
> > > > > Anyone have anything to add or dispute?
> > >
> > > You say that logical xor is used much more rarely than logical and/or.
> > > Question: Has anybody _ever_ found a situation where they would have
> > > wanted a logical xor?[/color]
> >
> > Yes. I often use the bits of an `unsigned int' struct member to
> > represent a number of two-state attributes of an object, and
> > to test for (a combination of) attributes, I use the idiom
> >
> > if (x->flags & FLAG_FOO) ...
> > if ((x->flags & FLAG_BAR) || (y->flags & FLAG_BAZ)) ...
> >
> > where the tokens starting with FLAG_ are macros that expand to an
> > unsigned int constant expression with one and only one bit that is
> > set to 1. For symmetry reasons, I would prefer it if I could also
> > write
> >
> > if ((x->flags & FLAG_BLAH) ^^ (y->flags & FLAG_BLUBB)) ...
> >
> > IMHO, that would look nicer (i.e., more like similar expressions
> > involving && or ||) than the alternatives.[/color]
>
> Yes, but have you actually needed it?[/color]

Yes. (Well, "needed" is too strong, but I would have liked to have it.)
[color=blue]
> In a real life program?[/color]

Not in a program I have been paid to write. In fact, not in a program
I have published yet. But in a program that is supposed to be applied to
a real life problem - it's not some kind of contrived example program.
[color=blue]
> Has it happened that you wanted to take some action if exactly one of
> the flags was set, but not both?[/color]

One flag describes whether an object is "active" in some sense (for
example, a GUI element which can be "selected" or "unselected"). The
other flag describes what the former flag should be set to. If and only
if the former flag will change, i.e. the object is inactive and will be
activated or it is active and will be deactivated, some actions are to
be performed (e.g., a GUI element will be redrawn).

Martin

"Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message news:<Pine.LNX.4.58-035.0402031505350.15317@unix41.andrew.cmu.edu>...[color=blue]
> Of course, both cases are pretty ugly, here. But I haven't yet
> come up with a good example. ;-)
> And while I think it would have been cool if C had been designed
> with a ^^ operator from the start, IMHO it's much too late now to
> try adding it to the standard language. C doesn't need any more
> syntax, and even if it did, I don't think the new syntax would find
> many willing users. A new version of C would IMHO suffer the same
> problems as C99 still suffers w.r.t. market share, only worse.
> Now, a *new* language... :-)[/color]

This is what I do when I need xor:

static inline int xor (int a, int b)
{
return a ? !b : b;
}

OR implement this with the binary '^' operator (I think it's slower
if you optimize).

The thing is that we couldn't do this with || and &&, because
these have early termination. And that's probably the reason for
their existance. In xor both must be evaluated.

And another problem is multiple xors. What happens then??

a ^^ b ^^ c ????

So xor is rather special


Stelios

stelios xanthakis wrote:[color=blue]
> And another problem is multiple xors. What happens then??
>
> a ^^ b ^^ c ????
>
> So xor is rather special[/color]

No more than (e.g.) == or < in this respect as far as I can see.

Jeremy.

"Jeremy Yallop" <jeremy@jdyallop.freeserve.co.uk> wrote in message
news:slrnc21ukj.i5b.jeremy@hehe.cl.cam.ac.uk...[color=blue]
> stelios xanthakis wrote:[color=green]
> > And another problem is multiple xors. What happens then??
> >
> > a ^^ b ^^ c ????
> >
> > So xor is rather special[/color]
>
> No more than (e.g.) == or < in this respect as far as I can see.[/color]

== is a short circuit though. The intention would be that ^^ would be a
short-circuit (otherwise I don't see the point) and as the others pointed
out you have to evaluate both sides to determine the result (therefore it
cannot short circuit).

What you could do is make ^& and ^| for NAND and NOR (former shorts if left
is zero, latter if left is one) and you'd have all four short-circuits ;-)

Well actually make ^& into ^^ since it's ambiguous with ^&varname, etc...so
you get

^^ = NAND
^| = NOR
|| = OR
&& = AND

Tom

mayall@freemail.gr (stelios xanthakis) writes:
[color=blue]
> And another problem is multiple xors. What happens then??
>
> a ^^ b ^^ c ????[/color]

I guess it would have left-to-right associativity just like &&
and ||, i.e. behave like (a ^^ b) ^^ c. But even if it behaved
like a ^^ (b ^^ c), the result would be the same. Where do you
see a problem?

Martin

"Martin Dickopp" <expires-2004-03-31@zero-based.org> wrote in message
news:bvr1e8$ad2$05$2@news.t-online.com...[color=blue]
> mayall@freemail.gr (stelios xanthakis) writes:
>[color=green]
> > And another problem is multiple xors. What happens then??
> >
> > a ^^ b ^^ c ????[/color]
>
> I guess it would have left-to-right associativity just like &&
> and ||, i.e. behave like (a ^^ b) ^^ c. But even if it behaved
> like a ^^ (b ^^ c), the result would be the same. Where do you
> see a problem?[/color]

You cannot short circuit the XOR logical op. So what's the point?

Tom

"Tom St Denis" <tomstdenis@iahu.ca> wrote:
[color=blue]
> "Jeremy Yallop" <jeremy@jdyallop.freeserve.co.uk> wrote in message
> news:slrnc21ukj.i5b.jeremy@hehe.cl.cam.ac.uk...[color=green]
> > stelios xanthakis wrote:[color=darkred]
> > > And another problem is multiple xors. What happens then??
> > >
> > > a ^^ b ^^ c ????
> > >
> > > So xor is rather special[/color]
> >
> > No more than (e.g.) == or < in this respect as far as I can see.[/color]
>
> == is a short circuit though.[/color]

No, it's not.

a == b

needs to evaluate both a and b, and

a == b == c

needs to evaluate all three.

Richard