CODEWITHSUNDEEP
c++operatorsstandards
rhino
rhino

Reputation: 13901

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

I'm used to the and and or keywords in C++. I've always used them and typing them is fast and comfortable for me. Once I've heard that these aliases are non-standard and may not work on all compilers. But I'm not sure of it, I don't really know if it's true.
Let's assume that I give someone my code, will he have problems compiling it?
Is it all right when I use and, or instead of &&, ||? Or are these keywords really non-standard?
P.S.I use the MinGW compiler.

Upvotes: 41

Views: 14387

Answers (10)

Zxrudi
Zxrudi

Reputation: 1

You can also use '*' instead of && and '+' instead of ||

Upvotes: 0

StoryTeller - Unslander Monica
StoryTeller - Unslander Monica

Reputation: 170203

It's syntactically valid, given those are required alternative tokens.

In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling.

However, some tokens are used for more than just logical or bitwise operators. So one can see the idiosyncratic:

auto& foo(auto and T) { // C++20 forwarding reference
    return T;
}

Or even

auto& foo(auto bitand T) { // lvalue reference
    return T;
}

That's gonna make one scratch their head for a while.

Upvotes: 3

Mark
Mark

Reputation: 11

Obviously in regards to backward compatability the "and/or" keywords are not the issue. I would believe them to be the newer standard. It is just old programmers not understanding that some noob might have to be able to read the code and not want to look up what && means. Then again if any IT department is worth it's salt it will make the programmers conform to the standards of the company! That is my belief so (and/or) are futuristic and real possible standard going towards the future. && is backward compatable not(pun) (and/or).

Upvotes: 1

Larswad
Larswad

Reputation: 41

I have always messed up ^ (xor) and the ~ (two complement) operators. With the alternative tokens (that I believe should be primary ones) there is no question about what they do, yes, I agree with former posters that the textual ones are much more descriptive.

There is another possible messup using the digraphs, it is possible to forget one of the characters in ||, && that will cause subtle bugs and strange behaviours. With the textual operators, it is much harder to make such a mistake.

I believe what I mentioned above are real valid arguments to improve code safety and clarity. Most C++ programmers SHOULD in my opinion try to get used to the textual operators in favor of the old cryptic ones.

I am surprised that so few programmers know about them. These operators should have taken over long time ago as I see it.

Upvotes: 4

In silico
In silico

Reputation: 52197

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    |    !=     |
+--------------+-----------+

Upvotes: 47

Jonathan Leffler
Jonathan Leffler

Reputation: 754700

Section 2.5 of the ISO/IEC 14882:1998 standard (the original C++ standard) says:

§2.5 Alternative tokens [lex.digraph]

1 Alternative token representations are provided for some operators and punctuators16).

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

16) These include “digraphs” and additional reserved words. The term “digraph” (token consisting of two characters) is not perfectly descriptive, since one of the alternative preprocessing tokens is %:%: and of course several primary tokens contain two characters. Nonetheless, those alternative tokens that aren’t lexical keywords are colloquially known as “digraphs”.

17) Thus the “stringized” values (16.3.2) of [ and <: will be different, maintaining the source spelling, but the tokens can otherwise be freely interchanged.

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

There is no discussion of 'if you include some header' (though in C, you need #include <iso646.h>). Any implementation that does not support the keywords or digraphs is not compliant with the 1998 edition, let alone later editions, of the C++ standard.

Upvotes: 1

amax
amax

Reputation: 33

Wow, i've been using and looking at many C++ code examples for years.. and never, until now, knew about these so I guess that means most people don't use them. So, for the sake of consistency (if you plan on working in group projects etc) it's probably best to make a habit of using && and ||.

Upvotes: 2

Cheers and hth. - Alf
Cheers and hth. - Alf

Reputation: 145419

they're standard C++, but with older compilers and possibly also with MSVC 10.0 (i haven't checked) you may have to include a special header, [isosomethingsomething.h]

cheers & hth.,

Upvotes: 4

Edward Strange
Edward Strange

Reputation: 40887

These keywords ARE standard and are described in section 2.5 of the standard. Table 2 is a table of these "alternative tokens". You can use them all you want, even though everyone will hate you if you do.

Upvotes: 9

fmt
fmt

Reputation: 993

They are standard in the new c++0x standard. Up-to-date modern compilers should recognise them, although I don't believe they are obliged to yet. Whatever floats your boat, I assume.

Upvotes: 5

Related Questions