"James Russell Kuyper Jr." wrote:
>=20
> Daniel Frey wrote:
> >
> > Michael Andres wrote:
> > >
> > > Matthew Austern <austern@research.att.com> wrote in message news:<d=
ilsndl921g.fsf@isolde.research.att.com>...
> > > > The standard had to use "bitand" and "bitor" (for & and | respect=
ively),
> > > > because "and" and "or" were already taken (by && and ||).  No suc=
h
> > > > consideration applied to "xor", because there is no "^^" operator=
.  So
> > > > we may as well use the simple name, "xor", for the only xor opera=
tion
> > > > 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 mor=
e
> > > consistent naming scheme.
> >
> > How about
> >
> > #define bitxor ^
> > #define xor !=3D
>=20
> That won't work. 'xor' get parsed during preprocessing as

Oops... thanks... so the OP could go for eor instead of xor? Even
better, this won't conflict with reserved keywords:

#define biteor ^
#define eor !=3D

Michael: Does this help? Now you just need to remember not to use xor
instead of eor :)

> #define bitnot_eq ^

Depends on what you consider 'intuitive'. I couldn't remember such a
name, but this is a matter of taste (and probably of your native
language)

Finally, a general question and suggestion for C++0x: For plateforms
that don't support some characters like '^', wouldn't it make sense to
allow source code to be written like strings? I mean:

#define my_bit_xor \136

Although the source will look ugly, you can write a program with just
the backslash and the number 0-9. That way, the language itself is
clean, minimalistic and doesn't waste keywords on platform specific
topics. Any platform that misses some characters could add
platform-standardized #define's to add new keywords. These could be
supplied by the compiler of that platform and they may start with __ (if
underline is available on that platform :) to prevent conflicts with
other code.

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 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                ]

Daniel Frey wrote:
>
> "James Russell Kuyper Jr." wrote:
...
...
> > #define bitnot_eq ^
>
> Depends on what you consider 'intuitive'. I couldn't remember such a
> name, but this is a matter of taste (and probably of your native
> language)

This suggestion is NOT to my taste; I'm quite happy with "^" or "xor".
I'm just trying to suggest a way of satisfying the OP's preference for
symmetry with the alternative tokens for the other bitwise operators.

"not_eq" is not something I chose randomly; it is defined by the
standard as the alternative token equivalent to !=, which bears (for
boolean values) the same relationship to ^ that || bears to |, or &&
bears to &. If, as the OP apparantly desired, all bitwise operators that
have such equivalents should have a 'bit' prefix, then bitnot_eq/not_eq
is preferable to bitxor/xor, because it does not rule out continuing to
use xor in the fashion defined by the standard.

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