7

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?

Can I rely on this to be supported by major compilers? I know gcc does support these keywords.

Finally, perhaps this is more a preference or style question, but are there any advantages to using the keywords over the standard operators (!, !=, && ... etc)?

user2864740
  • 60,010
  • 15
  • 145
  • 220
anio
  • 8,903
  • 7
  • 35
  • 53

5 Answers5

11

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

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
  • In gcc, are the keywords just macros that expand to the operators? – anio Jul 20 '12 at 16:05
  • @anio They are not macros, they are preprocessor preprocessing tokens. – Konrad Rudolph Jul 20 '12 at 16:07
  • 4
    More readable for who? Most experienced C-family coders will do a double-take at code containing these operators instead of `&&`, `||` and `!`, which they are extremely used to seeing. I would argue they are *less* readable for coders, and coders are who you should be targeting when you think of writing "readable" code. – user229044 Jul 20 '12 at 16:07
  • 3
    @meagar Most languages use keywords for logical expressions, either exclusively or as an allowed alternative. C# and Java are the only ones which don’t allow this, off the top of my head (but I’d wager there are more). C programmers may not be used to it but the same argument is justified to ban other good features, and it doesn’t hold any sway with me. `not x` in particular is more readable than `! x` because it makes the operator more visible and less likely to be overlooked. And I think `a and b` makes it nicely clear that we’re dealing with logical conditions, as opposed to (say) numbers. – Konrad Rudolph Jul 20 '12 at 16:09
  • 2
    I'm not arguing for other features, I'm arguing that for an experience programmer `&&` should be more readable than `and`. It's what someone experienced with C-style languages expects to see gluing together two variables in an `if` statement. – user229044 Jul 20 '12 at 16:21
  • Well, I’d describe myself as an experienced programmer, and most of recent programming I’ve done was in C++, and I definitely find `and` more readable than `&&`. On a related note, it annoys the heck out of me that Perl, PHP and Ruby assign different priorities to these operators (but I understand the reason). – Konrad Rudolph Jul 20 '12 at 16:23
  • readability depends on the context. Especially the ! often bears the danger of being overlooked. Just consider `return !someThing.isValid();` vs `return not someThing.isValid();` – Ichthyo Sep 25 '15 at 02:15
7

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

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
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 );
sean
  • 3,955
  • 21
  • 28
  • 1
    I disagree about bitwise operators. `bit_and` isn’t more readable than `&`, in the same way that `a plus b` isn’t as readable as `a + b`. I *do* agree that it makes logical expressions more readable. – Konrad Rudolph Jul 20 '12 at 16:05
  • 1
    Oh, I didn't make it clear I ment when there are logical operations mixed with bitwise. – sean Jul 20 '12 at 16:05
  • I wouldn't mix-and-match for the sake of readability. Stick to one type of operator and the maintainers of your code won't have to do a mental context switch every time your operators change. – user229044 Jul 20 '12 at 16:08
  • 1
    @meagar What mental context switch?! Mixing the operators is a *good* thing. Other languages don’t seem to consider that there’s a harmful context switch happening. – Konrad Rudolph Jul 20 '12 at 16:10
  • 1
    @Konrad Perhaps a bias has crept into my thinking as I've been working for the past year primarily in Ruby where `and` and `&&` are *not* the same thing. However, I would still find it easier to read a line of code where operators stand out as punctuation and variables stand out as words, and I would find it extremely distracting for a single line to mix-and-match ubiquitous `&&`-style operators and less-often used `and`-style operators. – user229044 Jul 20 '12 at 16:17
4

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.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
-2

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.

Jaywalker
  • 3,079
  • 3
  • 28
  • 44
  • I can see how one could mix up & and &&, so bitand looks useful to me. – anio Jul 20 '12 at 16:13
  • @anio I need to harp on about this, *don’t* use `bitand` instead of `&`. If anything, do it the other way round and replace the logical operators, not the bitwise ones. – See [my other comment](http://stackoverflow.com/q/11582955/1968#comment15326033_11582990) on the reason why. – Konrad Rudolph Jul 20 '12 at 16:19