?: as an lvalue

Rahul wrote:
> I tried MS VC++ 8.0...

I tried the same compiler and got essentially the same error, saying that le
ft
operand must be a lvalue.

> http://www.dinkumware.com/exam/default.aspx

If you tried it at this link, then most likely your code was compiled as C++
. In
C++ it would be parsed as '1 > 0 ? aa : (b = 10)'. Additionally in C++ the
result of ?: can be lvalue. It is not surprise that you didn't get an error.

--
Best regards,
Andrey Tarasevich

On 30 Mar, 15:02, Philip Potter <p...@doc.ic.ac.uk> wrote:
> Rahul wrote: 
> 
> 
> 
> 
>
> The result of the ?: operator is not an lvalue, and cannot be assigned to.=[/color
]

>
> If you want to conditionally assign to one of two objects, it's probably
> clearer to write it in full:
>
> if (1>0)
> =A0 =A0 aa =3D 0;
> else
> =A0 =A0 b =3D 10;
>
> If you really want unreadable code, I suppose you could do this:
> int *ip[2] =3D {&b,&aa};
>
> *ip[1>0] =3D 10;
>
> but if I worked with you I wouldn't thank you for it :)

For such requirements, I have written - and
been satisfied with - code of the style:

*(i > 0 ? &aa : &b) =3D <complicated expression>;
--

bert <bert.hutchings@btinternet.com> writes:

> On 30 Mar, 15:02, Philip Potter <p...@doc.ic.ac.uk> wrote: 
>
> For such requirements, I have written - and
> been satisfied with - code of the style:
>
> *(i > 0 ? &aa : &b) = <complicated expression>;

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.

In article <fsol4n$7uf$1@registered.motzarella.org>,
Richard  <devr_@gmail.com> wrote:
...
>Same number of characters give or take too .... Easy to see
>flow/assignment in a debugger too. Very easy to read.

You know perfectly well that nobody here uses a debugger.

Flash Gordon said:

> Rahul wrote, On 30/03/08 12:05: 
>
> In that case you need to tell your compiler to act as a C compiler
> rather than as an extended-C-like-language compiler.

The OP is using http://www.dinkumware.com/exam/default.aspx to test his
code. When I present that site with the following source:

#include <stdio.h>

int main(void)
{
int a = 0;
int b = 0;

1 > 0 ? a : b = 10;

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

return 0;
}

and select the only C option I can find, which is the EDG C99 option, I get
no diagnostic messages whatsoever (unless you count "Code compiled
successfully!" as a diagnostic message).

Either this is a bug in EDG's compiler, or the rules changed in C99. I can
find no evidence of a rule change in C99.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> Either this is a bug in EDG's compiler, or the rules changed in C99. I can
> find no evidence of a rule change in C99.

I tried compiling this with EDG/C99 option

void* v = 0;
int* p = v;

and it said that "a value of type "void *" cannot be used to initialize an
entity of type "int *"". I tried compiling this

int* p = (int[]) { 1, 2, 3 };

and it doesn't seem to know what it is. While this

class C {};

compiles successfully.

Obviously, EDG/C99 option actually stands for C++ compiler. What they mean b
y
C99 I don't know. In the output windows it says

Your code has been compiled with the EDG compiler using the Dinkum C99
library from the Dinkum Compleat Libraries package.

which probably means that C99 standard library used as C-portion of C++ stan
dard
library.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich said:

<snip>

> [EDG C99] said that "a value of type "void *" cannot be used to
> initialize an entity of type "int *"". I tried compiling this
>
>    int* p = (int[]) { 1, 2, 3 };
>
> and it doesn't seem to know what it is. While this
>
>    class C {};
>
> compiles successfully.
>
> Obviously, EDG/C99 option actually stands for C++ compiler.

It would appear so. As another data point, it also diagnoses recursive
main:

"sourceFile.c", line 8: error:
function "main" may not be called or have its address taken
main(argc - 1, argv + 1);
^

1 error detected in the compilation of "sourceFile.c".

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On 30 Mar, 19:11, Richard <de...@gmail.com> wrote:
> bert <bert.hutchi...@btinternet.com> writes: 
> 
er 
> 
> 
> 
> 
to.
> 
y 
> 
> 
> 
> 
> 
> 
>
> Well done - you'll make maintainers very happy in years to come.

I can't decide whether that's sarcasm from you, or real praise.

> What on earth is wrong with
>
> =A0 =A0 =A0v=3D complex expr;
> =A0 =A0 =A0if(i)
> =A0 =A0 =A0 =A0 aa=3Dv;
> =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 b=3Dv;
>
> Same number of characters give or take too .... Easy to see
> flow/assignment in a debugger too. Very easy to read.- Hide quoted text -

The main thing "wrong" with your alternative
is the omission of a block structure.

{
int v =3D complicated expression;
if (i)
aa =3D v;
else
b =3D v;
}

would make it perfectly clear to a maintainer
in years to come that the only purpose of v
was to be assigned either to aa or to b.
--

bert <bert.hutchings@btinternet.com> writes:

> On 30 Mar, 19:11, Richard <de...@gmail.com> wrote: 
>
> I can't decide whether that's sarcasm from you, or real praise.
> 
>
> The main thing "wrong" with your alternative
> is the omission of a block structure.

There is no omission. It was concentrating on the core code.

>
> {
>  int v = complicated expression;
>  if (i)
>    aa = v;
>  else
>    b = v;
> }
>
> would make it perfectly clear to a maintainer
> in years to come that the only purpose of v
> was to be assigned either to aa or to b.

That is another issue.

bert wrote:
> On 30 Mar, 19:11, Richard <de...@gmail.com> wrote: 
 
 
>
> I can't decide whether that's sarcasm from you, or real praise.

I don't think it was praise..

> 
>
> The main thing "wrong" with your alternative
> is the omission of a block structure.
>
> {
>  int v = complicated expression;
>  if (i)
>    aa = v;
>  else
>    b = v;
> }
>
> would make it perfectly clear to a maintainer
> in years to come that the only purpose of v
> was to be assigned either to aa or to b.

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:

*(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.

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.

--
Bart