There are both historical and practical reasons why there is no ^^ operator.

http://c-faq.com/misc/xor.dmr.html

C Programming FAQs: Frequently Asked Questions"

http://returnc.com/archives/2835.html

https://myreadmark.wordpress.com/2014/06/04/cpu-and-memory/

Back in July of 1995,Adam Moscowitz posed this question to Dennis Ritchie:

I teach C programming classes, and I'm often asked why C has a bitwiseexclusive-OR operator but not a logical one. Is this simply anhistorical accident, or was there a specific reason it was omitted?Also, is there any reason why the C9x committee shouldn't consideradding it to the standard?

Dennis replied:

I've often been asked this in person, and it comes up on netnews too.Since I formulated a mildly coherent answer, I'm sending it alongto Steve in case a suitably edited version is suitable for the C FAQ.

---

Answer:

There are both historical and practical reasons why there is no ^^ operator.

The practical is: there's not much use for the operator. The main pointof && and || is to take advantage of their short-circuit evaluation notonly for efficiency reasons, but more often for expressiveness and correctness.For example, in

	if (cond1() && cond2()) ...

it is often important that cond1() is done first, because if it's falsecond2() may not be well defined, or becausecond1() is cheap andcond2() is expensive. Syntax to handle the situation has made it into lotsof languages; compare Ada's `and then'.

By contrast, an ^^ operator would always force evaluation of both armsof the expression, so there's no efficiency gain. Furthermore, situationsin which^^ is really called for are pretty rare, though examples canbe created. These situations get rarer and stranger as youstack up the operator--

	if (cond1() ^^ cond2() ^^ cond3() ^^ ...) ...

does the consequent exactly when an odd number of thecondx()s are true. By contrast, the&& and|| analogs remainfairly plausible and useful.

Historical: C's predecessors (B and BCPL) had only the bitwiseversions of | & ^. They also had a special rule, namely thatin an statement like

	if (a & b) ...

the `&', being at the `top level' of the expression occurring in`truth-value context' (inside theif()) was interpreted justlike C's&&. Similarly for|. But not so for^.

One of the early bits of C evolution was the creation of separate&& and|| operators. This was better than the special rule, which was hardto explain.

In other words, the whole question arises because of the particular methodof symmetry-breaking that C chose. Suppose I had reacted tothe situation of BCPL and B taking their notion of

	if (a & b) ...

and had people say

	if (a) andif (b) ...

(and similarly with `orif'). One can make a case that this kind of syntax isbetter than&& and||. If it had happened, would people be asking for `xorif'?Probably not.

My guess is that &,&&; |,||; ^,^^ is a false symmetry. But it'sone that people seem to want, and, though it's not much help,adding it wouldn't do much harm.

Dennis