?: as an lvalue

"Bartc" <bc@freeuk.com> writes:

> bert wrote: 
> 
> 
>
> I don't think it was praise..
> 
>
> There was nothing much wrong with the original syntax:
>
>  a ? b : c = x;
>
> (maybe better as (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 unnecessar
y
> 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.

>
> 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?

"Richard" <devr_@gmail.com> wrote in message
news:fsr52k$1id$1@registered.motzarella.org...
> "Bartc" <bc@freeuk.com> writes:
>
 
... 
>
> 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?
> 
>
> 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.

> 
>
> There is no mystery about it.
> 
>
> 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

Richard <devr_@gmail.com> writes:

> "Bartc" <bc@freeuk.com> writes:
<snip> 
>
> There is no mystery about it.

Why not help by explaining it then?  It is a mystery to me as well, so
least least two people would benefit from your explanation.

In particular, a Closely Related Language, *does* allow the result of
a conditional operator to be an lvalue.  I can't think, off-hand, of a
reason for this difference.

--
Ben.

Richard wrote: 
>
> Well done - you'll make maintainers very happy in years to come.
>
> What on earth is wrong with
>
>      v= complex expr;
>      if(i)
>         aa=v;
>      else
>         b=v;
>
> Same number of characters give or take too .... Easy to see
> flow/assignment in a debugger too. Very easy to read.

There's nothing wrong with it except that it is a _statement_, while the
previous form is an _expression_. While I personally strongly prefer the
former in "normal" code, there are still quite a few expression-based
idiomatic tricks in C programming, which require the use of the
expression form.

I don't see the point in starting an argument about this. If at all, you
should probably direct your question to the authors of the language,
asking them why they introduced this "redundant" ?: operator in the
first place.

--
Best regards,
Andrey Tarasevich

On Mar 30, 7:19 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Rahul said:
> 
> 
> 
>
> This is a syntax error (which therefore requires the implementation to
> diagnose it as such). The syntax of the conditional operator is:
>

I believe the syntax is legal.  It just doesn't do what the OP wanted
it to.

Consider that it parses as

(1>0)?(aa):(b=10);

Change it to 1<0?aa:b=10; and see the result...

Regards,

-=Dave

Dave Hansen wrote:
> On Mar 30, 7:19 am, Richard Heathfield <r...@see.sig.invalid> wrote: 
>
> I believe the syntax is legal.  It just doesn't do what the OP wanted
> it to.
>
> Consider that it parses as
>
>    (1>0)?(aa):(b=10);

Would you care to place a small wager on that?

You could refer to the formal grammar in the Standard
to settle the question, or you could ask informally which
of = and ?: "binds more tightly."  The parse you suggest
would follow if = binds more tightly, in which case

x = a ? b : c;

would parse as

(x = a) ? b : c;

Since we know that it actually parses as

x = (a ? b : c);

you may be about to lose some money ...

--
Eric.Sosman@sun.com

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard <devr_@gmail.com> writes:
> 
> <snip> 
>
> Why not help by explaining it then?  It is a mystery to me as well, so
> least least two people would benefit from your explanation.

Huh? I must be missing something here or I will be first to apologise.

We already know that

*(c?x:y)=v;

is ok where x and y are pointers.

But (c?x:y)=v;

I dont really know what to say.

>
> In particular, a Closely Related Language, *does* allow the result of
> a conditional operator to be an lvalue.  I can't think, off-hand, of a
> reason for this difference.

Richard wrote:
> ...
> But (c?x:y)=v;
> I dont really know what to say.

Is there any reason why you believe that the property of "being an
lvalue" should be necessarily lost in the process of selection from two
lvalues of the same type?

I mean I'm OK personally with the way it works in C. I just like to know
what is it exactly in '(c?x:y)=v' that triggers a "I don't really know
what to say" reaction from some people.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> Richard wrote: 
>
> Is there any reason why you believe that the property of "being an
> lvalue" should be necessarily lost in the process of selection from
> two lvalues of the same type?
>
> I mean I'm OK personally with the way it works in C. I just like to
> know what is it exactly in '(c?x:y)=v' that triggers a "I don't really
> know what to say" reaction from some people.

because its not a macro? it returns a value. I dont know the legalise
words but it seems "obvious" enough to me, but again it might be because
I am tainted.

Eric wrote:
) Dave Hansen wrote:
)> Consider that it parses as
)>
)>    (1>0)?(aa):(b=10);
)
)      Would you care to place a small wager on that?
)
)      You could refer to the formal grammar in the Standard
) to settle the question, or you could ask informally which
) of = and ?: "binds more tightly."  The parse you suggest
) would follow if = binds more tightly, in which case

Technically, it would also follow if = binds equally tightly.
Left-to-right and all that.

) 	x = a ? b : c;
)
) would parse as
)
) 	(x = a) ? b : c;

Again, purely technically, it would not if = were to bind equally tightly.

) Since we know that it actually parses as
)
) 	x = (a ? b : c);
)
) you may be about to lose some money ...

I'm not going to bet on it though.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT