When Were the 'And' and 'Or' Alternative Tokens Introduced in C++

When were the 'and' and 'or' alternative tokens introduced in C++?

MSVC supports them as keywords only if you use the /Za option to disable extensions; this is true from at least VC7.1 (VS2003).

You can get them supported as macros by including iso646.h.

My guess is they believe that making them keywords by default would break too much existing code (and I wouldn't be surprised if they are right).

When did and become an operator in C++

There are several such alternatives defined in C++. You can probably use switches to turn these on/off.

Why are there alternative tokens in C++?

They're a hangover from C, really. There were implementations of C in which not all characters were available (such as some variants of EBCDIC that have no square brackets).

The C99 rationale document, section 5.2.1.1 Trigraph sequences has this to say:

Trigraph sequences were introduced in C89 as alternate spellings of some characters to allow the implementation of C in character sets which do not provide a sufficient number of non-alphabetic graphics.

The characters in the ASCII repertoire used by C and absent from the ISO/IEC 646 invariant repertoire are #, [, ], {, }, \, |, ~, and ^

The written versions of the logical operators

They originated in C in the header <iso646.h>. At the time there were keyboards that couldn't type the required symbols for && (for example), so the header contained #define's that would assist them in doing so, by (in our example) defining and to be &&. Of course, as time went by this became less used.

In C++, they became what are known as alternate tokens. You do not need to include anything to use these tokens in a compliant compiler (as such, the C++-ified version of the C header, <ciso646>, is blank). Alternate tokens are just like regular tokens, except for spelling. So during parsing and is exactly the same as &&, it's just a different way of spelling the same thing.

As for their use: because they are rarely used, using them is often more surprising and confusing than it is helpful. I'm sure if it were normal, they would be much easier to read, but people are so used to && and || anything else just gets distracting.

EDIT: I have seen a very slight increase in their usage since I posted this, however. I still avoid them.

What is the difference between and and && in c++

The C++ standard permits the token && to be used interchangeably with the token and.

Not all compilers implement this correctly (some don't bother at all; others require the inclusion of a special header). As such, code using and can be considered idiosyncratic.

The fact that the equivalence is at the token, rather than the operator, level means that since C++11 (where the language acquired the rvalue reference notation), you can arrange things (without recourse to the preprocessor) such that the statement

int and _int(string and vector);

is a valid function prototype. (It's eqivalent to int&& _int(string&& vector).)

Should I use && or and?

2.6 Alternative tokens [lex.digraph]

1 Alternative token representations are provided for
some operators and punctuators.16

2 In all respects of the language, each alternative token behaves the
same, respectively, as its primary token
, except for its spelling.17
The set of alternative tokens is defined in Table 2.

Can't paste table 2, but it explicitly states Alternative: and, Primary && (same for or and ||).

So they are absolutely identical.
If you want to try and convince yourself one is "better" than the other, that's your business. If someone else is trying to argue such, they'd better have a good reason.

Edit: The aforementioned Table 2:

Table 2 — Alternative tokens
Alternative Primary
<% {
%> }
<: [
:> ]
%: #
%:%: ##
and &&
bitor |
or ||
xor ˆ
compl ~
bitand &
and_eq &=
or_eq |=
xor_eq ˆ=
not !
not_eq !=

Edit: Maybe worth noting, according to Sebastian Redl, MS break the rules here.

Why do these alternative operator representations exist

As tomislav-maric points out in a comment, the reason is exactly
that given on the page you cite: some older widespread encodings
didn't contain the characters which are replaced. This is
probably not very relevant today, since those encodings have
pretty much disappeared, being replaced by some of the ISO 8859
encodings or UTF-8. I don't think you can use this as an
argument for your manager.

On the other hand, at least some C++ experts prefer and, or
and not to &&, || and !. I'm not one of them, but there
are arguments either way. My feeling is simply that it's C/C++,
and lots of strange character sequences rule. (If I were
designing a language from scratch, however...)

With regards to the trigraphs lower down on the page: that can
be considered an experiment that didn't really work. As far as
I know, no one ever really used them; the resulting code would
be just as unreadable as if the replacement characters were
used. Consider the alternatives if you were using the German
ISO 646:

int arrayÄ 10 Ü;      //  native
int array??( 10 ??); // tri-graphs
int array<: 10 :>; // digraph

Only the last is even slightly readable, but by the time the
last was specified, the problem had pretty much disappeared.

EDIT:

One additional point. Regardless of personal preferences, you
should make the decision and/or/not vs. &&/||/! at
a team level, and everyone in the team should use the same
conventions.

EDIT:

FWIW: trigraphs were first introduced in C90 (K&R C didn't have
them); digraphs and alternate tokens in C++98 and C99. (I'm not
sure offhand whether the earlier versions of CFront supported
them or not.)

What is the significance of the <: syntax in C?

Its call alternative tokens. C++ have several of them:

 <%     {
%> }
<: [
:> ]
%: #
%:%: ##
and &&
bitor |
or ||
xor ˆ
compl ~
bitand &
and_eq &=
or_eq |=
xor_eq ˆ=
not !
not_eq !=

You can seen some of the alternative token consists of letters. So you can write if (a<b and b<c) in a compiler which can correctly handle them. Their existence is for lack of symbols in keyboards or character sets. The alternative tokens are never replaced with the primary one (unlike trigraphs), but them behave the same as the primary one.

However, C++0x require special treatment for <:: (2.5p3):

Otherwise, if the next three characters are <:: and the subsequent
character is neither : nor >, the < is treated as a preprocessor token
by itself and not as the first character of the alternative token <:.

So that SomeTemplate<::SomeClass> can be correctly handled.

Is it okay to use and, or etc. instead of &&, ||?

They are in fact standard in C++, as defined by the ISO 14882:2003 C++ standard 2.5/2 (and, indeed, as defined by the 1998 edition of the standard). Note that they are built into the language itself and don't require that you include a header file of some sort.

However, they are very rarely used, and I have yet to see production code that actually uses the alternative tokens. The only reason why the alternative tokens exist in the first place is because these characters on some keyboards (especially non-QWERTY ones) were either nonexistent or clumsy to type. It's still in the standard for backwards compatibility.

Even though they are standard, I highly recommend that you don't use them. The alternative tokens require more characters to type, and the QWERTY keyboard layout already has all the characters needed to type out C++ code without having to use the alternative tokens. Also, they would most likely bewilder readers of your code.

2.5/2 Alternative tokens

In all respects of the language, each
alternative token behaves the same,
respectively, as its primary token,
except for its spelling. The set of
alternative tokens is defined in Table
2.

Table 2 - alternative tokens
+--------------+-----------+
| Alternative | Primary |
+--------------+-----------+
| <% | { |
| %> | } |
| <: | [ |
| :> | ] |
| %: | # |
| %:%: | ## |
| and | && |
| bitor | | |
| or | || |
| xor | ^ |
| compl | ~ |
| bitand | & |
| and_eq | &= |
| or_eq | |= |
| xor_eq | ^= |
| not | ! |
| not_eq | != |
+--------------+-----------+

&& and and operator in C

Check out the page here iso646.h

This header defines 11 macro's that are the text equivalents of some common operators.
and is one of the defines.

Note that I can only test this for a C++ compiler so I'm not certain if you can use this with a strict C compiler.

EDIT I've just tested it with a C compiler here and it does work.



Related Topics



Leave a reply



Submit