Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why do these alternative operator representations exist

Tags:

c++

Consider these alternative operator representations: (taken from here)

Primary Alternative
&&      and
&=      and_eq
&       bitand
|       bitor
~       compl
!       not
!=      not_eq
||      or
|=      or_eq
^       xor
^=      xor_eq

Why do these alternative operator representations exist? I like them but I am trying to find reasons to give to my manager to allow me to use them.

like image 601
gda2004 Avatar asked Feb 14 '14 11:02

gda2004


People also ask

What can we use instead of in C++?

A few such alternative programming languages and platforms used these days, instead of the C++ programming language, are Java programming, Python programming, Ruby, C# that is a variation of .


2 Answers

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.)

like image 102
James Kanze Avatar answered Dec 08 '22 07:12

James Kanze


The C Committee explained why C introduced these alternative operators in iso646.h in C99 Rationale, I think it can be used for C++ as well, since C++ inherit them from C.

In short, digraphs and trigraphs are introduced in C to solve the problem of using C in the old EBCDIC machines (which support ASCII only partly, so some missing ASCII tokens need to be represented in EBCDIC characters). While the alternative operators are used to keep the use of digraphs and trigraphs to a minimum.

Rationale for International Standard — Programming Languages — C §MSE.4 Support for invariant ISO/IEC 646

The added digraphs were intentionally kept to a minimum. Wherever possible, the Committee instead provided alternate spellings for operators in the form of macros defined in the new header <iso646.h>. Alternate spellings are provided for the preprocessing operators # and ## because they cannot be replaced by macro names. Digraphs are also provided for the punctuators [, ], {, and } because macro names proved to be a less readable alternative. The Committee recognizes that the solution offered in this header is incomplete and involves a mixture of approaches, but nevertheless believes that it can help make Standard C programs more readable.

For example, the character | is not in the old machine, so the trigraph ??! is used to represent it, but this would make code hard to read is much || is used. C solved the problem by letting the alternative operator or to be used representing ||.

like image 42
Yu Hao Avatar answered Dec 08 '22 09:12

Yu Hao