|
|
"Richard" <devr_@xxxxxxxxx> wrote in message
news:fsr52k$1id$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> "Bartc" <bc@xxxxxxxxxx> writes:
>
>> There was nothing much wrong with the original syntax:
>>
>> a ? b : c = x;
...
>> except that C doesn't allow it, and it's unfortunate that the legal
>> format
>> is a little messy:
>
> So nothing wrong with it except for the fact that C doesnt allow it? Are
> you trolling or just up for some sort of special award?
>
>>
>> *(a ? &b ? &c) = x;
>>
>> This is what the programmer wants to do, so why force him to create
>> unnecessary statements and to duplicate expressions, or declare
>> unnecessary
>> temporary variables? All extra clutter.
>
> Dont be ridiculous. Everything is a trade off between readability,
> maintainability and efficiency. The above is , IMO, too clever for its
> own good. And its certainly no more efficient.
You can argue the same way about using a?b:c as an rvalue.
>
>>
>> Exactly why a?b:c can't appear like that on the left-hand-side of an
>> assignment is a bit of a mystery;
>
> There is no mystery about it.
>
>> after all a, a.b, a->b, a[b] and so on can
>> all appear on the lhs without the programmer having to insert explicit
>> address-of operators.
>
> And that has to do with ?: how?
a: You can write a = x without writing *(&a) = x
a.b: You can write a.b = x without writing *(&a + offsetof b) = x
(I think offsetof is more complex than that)
a->b: You can write a->b = x without writing *(&a + offsetof b) = x
a[b]: You can write a[b] = x without writing *(a+b) = x
a?b:c: You CAN'T write a?b:c = x without writing *(a ? &b : &c) = x
So the mystery is why the compiler gives special dispensation to those other
forms when an lvalue is expected, but not the ?: form.
Someone will say, for the same reason as a+b can't usually be an lvalue, but
I think ?: is a little different.
--
Bart
|
|