Topic: and, or, not
Author: jgalt@infosoft.com (John Galt)
Date: 1996/02/05 Raw View
In article <1198@dawes.win.net>, Beman Dawes <beman@dawes.win.net> wrote:
> 2.9 Keywords [lex.key]
[snip]
> Table 4--alternative representations
> +------------------------------------------------+
> |and and_eq bitand bitor compl not |
> |not_eq or or_eq xor xor_eq |
> +------------------------------------------------+
This leads to another question:
Assuming that the problem characters (those that don't exist on some keyboards,
making the above names necessary) are &, |, !, ^, and ~,I wonder why they
didn't create names for all the affected characters. I would have done
something like this:
&& and &&= and_eq [a] & bitand &= bitand_eq
|| or ||= or_eq [a] | bitor |= bitor_eq
! not != unequal [b] ~ compl ~= compl_eq
^ bitxor [c] ^= bitxor_eq [c]
[a] In the draft, these names are not as shown here, but are given to the
operator at the end of the same row! This inconsistency will confuse
users and should be changed now, before someone implements it.
[b] Should not be called not_eq because it is not an assignment like the
other ones ending in "_eq".
[c] Should begin with "bit" like the other bit operators. If there were
logical-xor operators ^^ and ^^=, _those_ should be called xor and
xor_eq. Those ought to exist. Also, there ought to be shift-in-place
operators, <<= and >>=.
--
John David Galt I do not speak for my employer.
jgalt@infosoft.com Send personal mail to: John_David_Galt@cup.portal.com
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy is
in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
Author: clamage@eng.sun.com (Steve Clamage)
Date: 1996/02/06 Raw View
In article H7z@infosoft.com, jgalt@infosoft.com (John Galt) writes:
>In article <1198@dawes.win.net>, Beman Dawes <beman@dawes.win.net> wrote:
>> 2.9 Keywords [lex.key]
>[snip]
>> Table 4--alternative representations
>
>> +------------------------------------------------+
>> |and and_eq bitand bitor compl not |
>> |not_eq or or_eq xor xor_eq |
>> +------------------------------------------------+
>This leads to another question:
>Assuming that the problem characters (those that don't exist on some
>keyboards, making the above names necessary) are &, |, !, ^, and ~, I
>wonder why they didn't create names for all the affected characters.
>I would have done something like this: ...
As I said in an earlier article, the C++ Committee didn't invent the
alternative representations, and didn't even particularly like some
of them. They were previously adopted as part of another ISO standard.
It seemed much better to comply with an existing standard than to
create an incompatibility.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Author: Rod Burman <rodb@bridge.com>
Date: 1996/02/07 Raw View
In article H7z@infosoft.com, jgalt@infosoft.com (John Galt) writes:
>In article <1198@dawes.win.net>, Beman Dawes <beman@dawes.win.net> wrote:
>> 2.9 Keywords [lex.key]
>[snip]
> >> Table 4--alternative representations
> >
> >> +------------------------------------------------+
> >> |and and_eq bitand bitor compl not |
> >> |not_eq or or_eq xor xor_eq |
> >> +------------------------------------------------+
> YET
> >This leads to ^ another question:
Is the committee thinking of some how linking these with operator
overloading?
e.g. operator^() == operator.xor() xor operator_xor()
or do you just use trigraphs for this particular usage?
Just a thought
Rod B
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy is
in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1996/02/08 Raw View
In article <3118FDEF.458E@bridge.com> Rod Burman <rodb@bridge.com> writes:
> Is the committee thinking of some how linking these with operator
> overloading?
> e.g. operator^() == operator.xor() xor operator_xor()
In operator^, the word `operator' and the symbol `^' are separate
tokens. So it suffices to write
operator xor()
--
--Andrew Koenig
ark@research.att.com
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy is
in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
Author: horstman@jupiter.SJSU.EDU (Cay S. Horstmann)
Date: 1996/01/30 Raw View
I just got a press release from Borland that says their upcoming 5.0
compiler will support keywords and, or, not, that are synonyms to &&,
|| and !.
They say you can use those if your local keyboard makes it difficult
to write the traditional tokens. Hell, my local eyes make it difficult
to read them. Does that mean I can from now on just write
if (0 <= x and x <= 1) . . .
and be in conformance with ANSI C++?
That is, are "and", "or", "not", now reserved words in ALL C++
programs, or do you actually have to reside in a foreign country and
first use some preprocessor (like that trigraph filter) to get them?
If the answer is "they are reserved words in the language", then I'll
add
#define and &&
#define or ||
#define not !
into my personal setup file today, until my compiler understands them
natively. Hooray!
Cay
horstman@cs.sjsu.edu
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Author: beman@dawes.win.net (Beman Dawes)
Date: 1996/02/01 Raw View
In article <4ej3t4$7nb@jupiter.SJSU.EDU>, Cay S. Horstmann
(horstman@jupiter.SJSU.EDU) writes:
>I just got a press release from Borland that says their upcoming 5.0
>compiler will support keywords and, or, not, that are synonyms to &&,
>|| and !.
>
>They say you can use those if your local keyboard makes it difficult
>to write the traditional tokens. Hell, my local eyes make it difficult
>to read them. Does that mean I can from now on just write
> if (0 <= x and x <= 1) . . .
>and be in conformance with ANSI C++?
>
>That is, are "and", "or", "not", now reserved words in ALL C++
>programs, or do you actually have to reside in a foreign country and
>first use some preprocessor (like that trigraph filter) to get them?
>
>If the answer is "they are reserved words in the language", then I'll
>add
> #define and &&
> #define or ||
> #define not !
>into my personal setup file today, until my compiler understands them
>natively. Hooray!
Funny you should ask. I just looked it up this morning:
2.9 Keywords [lex.key]
1 The identifiers shown in Table 3 are reserved for use as keywords, and
shall not be used otherwise in phases 7 and 8:
Table 3--keywords
+--------------------------------------------------------------------------+
|asm do inline short typeid |
|auto double int signed typename |
|bool dynamic_cast long sizeof union |
|break else mutable static unsigned |
|case enum namespace static_cast using |
|catch explicit new struct virtual |
|char extern operator switch void |
|class false private template volatile |
|const float protected this wchar_t |
|const_cast for public throw while |
|continue friend register true |
|default goto reinterpret_cast try |
|delete if return typedef |
+--------------------------------------------------------------------------+
2 Furthermore, the alternative representations shown in Table 4 for cer-
tain operators and punctuators (_lex.digraph_) are reserved and shall
not be used otherwise:
Table 4--alternative representations
+------------------------------------------------+
|and and_eq bitand bitor compl not |
|not_eq or or_eq xor xor_eq |
+------------------------------------------------+
--Beman
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]