Are “not, and, or, not_eq..” part of the C++ standard? (And why might they be used or avoided in code?)

Question

So it looks like all these: http://www.cplusplus.com/reference/clibrary/ciso646/ are keywords in c++.

My question is. Is this a part of the c++ standard?

Ca

Answer 1

Microsoft's complier doesn't support them. You can see the list of keywords here.

It's just a matter of style (and perhaps readability improvement as some readers insist). Personally, I don't see any advantages of using them in place of && and || etc.

Answer 2

My question is. Is this a part of the c++ standard?

Yes.

Can I rely on this to be supported by major compilers?

Yes. But MSVC doesn’t support this by default, you need to pass it the option /permissive- (or, though this is buggy and outdated, /Za), which disables Microsoft language extensions. It seems a good idea to enable this option for almost all C++ projects anyway, it’s just a shame it’s off by default.

but are there any advantages to using the keywords over the standard operators

In general, no. But in the case of and, or, not, many (though probably not most) people find it more readable. Personally I recommend using them.

If you absolutely want the code to compile on MSVC without the /permissive- flag, #include <ciso646> (which is a standard header that’s empty on complying C++ implementations, but adds macros for the operators on MSVC).

Answer 3

They are in the standards, but support is somewhat uneven. Experienced programmers find them less readable than the usual symbols (||, &&, !=, etc.) so unless you just want to make a political statement about the vendors of the compilers that don't support them, they're best avoided.

At least in my opinion, they're also poorly defined. In particular, they're defined in terms of tokens, not logic. They real reason alternative tokens in general (trigraphs, digraphs, and these things) were invented was to allow use of the language on ancient terminals that didn't support the special characters used by the language. These were added to be marginally less annoying that trigraphs and digraphs. I guess they succeed in that respect, but they're still only marginally less annoying, not anything that should be used by choice.

Let's consider a few examples. If you honestly are on one of those ancient terminals, and you want to write code code that passes a parameter by reference, how do you do it?

void foo(T bitand param);

From that, it should be obvious how you'd pass a value by rvalue reference:

void foo(T and param);

Stupid and ugly, but I guess at least it settles the age-old argument about T& param vs T &param--with bitand you need to leave spaces on both sides. In return for that, it's misleading, confusing and unreadable.

Oh, and be careful not to spell it as bit_and rather than bitand. There is also something named bit_and, but it's entirely different--bitand is a preprocessor token, whereas bit_and is a function template defined in <functional>. Using the wrong one can lead to some rather confusing compiler errors.

That said, I can think of one situation in which and, bitand, etc., are probably justified. If (for whatever reason) you can't type in your code, and have to use dictation software instead, it's probably a whole lot easier to get dictation software to enter and than &&. It's might be more difficult to get it to distinguish between bitand and bit_and, but the latter is rarely enough used that it's probably not much of an issue.

Summary

For a few people, entering code using the accepted symbols really is difficult enough that it's reasonable for them to use word-based tokens instead.

For anybody else, even if they personally find and more readable than &&, inflicting such code on others would be about like if I decided to name an addition function biggerate, because I thought that was a cute name for addition when I was five years old. So, if you like them and you're writing code that you're absolutely, positively certain that nobody else will ever read, sure go ahead and have a blast. Otherwise, using them is a poor idea.

Answer 4

Is this a part of the c++ standard?

Yes. See the table in section [lex.digraph].

Are there any advantages to using the keywords over the standard operators?

My understanding is that the original digraphs (<% instead of {, etc.) were introduced to allow people with simple keyboards to be able to write C code (Wikipedia corroborates this). Perhaps the same rationale applies for not_eq, etc. But AFAIK, there is no good reason to write such stuff nowadays (unless you're coding on your smartphone), not least because 99% of programmers don't know it's valid C++!

Answer 5

Yes, they are supported.

In terms of the second half of your question they can lead to more readable code especially when dealing with bitwise operators as well as logical operations at the same time for example:

if( a & 1 == 0 || c | a == 2 );

vs

if( a & 1 == 0 or c | a == 2 );