Wed, 19 Sep 2001 18:17:47 GMT, James Russell Kuyper Jr. <kuyper@wizard.ne=
t> pisze:

>> 3 ^^ 5 is false, 3 !=3D 5 is true.  ^^ is defined on bool and conversi=
ons
>> do not yeild the same result as !=3D on the originals.
>=20
> When would you ever want to use ^^ on non-booleans?

For the same reason as why && and || are used on non-booleans. A C++
convention is that several types define their truth value as something
similar to "non-zero".

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

The standard defines keyword "bitand" for a bitwise
and-operation, and "bitor" for a bitwise or-operation.

Why doesn't it define "bitxor" for a bitwise xor-operation?
Instead "xor" was chosen as name for that.

What is the reason for this inconsistency?


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Michael Andres" <cizarre@gmx.net> wrote in message
news:8fbd32b9.0109170124.322dbf72@posting.google.com...
> The standard defines keyword "bitand" for a bitwise
> and-operation, and "bitor" for a bitwise or-operation.
>
> Why doesn't it define "bitxor" for a bitwise xor-operation?
> Instead "xor" was chosen as name for that.
>
> What is the reason for this inconsistency?

Probably because there is no logical xor operation, as there is
for 'and' and 'or'??

&    --> 'bitand'
&&    --> 'and'

|    --> 'bitor'
||    --> 'or'

^    --> xor

~Jeff


>
>
>  - Michael
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
>
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>
> The standard defines keyword "bitand" for a bitwise
> and-operation, and "bitor" for a bitwise or-operation.
>
> Why doesn't it define "bitxor" for a bitwise xor-operation?
> Instead "xor" was chosen as name for that.
>

because there is no non-bitwise xor.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

cizarre@gmx.net (Michael Andres) writes:

> The standard defines keyword "bitand" for a bitwise
> and-operation, and "bitor" for a bitwise or-operation.
>
> Why doesn't it define "bitxor" for a bitwise xor-operation?
> Instead "xor" was chosen as name for that.
>
> What is the reason for this inconsistency?

The standard had to use "bitand" and "bitor" (for & and | respectively),
because "and" and "or" were already taken (by && and ||).  No such
consideration applied to "xor", because there is no "^^" operator.  So
we may as well use the simple name, "xor", for the only xor operation
that exists in the language.

(The natural next question, which might qualify as a FAQ, is why there
is no ^^ operator.  Answer: the biggest difference between & and &&,
and between | and ||, is short-circuiting.  But it's impossible to
short-circuit xor, so there's no point in having an ^^ operator.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>
> The standard defines keyword "bitand" for a bitwise
> and-operation, and "bitor" for a bitwise or-operation.
>
> Why doesn't it define "bitxor" for a bitwise xor-operation?
> Instead "xor" was chosen as name for that.
>
> What is the reason for this inconsistency?

The logical equivalent of | is ||, both of which are known as "AND", so
they needed to be distinguished from each other. The method chosen was
to prefix the bitwise operator with 'bit'. However, the logical
equivalent of ^ is != (at least when it's restricted to boolean
operands). There's no reasonable confusion between xor and not-eq, so
there was no need to prefix it with 'bit'. Still, I suppose you could
argue that it would be more consistent to call it bitnot-eq.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Matthew Austern <austern@research.att.com> wrote in message news:<dilsndl921g.fsf@isolde.research.att.com>...
> cizarre@gmx.net (Michael Andres) writes:
>
> > The standard defines keyword "bitand" for a bitwise
> > and-operation, and "bitor" for a bitwise or-operation.
> >
> > Why doesn't it define "bitxor" for a bitwise xor-operation?
> > Instead "xor" was chosen as name for that.
> >
> > What is the reason for this inconsistency?
>
> The standard had to use "bitand" and "bitor" (for & and | respectively),
> because "and" and "or" were already taken (by && and ||).  No such
> consideration applied to "xor", because there is no "^^" operator.  So
> we may as well use the simple name, "xor", for the only xor operation
> that exists in the language.

I know that there is no "^^" operator. I would have chosen "bitxor"
although it is the only xor operation because it would follow a more
consistent naming scheme.

> (The natural next question, which might qualify as a FAQ, is why there
> is no ^^ operator.  Answer: the biggest difference between & and &&,
> and between | and ||, is short-circuiting.  But it's impossible to
> short-circuit xor, so there's no point in having an ^^ operator.)

That was my next question. :)

Here is another one: Why is it so important to bind an operator ^^ to
short-circuiting? If I define

inline bool XOR(bool lhs, bool rhs)
{
  return (lhs && !rhs) || (!lhs && rhs);
}


then I can use it in logical operations like

  if (XOR(a, b)) // ...

Here a and b are evaluated without short-circuiting and the result of
the operation is what it is expected to be.

Furthermore something similar happens with an overloaded operator|| or
operator&&. It might be argued that it was a mistake to allow overloading
for operator|| and operator&& but that is not a strong argument against
allowing a logical xor operation.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Matthew Austern <austern@research.att.com> wrote in message
news:dilsndl921g.fsf@isolde.research.att.com...

> (The natural next question, which might qualify as a FAQ, is why there
> is no ^^ operator.  Answer: the biggest difference between & and &&,
> and between | and ||, is short-circuiting.  But it's impossible to
> short-circuit xor, so there's no point in having an ^^ operator.)

I don't regard that as valid. && and || are boolean operators and it natural
for any given computer language to support these. The fact that they
short-circuit is a side-effect to do with C and C++, nothing to do with
their intrinsic properties as boolean operators. IMO, ^^ should exist as the
mathematical boolean properties for xor are well defined. That fact that it
would not short-circuit is neither here nor there.  I also note that the
unary boolean operator ! exists for C and C++ yet it has no short-circuiting
properties.

Cheers

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>
> Matthew Austern <austern@research.att.com> wrote in message news:<dilsndl921g.fsf@isolde.research.att.com>...
> > The standard had to use "bitand" and "bitor" (for & and | respectively),
> > because "and" and "or" were already taken (by && and ||).  No such
> > consideration applied to "xor", because there is no "^^" operator.  So
> > we may as well use the simple name, "xor", for the only xor operation
> > that exists in the language.
>
> I know that there is no "^^" operator. I would have chosen "bitxor"
> although it is the only xor operation because it would follow a more
> consistent naming scheme.

How about

#define bitxor ^
#define xor !=

AFAICS, this would give you exactly what you need although #define's are
always a bad idea as they affect others sources as well (if you write a
lib or something).

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo   -Rahe-Stra   e 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Stephen Howe wrote:
>
> Matthew Austern <austern@research.att.com> wrote in message
> news:dilsndl921g.fsf@isolde.research.att.com...
>
> > (The natural next question, which might qualify as a FAQ, is why there
> > is no ^^ operator.  Answer: the biggest difference between & and &&,
> > and between | and ||, is short-circuiting.  But it's impossible to
> > short-circuit xor, so there's no point in having an ^^ operator.)
>
> I don't regard that as valid. && and || are boolean operators and it natural
> for any given computer language to support these. The fact that they
> short-circuit is a side-effect to do with C and C++, nothing to do with
> their intrinsic properties as boolean operators. IMO, ^^ should exist as the
> mathematical boolean properties for xor are well defined. That fact that it

What's the matter with using != instead of ^^ ?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Tue, 18 Sep 2001 23:34:50 GMT, "James Russell Kuyper Jr."
<kuyper@wizard.net> wrote:

> Stephen Howe wrote:

> > I don't regard that as valid. && and || are boolean operators and it natural
> > for any given computer language to support these. The fact that they
> > short-circuit is a side-effect to do with C and C++, nothing to do with
> > their intrinsic properties as boolean operators. IMO, ^^ should exist as the
> > mathematical boolean properties for xor are well defined. That fact that it
>
> What's the matter with using != instead of ^^ ?

3 ^^ 5 is false, 3 != 5 is true.  ^^ is defined on bool and conversions
do not yeild the same result as != on the originals.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Daniel Frey wrote:
>
> Michael Andres wrote:
> >
> > Matthew Austern <austern@research.att.com> wrote in message news:<dilsndl921g.fsf@isolde.research.att.com>...
> > > The standard had to use "bitand" and "bitor" (for & and | respectively),
> > > because "and" and "or" were already taken (by && and ||).  No such
> > > consideration applied to "xor", because there is no "^^" operator.  So
> > > we may as well use the simple name, "xor", for the only xor operation
> > > that exists in the language.
> >
> > I know that there is no "^^" operator. I would have chosen "bitxor"
> > although it is the only xor operation because it would follow a more
> > consistent naming scheme.
>
> How about
>
> #define bitxor ^
> #define xor !=

That won't work. 'xor' get parsed during preprocessing as
"preprocessing-op-or-punc" (see 2.12p1), and therefore can't be parsed
as an identifier. The thing that immediately follows a #define is
required to be an identifier. What you've written is precisely
equivalent to:

#define ^ !=

Which is a syntax error. See also Table 4, in 2.11p2, which makes xor
reserved to the implementation in all contexts.

If the symmetry with bitand and bitor is important to you, you might
instead try:

#define bitnot_eq ^

That won't conflict with any of the standard tokens.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Russell Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3BA7D93F.C22859E7@wizard.net...

> > I don't regard that as valid. && and || are boolean operators and it
natural
> > for any given computer language to support these. The fact that they
> > short-circuit is a side-effect to do with C and C++, nothing to do with
> > their intrinsic properties as boolean operators. IMO, ^^ should exist as
the
> > mathematical boolean properties for xor are well defined. That fact that
it
>
> What's the matter with using != instead of ^^ ?

Nothing wrong. But I have to do

if (boolexpression1 != boolexpression2)
    ;       // equivalent to ^^ (bool xor)

and

if ((boolexpression1 != boolexpression2) != boolexpression3)
    ;       // equivalent to ^^ (bool xor)

for 3 bool expressions and so on.

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I just want to point out that from the Boolean point of view, xor is the
same as not <=> (and not !=). One can classify the Boolean function is two
variables:

The number of Boolean functions in n variables is 2^(2^n). When n = 2,
this gives 16 functions. There are two functions not depending on any
argument, namely: "false" and "true". Also the functions only depending on
one argument are "first" and "second", and their negations.

This makes a total of six function that do not depend on at least one
argument, so ten remains, namely
    and    or    =>    <=    <=>
plus their negations. And as said above, the negation of <=> is xor.

One can also remark that the reason that one has both operators | and ||
etc., is from the history from C as a largely untyped language, where one
has added operators in order to conform to common low-level CPU features.
If one would continue the C++ programme of name overloading and typing,
this would not be needed:

Then the Boolean "and" and "or" would be applied to the type bool, which
has only one atom "true". The bitwise operators |, &, etc., correspond to
the application on a type bool<n>, where n is the number of bits.

So the introduction of such types would make the need for such operator
duplicates go away. (Even though one in C++ might prefer a type binary<n>
with some additional bit operations, like shifts and rotations.)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Potter wrote:
>
> On Tue, 18 Sep 2001 23:34:50 GMT, "James Russell Kuyper Jr."
> <kuyper@wizard.net> wrote:
>
> > Stephen Howe wrote:
>
> > > I don't regard that as valid. && and || are boolean operators and it natural
> > > for any given computer language to support these. The fact that they
> > > short-circuit is a side-effect to do with C and C++, nothing to do with
> > > their intrinsic properties as boolean operators. IMO, ^^ should exist as the
> > > mathematical boolean properties for xor are well defined. That fact that it
> >
> > What's the matter with using != instead of ^^ ?
>
> 3 ^^ 5 is false, 3 != 5 is true.  ^^ is defined on bool and conversions
> do not yeild the same result as != on the originals.

When would you ever want to use ^^ on non-booleans?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

James Russell Kuyper Jr. (kuyper@wizard.net) wrote:
> What's the matter with using != instead of ^^ ?

My xor FAQ follows.

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

People often ask why there isn't a logical exclusive-or operator.
After all, the && and || operators exist, so perhaps ^^ should, too.

What would ^^ do?  Presumably, it would be as similar as possible
to && and ||, so we should study their attributes:

1) Left-to-right evaluation
   f() && g() calls f() before g()

2) Short-circuit evaluation
   f() && g() doesn't call g() if f() is false.

3) Sequence point
   *p++ && *p++ is well-defined

4) Treating the arguments as boolean values
   (1 && 2)==1, whereas (1 & 2)==0.
   (3 && "hello")==1, whereas (3 & "hello") is a syntax error

5) A boolean result
   (5 && 6)==1, whereas (5 & 6)==4.
   In C++, the operands and result of && and || are bool, not int,
   but the essence is the same.

The mythical ^^ operator can't do (2), but the others are possible.

Proposed code  left-to-right?  sequence point?  bool args?  bool result?
--------------   --------------  ---------------  ----------  ------------
a ^ b                no              no             no          no
a != b                no              no             no          yes
(!a)!=(!b)             no              no             yes         yes
my_xor_func(a,b)       no              no             yes         yes
a ? !b : b             yes             yes       yes         no
a ? !b : !!b           yes             yes       yes         yes

The fact that you can achieve the same effect using a ? !b : !!b doesn't
end the discussion.  A ^^ operator might be useful for clarity and brevity.

"I've never needed a ^^ operator."  It's hard to say--our tools guide our
thinking.  Nobody uses ^^ now, because it's not available.  If it were
available, perhaps it would get used.

Does anybody have any quotes from Bjarne Stroustrup on this?

Dennis Ritchie said:

> There are both historical and practical reasons why there is no ^^
> operator.  The practical is: there's not much use for the operator.
> The main point of && and || is to take advantage of their
> short-circuit evaluation not only for efficiency reasons, but more
> often for expressiveness and correctness. For example, in
>
>   if (cond1() && cond2()) ...
>
> it is often important that cond1() is done first, because if it's false
> cond2() may not be well defined, or because cond1() is cheap and
> cond2() is expensive.  Syntax to handle the situation has made it into
> lots of languages; compare Ada's "and then'. By contrast, an ^^
> operator would always force evaluation of both arms of the expression,
> so there's no efficiency gain.  Furthermore, situations in which ^^ is
> really called for are pretty rare, though examples can be created.
> These situations get rarer and stranger as you stack up the operator--
>
>   if (cond1() ^^ cond2() ^^ cond3() ^^ ...) ...
>
> does the consequent exactly when an odd number of the condx()s
> are true.   By contrast, the && and || analogs remain fairly plausible
> and useful.
>
> Historical:  C's predecessors (B and BCPL) had only the bitwise
> versions of | & ^.   They also had a special rule, namely that in an
> statement like
>
>  if (a & b) ...
>
> the '&", being at the 'top level' of the expression occurring  in
> `truth-value context' (inside the if())  was interpreted just
> like C's &&.  Similarly for |. But not so for ^.
>
> One of the early bits of C evolution was the creation of separate
> && and || operators.  This was better than the special rule, which was
> hard to explain.
>
> In other words, the whole question arises because of the particular
> method of symmetry-breaking that C chose.   Suppose I had reacted to
> the situation of BCPL and B taking their notion of
>
>  if (a & b) ...
>
> and had people say
>
>  if (a) andif (b) ...
>
> (and similarly with "orif")  One can make a case that this kind of
> syntax is better than && and ||,   If it had happened,
> would people be asking for "xorif"? Probably not.
>
> My guess is that &, &&; |,||; ^,^^ is a false symmetry.  But it's
> one that people seem to want, and, though it's not much help,
> adding it wouldn't do much harm.
>
>  Dennis

--
Jack Applin
neutron@fc.hp.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

jackapplin <jackapplin@home.com> wrote in message
news:XY1q7.12557$w62.8939563@news1.denver1.co.home.com...

> > My guess is that &, &&; |,||; ^,^^ is a false symmetry.  But it's
> > one that people seem to want, and, though it's not much help,
> > adding it wouldn't do much harm.
> >
> > Dennis

Right. For completeness I would add it (for both C and C++).
It is bizarre that all the boolean operators are present but exclusive-or is
not.

Stephen Howe



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>
> The standard defines keyword "bitand" for a bitwise
> and-operation, and "bitor" for a bitwise or-operation.
>
> Why doesn't it define "bitxor" for a bitwise xor-operation?
> Instead "xor" was chosen as name for that.
[SNIP]

I see many of you "discussing" this topic with heat.  May I ask just one
question?  How many of you actually _use_ this "feature"?  I mean I
guess that a very low percentage of C++ programmers need this
alternative operator notation anyways.  Therefore I doubt that it is
worth the effort and the heat to "quarel" about its name.  So we may
have an exceptional naming, which will be learnt by those very few who
needs it in 1 day and never needed by the majority of us.  I don't see
any source of confusion or other danger in this naming.  When in doubt,
read the: standard, Stroustrup, your manual etc.  So if someone is in
doubt (can this be a logical xor, but we do not have a logical xor in
C++) he/she will pick up the book, look it up and remember it.  Case
closed?

Attila

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]