«

On 2012-01-30, timprince <> wrote:
> On 1/30/2012 10:32 AM, Anders Wegge Keller wrote:
>>
>> At work, we got into a talk about weird C constructs. One of my
>> collegues volunteered this line:
>>
>> (a>b)?a:b = 42;
>>
>> According to him, he have found three different compilers with three
>> different ways of handling this. One did nothing, one always assigned
>> to b, and the last one did what one should expect, were it legal.
>>
>> We ended up discussing what the acutal problem here is. The
>> diffrerent compilers we had at hand gave different diagnostics, so
>> they giv no clue. We narrowed it down to one of two:
>>
>> 1) a and b are not lvalues in this context.
>>
>> 2) This expression invokes undefined behaviour, since there are no
>> sequence point between (a>b) and the assignment.
>>
>>
>>
> You may require additional parentheses to use this extension more
> reliably (and force diagnostics when it is interpreted as a do-nothing):
> ((a>b)?a:b) = 42;

(a>b)?a:b = 42; means the same thing as ((a>b)?a:b) = 42

(whatever it happens to mean).

The parens would be necessar only if you need to port your code some poor
quality compilers that cannot correctly parse the precedence of an assignment
expression relative to a ternary operator.

The extension is not syntactic but semantic.

James Kuyper <> writes:

> [...] Note
> that this is one of the differences between C and C++; the result of a
> ?: expression is an lvalue in C++.

I'd say "can be a lvalue" since it is not always an lvalue in C++. It's
probably also worth pointing out that the syntax is different between C
and C++. The original means (a > b ? a : b) = 42; in C, but it means
a > b ? a : (b = 42); in C++.

--
Ben.

Le 30/01/12 16:32, Anders Wegge Keller a écrit :
>
> At work, we got into a talk about weird C constructs. One of my
> collegues volunteered this line:
>
> (a>b)?a:b = 42;
>

lcc-win diagnostics this as an error. A ternary operator construct
is not an lvalue.

Anders Wegge Keller <> writes:

> At work, we got into a talk about weird C constructs. One of my
> collegues volunteered this line:
>
> (a>b)?a:b = 42;

GCC 2.x and 3.x had an extension that allowed ?: to yield an
lvalue:
http://gcc.gnu.org/onlinedocs/gcc-3....c_5.html#SEC76
It was never standard, rarely useful, and removed from GCC 4.x.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

"James Kuyper" <> wrote in message
news:...
> On 01/30/2012 11:43 AM, BartC wrote:
>>
>>
>> "Devil with the China Blue Dress" <> wrote in message
>> news:chine.bleu-...
>>> In article <>,
>>> Anders Wegge Keller <> wrote:
>>>
>>>> At work, we got into a talk about weird C constructs. One of my
>>>> collegues volunteered this line:
>>>>
>>>> (a>b)?a:b = 42;
>>>
>>> *(a>b ? &a : &b) = 42;
>>
>> There's no reason why the original version shouldn't work. ...
>
> That depends upon what you mean by "work". The original expression is
> equivalent to
>
> b = 42;

Only if the precedence of ?: is lower than for assignment. Used the other
way:

x = (a>b) ? a : b;

You would expect the conditional expression to be evaluated first. Why not
the same with the conditional on the left?

--
Bartc

gwowen <> writes:

> On Jan 30, 3:32Â*pm, Anders Wegge Keller <we...@wegge.dk> wrote:
>
> > Â*According to him, he have found three different compilers with three
> > different ways of handling this. One did nothing, one always assigned
> > to b, and the last one did what one should expect, were it legal.
>
> What should one expect?
>
> (a>b) ? a : (b=42);

Worse than that:

(a>b) ? (a=42) : (b=42);


--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

"jacob navia" <> wrote in message
news:jg6m3s$1n6$...
> Le 30/01/12 16:32, Anders Wegge Keller a écrit :
>>
>> At work, we got into a talk about weird C constructs. One of my
>> collegues volunteered this line:
>>
>> (a>b)?a:b = 42;
>>
>
> lcc-win diagnostics this as an error. A ternary operator construct
> is not an lvalue.

Strangely, your compiler was the only one of four where this worked
completely as expected!

int a=400;
int b=300;

printf("A=%d B=%d\n",a,b);

(a>b)?a:b = 42;

printf("A'=%d B'=%d\n",a,b);


--
bartc

Kaz Kylheku <> writes:

> On 2012-01-30, Anders Wegge Keller <> wrote:
> >
> > At work, we got into a talk about weird C constructs. One of my
> > collegues volunteered this line:
> >
> > (a>b)?a:b = 42;

...

>> We ended up discussing what the acutal problem here is.

> Probably, that of not knowing that there exist different dialects of
> C, and that your compiler might not be using the one you think it
> is.

No, actually we were discussing why this was prohibited under ISO C,
and wondering exactly *what* part of the standard was violated.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

On 01/30/2012 01:16 PM, BartC wrote:
>
>
> "James Kuyper" <> wrote in message
> news:...
>> On 01/30/2012 11:43 AM, BartC wrote:
>>>
>>>
>>> "Devil with the China Blue Dress" <> wrote in message
>>> news:chine.bleu-...
>>>> In article <>,
>>>> Anders Wegge Keller <> wrote:
>>>>
>>>>> At work, we got into a talk about weird C constructs. One of my
>>>>> collegues volunteered this line:
>>>>>
>>>>> (a>b)?a:b = 42;
>>>>
>>>> *(a>b ? &a : &b) = 42;
>>>
>>> There's no reason why the original version shouldn't work. ...
>>
>> That depends upon what you mean by "work". The original expression is
>> equivalent to
>>
>> b = 42;
>
> Only if the precedence of ?: is lower than for assignment. Used the other
> way:

The ?: operator can't be explained in terms of a simple precedence
relative to other operators.

> x = (a>b) ? a : b;
>
> You would expect the conditional expression to be evaluated first. Why not
> the same with the conditional on the left?

Because I when gwowen wrote his comment, it sounded familiar, like
something I already knew to be true, so I didn't bother to check. I just
checked, and he was wrong, and I was therefore wrong to agree with his
parse. The C grammar is:

logical-OR-expression ? expression : conditional-expression

In the following lines, I've inserted spaces to make corresponding parts
line up with each other, but the alignment will not come out correctly
unless viewed using a monospaced font:

According to that grammar,
a || b ? d , e : f ? g : h
must be parsed as
(a || b) ? (d , e) : (f ? g : h)
but
a ? b : c ? d , e : f = g
must be parsed as
(a ? b : (c ? (d , e) : f)) = g
(that last parse results in a constraint violation, but it's not a
syntax error).

In all other contexts, the C grammar can be understood as giving || a
higher precedence than =, giving both of them higher precedence than the
comma operator. However, there's no way to insert ?: into that
precedence hierarchy that explains both of the above parses.

The C++ grammar is different, as I said, but I had the difference backwards:
logical-or-expression ? expression : assignment-expression

and that's probably what both gwowen and I were thinking about. In C++
a || b ? d , e : f = g
parses as:
(a || b) ? (d , e) : (f = g)
while
a ? b : c ? d , e : f , g
parses as:
(a ? (b : c ? (d , e) : f)), g

which is even harder to explain by inserting the ?: anywhere into the
precedence hierarchy relative to ||, =, and the comma operator.

Arbitrary assignment operation in any parenthesis allowed in C is just teasing
programmers to write more debates for collecting taxes in books about C
programming.

Pascal and Fortran are better in this issue.