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

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 ¶m--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 . 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.