There has been some debate at work about using the merits of using the alternative spellings for C/C++ logical operators in iso646.h:

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

According to Wikipedia, these macros facilitate typing logical operators in international (non-US English?) and non-QWERTY keyboards. All of our development team is in the same office in Orlando, FL, USA and from what I have seen we all use the US English QWERTY keyboard layout; even Dvorak provides all the necessary characters.

Supporters of using the iso646.h macros claim we should them because they are part of the C and C++ standards. I think this argument is moot since digraphs and trigraphs are also part of these standards and they are not even supported by default in many compilers.

My rationale for opposing these macros in our team is that we do not need them since:

  • Everybody on our team uses the US English QWERTY keyboard layout;
  • C and C++ programming books from the US barely mention iso646.h, if at all; and
  • new developers may not be familiar with iso646.h (this is expected if they are from the US).


Finally, to my set of questions:

  • Does anyone in this site use the iso646.h logical operator macros? Why?
  • What is your opinion about using the iso646.h logical operator macros in code written and maintained on US English QWERTY keyboards?
  • Is my digraph and trigraph analogy a valid argument against using iso646.h with US English QWERTY keyboard layouts?


I missed two similar questions in StackOverflow:

  • At least on german keyboards, | and ~ (and non-round brackets, for the record) require the Alt key and nearly other symbols (depending on what you count) require the shift key. Could be an argument in favour of these, although I'm yet to see anyone using them.
    – user7043
    Commented Feb 11, 2011 at 18:24
  • 1
    I do not care; I am using Python.
    – Job
    Commented Feb 11, 2011 at 23:04
  • @Job - Python has | operators etc. It lacks an iso646 library, but once the idea gets around... BTW, why does this remind me of the people who define macros trying to turn C into Pascal or Ada or whatever?
    – user8709
    Commented Feb 12, 2011 at 0:00
  • 2
    I once used them by accident after I had done a lot of Ada coding. It confused other people, though.
    – Simon B
    Commented Jul 3, 2014 at 12:23

4 Answers 4


The one thing that I notice immediately is that and and bitand are a whole lot easier to keep straight than && and &. Same for the or pair. Using this will reduce the number of stupid, not-paying-attention bugs in your codebase.

  • 9
    I'm very sure, I'd often type and while meaning &. So this is even more error-prone. If somebody really thinks something like this could be useful, so they should provide unambiguous names like bitand and booland or whatever. Using plain and leads to as many errors as using = for assignment did.
    – maaartinus
    Commented Feb 12, 2011 at 1:16
  • 4
    Really? & and && are second nature to me. Like driving a car. No confusion whatsoever. Commented Dec 23, 2016 at 0:27

I added support for the "and", "or", etc when I started working on a C++ compiler. Not a feature that ever really gets used however, or one that had been missed by customers and users before I added it!

Personally, I like the "and" and "or" operators, because I also write code in Python. I also added that form of operator in a scripting language I designed and implemented on the grounds that it was readable (but also, it was my personal preference).


For me it's completely unusable. It's a new language to learn, where you need to think about what and really means, is it & or &&? If it was this way from the very beginning, it'd be OK, but for now I see it as a big step backwards.

Or maybe add

#define begin {
#define end }

and we can switch to Pascal. While iso646.h may alleviate problems with programming-hostile keyboards, it can hardly solve them. Changing the source code because of lacking suitable keyboard and because of not being able to define the needed keys properly is bad. The overly verbose style may make a program readable for a beginner not knowing the language properly. But for an advanced programmer it makes it harder to read, as the program turns to a long sequence of words, words, words... with operators looking the same like variables. Taken to an extreme:

a times x plus b times y plus c times z


a*x + b*y + c*z

What's better?

  • 4
    As someone who actually uses Pascal on a daily basis, I disagree. The operators only "end up looking like variables" if you're using a really primitive editor. Any modern editor can do syntax highlighting and make keywords such as and and or look distinctive so you don't confuse them with variables. Commented Feb 21, 2011 at 17:37
  • @MasonWheeler While in Pascal "and" is a keyword, it's something completely different from var or end, so "keyword highlighting" alone is of little use. Basically, it's a good thing, but there are already more than enough things to be styled (my eclipse shows maybe 30 categories). So the fewer keywords, the better.
    – maaartinus
    Commented Mar 21, 2016 at 22:28

I was using them for some time when I was compiling with g++, but at some point I went on MSVC and it wouldn't work because apparently this header is not included by default.

I'm living in France and I have a QWERTY keyboard, I admit those macros can be very useful, but they don't fix the pain from having to type "[]{}()".

My opinion is that it makes the code far more readable, especially for !, || and && operators.

  • 6
    The real problem is not that C++ is not programmer-friendly, but that European keyboards are not programming-friendly.
    – Job
    Commented Feb 11, 2011 at 23:05
  • 5
    I think you mean "not C programming-friendly" there, @Job. People using languages that aren't a rat's nest of line noise have no problems with European keyboards. Commented Feb 12, 2011 at 5:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.