[Cross-posted to comp.std.c]

I just noticed another incompatibility between the upcoming C and C++
draft standards.

The C draft (C9X) defines the following identifiers as macros that can be
used in implementations that don't have full source character sets (such as
those lacking the tilde character, for example), provided that the standard
<iso646.h> header is included (see 7.17 and D.19 in the draft):

    and     &&  //(amper amper) *
    and_eq  &=  //(amper equal)
    bitand  &   //(amper)       *
    bitor   |   //(bar)         *
    compl   ~   //(tilde)       *
    not     !   //(bang)        *
    not_eq  !=  //(bang equal)  *
    or      ||  //(bar bar)     *
    or_eq   |=  //(bar equal)
    xor     ^   //(caret)       *
    xor_eq  ^=  //(caret equal)

C++, on the other hand, defines these as reserved words, such that
inclusion of a header file is not necessary to use them.  It is explicitly
stated, in fact, that these tokens are not macros found in the <ciso646>
header (see C.4.2.2 of the draft).

This creates a difference between the two languages in the use of the
tokens marked with a '*' in the preprocessor.  The following directives
are specific examples that will work in C (assuming that <iso646.h> has
been included) but won't work in C++:

    #if not defined(SYMBOL)
    #if BUFSIZ >= 512 and BLKSZ >= 512

One possible way out of this is to note that many C++ compilers can
translate both C++ and C source programs, so presumably such compilers
would supply an <iso646.h> header.  Thus, C++ programs could #include this
header in order to get the same preprocessor behavior (although such
programs would not be strictly conforming C++).

Another solution is to define these tokens as operators recognized by the
C++ preprocessor.

While C++ programs typically don't make as much use of the preprocessor
as C programs, we expect the same expressive power in both flavors of
the preprocessor.  The iso646 tokens are supplied to make life simpler for
programmers with limited character sets.  It makes sense, then, to give
the C++ preprocessor the same expressive power as the C++ language itself
has, meaning that it makes sense to allow the use of the 'and', 'or',
'not', etc. tokens in preprocessor expressions as a convenience to those
programmers who need to use those tokens.  At the very least, it makes
sense to allow the C++ preprocessor to have as much expressiveness as the
C preprocessor.

--------------------.     +1-972-738-6125 Work  ,-.   C++ : the PL/1 of
David R. Tribble     \   ,---------------------'   \  the 90s
http://www.beasys.com `-' +1-972-738-6111 Fax       `-------------------
david.tribble@noSPAM.beasys.com           http://www.flash.net/~dtribble
Support the anti-Spam amendment, join at http://www.cauce.org/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David R Tribble writes:

> The C draft (C9X) defines the following identifiers as macros that can be
> used in implementations that don't have full source character sets

[alternate representations of boolean and bitwise operations]

> C++, on the other hand, defines these as reserved words

Which doesn't make a different at all, except that, in C++, one can't
expect

#ifdef and
  this is a parse error
#endif

to produce a parse error (it should produce a preprocessor error,
instead)

And this shouldn't be a problem if one wants to write standard
include-files.  iso646.h would contain:

#ifndef __cplusplus
#define and &&
#define or ||
etc
#endif

> This creates a difference between the two languages in the use of the
> tokens marked with a '*' in the preprocessor.

Is there any reason to suppose the C++ preprocessor wouldn't recognize
the alternate representations in the following example: ?

>     #if not defined(SYMBOL)
>     #if BUFSIZ >= 512 and BLKSZ >= 512

> Another solution is to define these tokens as operators recognized by the
> C++ preprocessor.

AFAIK, this is exactly what the C++ Standard requires.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[cross-posted to comp.std.c]

David R Tribble wrote:
> I just noticed another incompatibility between the upcoming C and C++
> draft standards.

I appears I may have spoken too soon.

> The C draft (C9X) defines the following identifiers as macros that can
> be used in implementations that don't have full source character sets
> (such as those lacking the tilde character, for example), provided that
> the standard <iso646.h> header is included (see 7.17 and D.19 in the
> draft):
>
>     and     &&  //(amper amper) *
>     and_eq  &=  //(amper equal)
>     bitand  &   //(amper)       *
>     bitor   |   //(bar)         *
>     compl   ~   //(tilde)       *
>     not     !   //(bang)        *
>     not_eq  !=  //(bang equal)  *
>     or      ||  //(bar bar)     *
>     or_eq   |=  //(bar equal)
>     xor     ^   //(caret)       *
>     xor_eq  ^=  //(caret equal)
>
> C++, on the other hand, defines these as reserved words, such that
> inclusion of a header file is not necessary to use them.  It is
> explicitly stated, in fact, that these tokens are not macros found in
> the <ciso646> header (see C.4.2.2 of the draft).
>
> This creates a difference between the two languages in the use of the
> tokens marked with a '*' in the preprocessor.

Apparently not.  Upon closer examination of sections 2.4 and 2.5 of
the C++ draft, I see that these tokens are indeed recognized by the
preprocessor.

Sorry for the noise.

--------------------.     +1-972-738-6125 Work  ,-.   C++ : the PL/1 of
David R. Tribble     \   ,---------------------'   \  the 90s
http://www.beasys.com `-' +1-972-738-6111 Fax       `-------------------
david.tribble@noSPAM.beasys.com           http://www.flash.net/~dtribble
Support the anti-Spam amendment, join at http://www.cauce.org/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]