Is anybody using the named boolean operators?

Question

Or are we all sticking to our taught "&&, ||, !" way?

Any thoughts in why we should use one or the other?

I'm just wondering because several answers state thate code should be as natural as possible, but I haven't seen a lot of code with "and, or, not" while this is more natural.

Polytypic

And to expand the question slightly, is anyone using digraphs? – Mysterious

I didn't even know that they existed. I have tried them now and they don't compile. – Arlettaarlette

You probably need to search for an option in your compiler to turn it on. – Demarche

I also had to look them up, to remind me what they are. – Polytypic

you may need to #include <ciso646> to use them – Hedberg

@markh44: Yes, thank you, that made it. I see that this header is just defining some macros. Are these constructs part of the standard C++ language? – Arlettaarlette

Never mind, I already found this answer https://mcmap.net/q/189731/-when-were-the-39-and-39-and-39-or-39-alternative-tokens-introduced-in-c/… – Arlettaarlette

I asked a related #1069852 recently on how to control whether or not they supported by the compiler. Turns out its enabled by default in GCC and not so much in MSVC. – Wilscam

Thanks for the related questions. They helped. I didn't find them while checking whether this question was already asked. – Polytypic

I urge you to write struct X { compl X() { } }; instead of using the ~ token. – Seedy

@litb: nice one :-), although compl wouldn't mean destructor, while "and, or, not" mean exactly that and be honest, if you didn't know C, what would "||" mean? – Polytypic

Answer 1

Those were not supported in the old days. And even now you need to give a special switch to some compilers to enable these keywords. That's probably because old code base may have had some functions || variables named "and" "or" "not".

Demarche

