Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The choice of operator seems very odd to me. Wouldn't `^` be significantly more readable?


^ is already used for bitwise xor.


What about then, like some other languages?


Python uses * * , but that is ambigous with

  int a = 1;
  int *b = &a;
  int c = a ** b;
  // Am I casting b to an int (returning it's address) and exponenting it or am I derefrencing b and multiplying it's result with a?


How would this be different from &? It is also a unary operator and && is a different binary operator.

'||' and '&&' are distinct tokens in C as far as i know, i.e. not handled as two consecutive '|'s or '&'s.

So your example would unambiguously be parsed as "a to the b:th power". Whereas the other case would need explicit parens:

   int c = a * (*b);
Similar example for &:

   int a = 1;
   int b = 1 && a; /* 1 LOGICAL_AND a */
   int c = 1 & (&a); /* 1 AND address of a */


Just dropping in to say you are completely correct. It is called "maximum munch" and mandated by the C spec. I recently wrote a toy C compiler and was confused until I learned this.


I suppose ^^ might work, although a little odd because by consistency it would otherwise be the "logical XOR", a mythical operator that doesn't actually make much sense.


> a mythical operator that doesn't actually make much sense.

Hmm I'm pretty sure practically every programming languages have it. It usually looks like "!=" or "<>".

The even more obscure logical XNOR is usually denoted "==" or "="


Alas, this doesn't deal with the idea of truthyness as a proper logocal XOR would, so it is incorrect in many of the most popular languages, including C, where a value that is true is not always equal to another value that is true. This only works in the much more strongly typed languages, or when you force cast both sides to a boolean with something like !!


Yes! In C its full spelling is "!a != !b".


Not quite..


Perl has logical xor, which is occasionally useful. I usually reach for it when argument checking, where it makes sense to have either this param or that but not both.


> What about then, like some other languages?

I assume there's a double asterisk there, and it's being eaten by the formatter?


Right yes. I forgot to escape, and now it's too late to.


Probably too much ambiguity with pointers




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: