Grokking convoluted expressions [LWN.net]

Grokking convoluted expressions

Posted Mar 19, 2007 15:03 UTC (Mon) by tjc (subscriber, #137)
In reply to: Grokking convoluted expressions by ldo
Parent article: Quotes of the week

For everybody else, I've put together this page. :)

A very useful page, but shouldn't the type cast operator be merged with the prefix unary group, instead of being in a group by itself? I can compile this without error with gcc 4.1.0:

int main()
{
        double foo = 1.0;

        ~(int)foo;

        return 0;
}

If the type cast operator has lower precedence than the bitwise one's complement operator, then the later should be evaluated first, and the compiler would produce the error "wrong type argument to bit-complement."

On the other hand, since these are both prefix operators and right-to-left associative, and if they both have the same precedence level, then the type cast will be evaluated first and there will be no error.

(Log in to post comments)

Grokking convoluted expressions

Posted Mar 20, 2007 1:41 UTC (Tue) by ldo (subscriber, #40946) [Link]

If the type cast operator has lower precedence than the bitwise one's complement operator, then the later should be evaluated first, and the compiler would produce the error "wrong type argument to bit-complement."

Well, actually no, since the syntax of your example is that bitwise-complement is applied to the result of the cast, there's no way not to do the cast first. (The only other way to try to interpret it is that bitwise-complement applies to the type, but C syntax doesn't allow that interpretation.)

You're right that it doesn't have any effect to separate cast out into its own grouping. However, I'm following the groupings in section A7 of K&R2, which puts casting into its own subsection, coming after the other prefix unary operators.

Grokking convoluted expressions

Posted Mar 20, 2007 14:41 UTC (Tue) by tjc (subscriber, #137) [Link]

Well, actually no, since the syntax of your example is that bitwise-complement is applied to the result of the cast, there's no way not to do the cast first.

Exactly, which is why the type cast operator can't *really* be at a level below the unary prefix operators. If it was, then the one's complement would be evaluated first, which would produce an error since the operand is a floating-point number.

I'm following the groupings in section A7 of K?R2, which puts casting into its own subsection, coming after the other prefix unary operators.

Thanks for the tip, I'll take a look at K?R2 when I get home. There's also a grammar at the back of the book that might reveal why they put the type cast operator in a separate group.