Funny, I just got burned by this... I was compiling some old C++ code that was clearly written before the named boolean operators were supported (John Lakos, I'm looking at you) and there were variables & routines name "or"... fast forward to today, compiler barfs, code needs to change... – Lorindalorine

Answer 2

I like the idea of the not operator because it is more visible than the ! operator. For example:

if (!foo.bar()) { ... }

if (not foo.bar()) { ... }

I suggest that the second one is more visible and readable. I don't think the same argument necessarily applies to the and and or forms, though.

Diverse

Yes, I agree with with this. I go even further and create a Not() function, because not only do I have trouble seeing the critter, I also have problems remembering its precedence! – Mysterious

Function is a little bit overkill. Use parentheses instead! – Demarche

Valid point. Although syntax hightlighting comes to the rescue, we do not have to rely on that. – Zetland

I use == false instead of !, as its not visable enough for me. – Radio

If you don't find !foo.bar() visible enough you could also write !!!!!foo.bar(). Since 5 is an odd number, it is equivalent to !foo.bar(). – Arlettaarlette

yeah, that's the only one I'm a bit queasy with. – Inchoation

@Daniel, you must be joking. I wouldn't start counting the amount of "!"'es in that. I would just go to my fellow and ask him to remove that. – Seedy

I use if ((not true == foo.bar) == false). – Viglione

Ahhhh, "boolean fundamentalists".... @phresnel can joke about it, but I've seen stuff not too far from that. – Blanche

Answer 3

"What's in a name? That which we call &&, || or ! By any other name would smell as sweet."

In other words, natural depends on what you are used to.

Zetland

I agree & what's more I'm ! convinced that the average programmer will code faster using and | not. – Higher

And those of us who have used && and || for twenty years or so will be slow to change from it. – Stet

And those of us who have used || and && for 30 years or so, but who also code a lot in python, will be bound to one day write if( x<3 and y<7) without even thinking about it, and then be surprised when a co-worker compiling it with MSVC commits a 'fix' to change it to &&. This is how I found out that and was even possible... – Blanche

Answer 4

One problem with using them (for me anyway) is that in MSVC you have to include iso646.h or use the (mostly unusable) /Za switch.

The main problem I have with them is the Catch-22 that they're not commonly used, so they require my brain to actively process the meaning, where the old-fashioned operators are more or less ingrained (kind of like the difference between reading a learned language vs. your native language).

Though I'm sure I'd overcome that issue if their use became more universal. If that happened, then I'd have the problem that some boolean operators have keywords while others don't, so if alternate keywords were used, you might see expressions like:

if ((x not_eq y) and (y == z) or (z <= something)) {...}

when it seems to me they should have alternate tokens for all the (at least comparison) operators:

if ((x not_eq y) and (y eq z) or (z lt_eq something)) {...}

This is because the reason the alternate keywords (and digraphs and trigraphs) were provided was not to make the expressions more readable - it was because historically there have been (and maybe still are) keyboards and/or codepages in some localities that do not have certain punctuation characters. For example, the invariant part of the ISO 646 codepage (surprise) is missing the '|', '^' and '~' characters among others.

Lao

Answer 5

Although I've been programming C++ from quite some time, I did not know that the keywords "and" "or" and "not" were allowed, and I've never seen it used.

I searched through my C++ book, and I found a small section mentioning alternative representation for the normal operators "&&", "||" and "!", where it explains those are available for people with non-standard keyboards that do not have the "&!|" symbols.

A bit like trigraphs in C.

Basically, I would be confused by their use, and I think I would not be the only one. Using a representation which is non-standard, should really have a good reason to be used. And if used, it should be used consistently in the code, and described in the coding standard.

Spivey

Answer 6

The digraph and trigraph operators were actually designed more for systems that didn't carry the standard ASCII character set - such as IBM mainframes (which use EBCDIC). In the olden days of mechanical printers, there was this thing called a "48-character print chain" which, as its name implied, only carried 48 characters. A-Z (uppercase), 0-9 and a handful of symbols. Since one of the missing symbols was an underscore (which rendered as a space), this could make working with languages like C and PL/1 a real fun activity (is this 2 words or one word with an underscore???).

Conventional C/C++ is coded with the symbols and not the digraphs. Although I have been known to #define "NOT", since it makes the meaning of a boolean expression more obvious, and it's visually harder to miss than a skinny little "!".

Copyist

Print technology informs style. I used to do schematic design with output to a pen plotter, and it was mandatory style to put dots on the T-junctions - it wasn't required in order to get the right netlist, but if a pen skipped and you didn't have a dot, the intersection would be unclear on the paper. Later, with laser printers, the dots weren't needed. – Blanche

Answer 7

I wish I could use || and && in normal speech. People try very hard to misunderstand when I say "and" or "or"...

Courtroom

Answer 8

I personally like operators to look like operators. It's all maths, and unless you start using "add" and "subtract" operators too it starts to look a little inconsistent.

I think some languages suit the word-style and some suit the symbols if only because it's what people are used to and it works. If it ain't broke, don't fix it.

There is also the question of precedence, which seems to be one of the reasons for introducing the new operators, but who can be bothered to learn more rules than they need to?

Labors

Answer 9

In cases where I program with names directly mapped to the real world, I tend to use 'and' and 'or', for example:

if(isMale or isBoy and age < 40){}

Selfpossessed

Answer 10

It's nice to use 'em in Eclipse+gcc, as they are highlighted. But then, the code doesn't compile with some compilers :-(

Salic

Answer 11

Using these operators is harmful. Notice that and and or are logical operators whereas the similar-looking xor is a bitwise operator. Thus, arguments to and and or are normalized to 0 and 1, whereas those to xor aren't.

Imagine something like

    char *p, *q; // Set somehow
    if(p and q) { ... } // Both non-NULL
    if(p or q) { ... } // At least one non-NULL
    if(p xor q) { ... } // Exactly one non-NULL

Bzzzt, you have a bug. In the last case you're testing whether at least one of the bits in the pointers is different, which probably isn't what you thought you were doing because then you would have written p != q.

This example is not hypothetical. I was working together with a student one time and he was fond of these literate operators. His code failed every now and then for reasons that he couldn't explain. When he asked me, I could zero in on the problem because I knew that C++ doesn't have a logical xor operator, and that line struck me as very odd.

BTW the way to write a logical xor in C++ is

!a != !b

Genius

Answer 12

I like the idea, but don't use them. I'm so used to the old way that it provides no advantage to me doing it either way. Same holds true for the rest of our group, however, I do have concerns that we might want to switch to help avoid future programmers from stumbling over the old symbols.

Polymorphonuclear

Answer 13

So to summarize: it's not used a lot because of following combination

• old code where it was not used
• habit (more standard)
• taste (more math-like)

Thanks for your thoughts

Polytypic