is83020@cis.nctu.edu.tw (Cheng-hsien Chang) writes:

>There are some operator treat L-value and R-value differently
>between C++ and C. like this:

> 1.
>  int a;
>  ++++a;
>   ===> Error in C; and Correct in C++;
> 2.
>  int a;
>  (a=2)=3;
>   ===> Error in C; and Correct in C++;

> Is there something else about different L-value and
> R-Value treatment between C++ and C?

Hi!

I guess, that in C++ followed expression also is correct:

( Flag ? a : b) = r_value;

but not in C...

Best regards, Nick.
--
-------------------------------------------------
Nickolay Belofastow
University of the Federal Armed Forces, Munich
e81bnick@rz.unibw-muenchen.de
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

ccshan@husc.harvard.edu (Chung-chieh Shan) writes:

> J. Kanze (kanze@gabi-soft.fr) wrote:
> > I think that for the basic types, all expressions that would be illegal
> > in C are also illegal in C++.  On the other hand, there is some
> > justification for the "lvalue-ness" when classes are considered.  If "a"
> > and "b" have class type, for example:
>
> >   (a = b).c = x ;
>
> > If "c" has a user defined operator=, for example, there is a function
> > call before the second modification of the (c in the) a object; this
> > function call is a sequence point, and makes the above defined.
>
> This is a bit disturbing.
>
> Suppose that c is an int.  Then the assignment from x to c doesn't
> involve any function calls, and so (to my understanding) the b-to-a
> assignment can happen *after* the x-to-c assignment, the former
> overwriting the latter with b.c (or whatever a.operator= assigns to
> a.c, if the default operator= is not being used).

If c is an int, the sub-expression "a = b" modifies a.c, as does the
final expression.  Modifying the same object twice without an
intervening sequence point is undefined behavior, and has been for as
long as I have been using C (since about 1982).

> However, if c is a struct, then the assignment does involve a function
> call a.c.operator=(x), and so it is guaranteed that the x-to-c assignment
> will happen after the b-to-a assignment.  To my understanding, even if
> c is a plain C struct, a call to an implicitly generated operator=() is
> still a function call, and so still constitutes a sequence point.

Your understanding doesn't coincide with mine, but I'll admit that
you've sown a doubt.  Does an implicitly generated function (like
operator=) count as a sequence point or not?

> Please correct me if any of the above is wrong.

How about: unknown?

> Obviously, any program that relies on all this detail is probably bad
> anyway, but the subtleness of this difference between built-in and
> user-defined C++ objects worries me a bit.

The subtleness is there.  You can't get away from it.  In theory, it can
sometimes be not subtle at all; once the user starts overloading
operators, all bets are off as to the meaning of those operators.  The
fact that a user defined operator+ creates a sequence point is nothing
compared to the fact that a user defined operator+ might actually
subtract.

Note that programs that don't rely on a given sequence point will work
even if it is there.

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <53vm9v$lbd@news.cis.nctu.edu.tw> Cheng-hsien Chang wrote:
> There are some operator treat L-value and R-value differently
> between C++ and C. like this:

>  1.
>   int a;
>   ++++a;
>    ===> Error in C; and Correct in C++;
>  2.
>   int a;
>   (a=2)=3;
>    ===> Error in C; and Correct in C++;

>  Is there something else about different L-value and
>  R-Value treatment between C++ and C?

Also the result of `?' operator is l-value in c++, if both the second and
the third operands are l-values of the same type.

--
Alexander N. Krotoff  krotoff@such.srcc.msu.su
Research Computer Center tel: +7(095)939-2638
Moscow State University  fax: +7(095)939-4430


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

There are some operator treat L-value and R-value differently
between C++ and C. like this:

 1.
  int a;
  ++++a;
   ===> Error in C; and Correct in C++;
 2.
  int a;
  (a=2)=3;
   ===> Error in C; and Correct in C++;

 Is there something else about different L-value and
 R-Value treatment between C++ and C?


--
Cheng-hsien Chang


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

is83020@cis.nctu.edu.tw (Cheng-hsien Chang) writes:

> There are some operator treat L-value and R-value differently
> between C++ and C.

Some operators didn't result in an lvalue in C do in C++.  Prefix
incrementation and decrementation, and assignment, are examples.

In C, an operator results in an lvalue if and only if there would be
some way of legally using the results when the operator is applied to
built-in types.  In C++, an operator results in an lvalue in all cases
where the operator itself manipulates an lvalue, and the results of the
operator are equal to the value of the lvalue object.  (Thus, for
example, prefix ++ results in an lvalue, because the results are equal
to the value of the object, whereas postfix ++ is not an lvalue, because
the results correspond to the previous value, and not the current
value.)

Note that the examples that you cite ("++++a" and "(a=2)=3)", where "a"
is an int) are illegal in both C and C++, but for different reasons.  In
C, the results of the first operation are not an lvalue, and the second
operator requires an lvalue.  A constraint has been violated, and a
diagnostic is required.  In C++, both of these expressions attempt to
modify the same object twice without an intervening sequence point, and
so result in undefined behavior.

I think that for the basic types, all expressions that would be illegal
in C are also illegal in C++.  On the other hand, there is some
justification for the "lvalue-ness" when classes are considered.  If "a"
and "b" have class type, for example:

  (a = b).c = x ;

If "c" has a user defined operator=, for example, there is a function
call before the second modification of the (c in the) a object; this
function call is a sequence point, and makes the above defined.

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze (kanze@gabi-soft.fr) wrote:
> I think that for the basic types, all expressions that would be illegal
> in C are also illegal in C++.  On the other hand, there is some
> justification for the "lvalue-ness" when classes are considered.  If "a"
> and "b" have class type, for example:

>   (a = b).c = x ;

> If "c" has a user defined operator=, for example, there is a function
> call before the second modification of the (c in the) a object; this
> function call is a sequence point, and makes the above defined.

This is a bit disturbing.

Suppose that c is an int.  Then the assignment from x to c doesn't
involve any function calls, and so (to my understanding) the b-to-a
assignment can happen *after* the x-to-c assignment, the former
overwriting the latter with b.c (or whatever a.operator= assigns to
a.c, if the default operator= is not being used).

However, if c is a struct, then the assignment does involve a function
call a.c.operator=(x), and so it is guaranteed that the x-to-c assignment
will happen after the b-to-a assignment.  To my understanding, even if
c is a plain C struct, a call to an implicitly generated operator=() is
still a function call, and so still constitutes a sequence point.

Please correct me if any of the above is wrong.

Obviously, any program that relies on all this detail is probably bad
anyway, but the subtleness of this difference between built-in and
user-defined C++ objects worries me a bit.

--
blue | Ken; Shan, Chung-chieh; Sian7, Tiong1-kiat8; ccshan@fas.harvard.edu.
 ()  | Your code today becomes the mind tomorrow:  Your plan its means,
 /\  | your dream its ends, your ideal its elegance.  Hack on.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]