Thread View: comp.std.c++
2 messages
2 total messages
Started by Beman Dawes
Thu, 01 Feb 1996 01:32
Re: and, or, not
Author: Beman Dawes
Date: Thu, 01 Feb 1996 01:32
Date: Thu, 01 Feb 1996 01:32
66 lines
3738 bytes
3738 bytes
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. ]
Re: and, or, not
Author: John Galt
Date: Mon, 05 Feb 1996 19:25
Date: Mon, 05 Feb 1996 19:25
43 lines
2732 bytes
2732 bytes
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. ]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads