|
|
Richard <devr_@xxxxxxxxx> writes:
> Andrey Tarasevich <andreytarasevich@xxxxxxxxxxx> writes:
>
>> Richard wrote:
>>>>> Exactly why a?b:c can't appear like that on the left-hand-side of
>>>>> an assignment is a bit of a mystery; 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.
>>>> Because b and c are two distinct objects that can have different types,
>>>> which makes the type of any resulting lvalue somewhat problematic.
>>>>
>>> That should nail it ...
>>
>> No, that completely misses it. For example, what will happen if you
>> try to compile this
>>
>> double* d;
>> int* i;
>>
>> 1 < 0 ? d : i;
>>
>> Here's another example
>>
>> struct A { int i; } a;
>> struct B { int i; } b;
>>
>> 1 < 0 ? a : b;
>>
>> I'll answer it for you: in both cases the code is invalid. It won't
>> compile. Why? Because the existing type-compatibility requirements
>> imposed on the second and third parameter of '?:' have been
>> violated. Note, that this is normal C '?:', which returns a
>
> Exactly.
That is too terse. It seems unlikely that you agree with Andrey
Tarasevitch since he is explaining why your "that should nail it"
comment was a bit premature.
If you disagree, you would need to have commented on the bit you
clipped:
Andrey Tarasevich <andreytarasevich@xxxxxxxxxxx> writes:
| What it illustrates is that the type-compatibility requirements are
| _already_ in the language. They are already there and there's no way
| around them. The fact that '?:' returns a non-lvalue in C doesn't
| really make things easier. And making '?:' return an lvalue wouldn't
| really make things harder.
Type-checking (c ? a : b) = v; is not obviously any harder than
type-checking v = (c ? a : b);.
--
Ben.
|
|