Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #101118 > unrolled thread

Re: lvalues from the ternary op

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: lvalues from the ternary op Manfred <noname@invalid.add> - 2017-01-04 19:46 +0100
    Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-04 11:08 -0800
    Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 21:10 +0000
      Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 13:48 -0800
        Re: lvalues from the ternary op Ian Collins <ian-news@hotmail.com> - 2017-01-05 11:07 +1300
          Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 14:20 -0800
        Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-04 14:41 -0800
          Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 15:21 -0800
            Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-04 15:52 -0800
              Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 16:37 -0800
              Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-04 18:31 -0800
                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 17:26 -0800
                  Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-13 17:49 -0800
                    Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 22:53 -0800
      Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 17:08 -0800
        Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 02:15 +0000
          Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 22:51 -0800
        Re: lvalues from the ternary op luser droog <luser.droog@gmail.com> - 2017-01-16 23:09 -0800
          Re: lvalues from the ternary op Manfred <noname@invalid.add> - 2017-01-18 14:51 +0100
            Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 09:59 -0800
              Re: lvalues from the ternary op Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-01-18 13:12 -0500
              Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-18 12:11 -0800
                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 12:45 -0800
                  Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-18 14:07 -0800
                    Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 14:40 -0800
                      Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-18 16:10 -0800
                        Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-18 18:08 -0800
                          Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-19 06:44 -0800
                            Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-19 08:40 -0800
                              Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-19 12:32 -0800
                              Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-20 06:01 -0800
                                Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-20 08:15 -0800
                                  Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-20 10:51 -0800
                                    Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-20 11:32 -0800
                                      Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-20 13:41 -0800
                                      Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-23 07:04 -0800
                                        Re: lvalues from the ternary op Ike Naar <ike@iceland.freeshell.org> - 2017-01-23 17:59 +0000
                                          Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-23 10:57 -0800
                                        Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:45 -0800
                                          Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-01-31 09:13 -0800
                                          Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-31 10:17 -0800
                                            Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-01 01:51 +0000
                                              Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-01 14:24 -0800
                                                Re: lvalues from the ternary op Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-02 03:07 +0000
                                                  Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 04:43 -0800
                                                    Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-04 08:01 -0800
                                                      Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 09:06 -0800
                                                        Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-09 11:56 -0800
                                                          Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 10:29 -0800
                                                            Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-12 13:43 -0800
                                                              Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:44 -0800
                                                                Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-20 08:15 -0800
                                                                  Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 07:58 -0800
                                                                    Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-24 10:00 -0800
                                                                      Re: lvalues from the ternary op scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 18:58 +0000
                                                                        Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-24 13:03 -0800
                                                                          Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 14:11 -0800
                                                                      Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 12:42 -0800
                                                                        Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 13:49 -0800
                                                                        Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-24 13:58 -0800
                                                                          Re: lvalues from the ternary op Keith Thompson <kst-u@mib.org> - 2017-02-24 14:56 -0800
                                                                            Re: lvalues from the ternary op supercat <flatfinger@casperkitty.com> - 2017-02-25 14:00 -0800
                                                                        Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 09:23 -0800
                                                                      Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 09:43 -0800
                                            Re: lvalues from the ternary op Kelsey Bjarnason <kbjarnason@gmail.com> - 2017-02-01 22:47 -0800
                                              Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-02 10:12 -0800
                                                Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 07:51 -0800
                                                  Re: lvalues from the ternary op supercat@casperkitty.com - 2017-02-04 08:18 -0800
                                                    Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 08:58 -0800
                                              Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 04:00 -0800
                                                Re: lvalues from the ternary op Kelsey Bjarnason <kbjarnason@gmail.com> - 2017-02-04 09:35 -0800
                                            Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 09:35 -0800
                                        Re: lvalues from the ternary op Robert Wessel <robertwessel2@yahoo.com> - 2017-01-31 13:36 -0600
                                          Re: lvalues from the ternary op supercat@casperkitty.com - 2017-01-31 12:23 -0800
                                          Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 13:48 -0800
                          Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:53 -0800
              Re: lvalues from the ternary op Manfred <noname@invalid.add> - 2017-01-19 14:10 +0100
          Re: lvalues from the ternary op Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 12:05 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#101118 — Re: lvalues from the ternary op

On 9/28/2016 1:23 AM, Ben Bacarisse wrote:
> I consider special cases to be a sort of intellectual cost.
I am 100% with you.

   But my
> remark about it being a shame is not intended to be a considered
> weighing-up of hard engineering costs but simply a sad observation on
> there being yet another exception I would not have expected.  If I did
> not know better, I would assume that that any expression that could
> reasonably be a lvalue would be an lvalue.
Maybe the keyword here is "reasonably", which would point out that what 
is reasonable for C++ is not for C.
Here the C rationale appears to be "result of expressions are rvalues" 
i.e. value-oriented, while the C++ rationale appears to be "result of 
expressions are objects" i.e. more symbol-oriented.

[toc] | [next] | [standalone]

#101120

On Wednesday, January 4, 2017 at 12:46:16 PM UTC-6, Manfred wrote:
> Here the C rationale appears to be "result of expressions are rvalues" 
> i.e. value-oriented, while the C++ rationale appears to be "result of 
> expressions are objects" i.e. more symbol-oriented.

I think the issue is instead that C++ recognizes the concept of an object
reference as a kind of value which may, but need not, be represented as an
address, and whose usage is somewhat more restricted than that of a pointer.

[toc] | [prev] | [next] | [standalone]

#101133

Manfred <noname@invalid.add> writes:

> On 9/28/2016 1:23 AM, Ben Bacarisse wrote:
>> I consider special cases to be a sort of intellectual cost.
> I am 100% with you.
>
>>   But my
>> remark about it being a shame is not intended to be a considered
>> weighing-up of hard engineering costs but simply a sad observation on
>> there being yet another exception I would not have expected.  If I did
>> not know better, I would assume that that any expression that could
>> reasonably be a lvalue would be an lvalue.
> Maybe the keyword here is "reasonably", which would point out that
> what is reasonable for C++ is not for C.

Yes, it's a hopelessly woolly word.  Almost as soon as I'd written it I
thought: well, that doesn't say much, does it?

> Here the C rationale appears to be "result of expressions are rvalues"
> i.e. value-oriented, while the C++ rationale appears to be "result of
> expressions are objects" i.e. more symbol-oriented.

I can't comment on C++'s abstract model because I have not studied the
standard, but, in C, expressions /evaluate/ to values (we could call
them rvalues but that's probably unnecessary and the standard doesn't),
whereas some syntactic forms of expression /are/ lvalues.  So you are
right that there is no kind of "value" (in C's abstract semantics) that
could be used to denote objects.  lvalues are simply expressions, not
values, despite the name.

But I don't think that gets us any closer to knowing what might or might
not be "reasonable" in C.  The C standard enumerates all the expression
forms that are lvalues and, as in the case of x.y for example, it
sometimes depends on whether one or other part of the expression is
itself an lvalue.  So there's no obvious reason that it could not say
that a conditional expression is an lvalue if both arms are lvalue
expressions.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101136

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> But I don't think that gets us any closer to knowing what might or might
> not be "reasonable" in C.  The C standard enumerates all the expression
> forms that are lvalues and, as in the case of x.y for example, it
> sometimes depends on whether one or other part of the expression is
> itself an lvalue.  So there's no obvious reason that it could not say
> that a conditional expression is an lvalue if both arms are lvalue
> expressions.

And of the same type, or perhaps compatible types would be sufficient.

For example, this:

    int x;
    double y;
    (condition ? x : y) = 42;

would be difficult to implement sensibly.  Taking the address of a
ternary expression would be even more difficult.  (C++ already does
this; I haven't checked the standard's wording.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101140

On 01/ 5/17 10:48 AM, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> But I don't think that gets us any closer to knowing what might or might
>> not be "reasonable" in C.  The C standard enumerates all the expression
>> forms that are lvalues and, as in the case of x.y for example, it
>> sometimes depends on whether one or other part of the expression is
>> itself an lvalue.  So there's no obvious reason that it could not say
>> that a conditional expression is an lvalue if both arms are lvalue
>> expressions.
>
> And of the same type, or perhaps compatible types would be sufficient.
>
> For example, this:
>
>      int x;
>      double y;
>      (condition ? x : y) = 42;
>
> would be difficult to implement sensibly.  Taking the address of a
> ternary expression would be even more difficult.  (C++ already does
> this; I haven't checked the standard's wording.)

Does it?

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#101142

Ian Collins <ian-news@hotmail.com> writes:
> On 01/ 5/17 10:48 AM, Keith Thompson wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>> But I don't think that gets us any closer to knowing what might or might
>>> not be "reasonable" in C.  The C standard enumerates all the expression
>>> forms that are lvalues and, as in the case of x.y for example, it
>>> sometimes depends on whether one or other part of the expression is
>>> itself an lvalue.  So there's no obvious reason that it could not say
>>> that a conditional expression is an lvalue if both arms are lvalue
>>> expressions.
>>
>> And of the same type, or perhaps compatible types would be sufficient.
>>
>> For example, this:
>>
>>      int x;
>>      double y;
>>      (condition ? x : y) = 42;
>>
>> would be difficult to implement sensibly.  Taking the address of a
>> ternary expression would be even more difficult.  (C++ already does
>> this; I haven't checked the standard's wording.)
>
> Does it?

Perhaps "does this" was ambiguous.  What I meant is that in C++, given:

    int i1, i2;
    double x;

(condition ? i1 : i2) is an lvalue, but (condition ? i1 : x) is not.
I verified this by compiling a couple of small test programs (with
a ternary expression on the LHS of an assignment) with g++.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101144

On Wednesday, January 4, 2017 at 3:48:34 PM UTC-6, Keith Thompson wrote:
> For example, this:
> 
>     int x;
>     double y;
>     (condition ? x : y) = 42;
> 
> would be difficult to implement sensibly.  Taking the address of a
> ternary expression would be even more difficult.  (C++ already does
> this; I haven't checked the standard's wording.)

The Standard already includes type resolution rules for condition?p:q where
p and q are pointers.  If the result of the conditional expression is used
as an object, is there any reason the type resolution rules for
*(condition ? &x : &y) couldn't be used for (condition ? x : y), but with
the proviso that if the address of the expression isn't taken, x and y need
not be regarded as having had their addresses taken by the expression, would
not be adequate?

[toc] | [prev] | [next] | [standalone]

#101146

supercat@casperkitty.com writes:
> On Wednesday, January 4, 2017 at 3:48:34 PM UTC-6, Keith Thompson wrote:
>> For example, this:
>> 
>>     int x;
>>     double y;
>>     (condition ? x : y) = 42;
>> 
>> would be difficult to implement sensibly.  Taking the address of a
>> ternary expression would be even more difficult.  (C++ already does
>> this; I haven't checked the standard's wording.)
>
> The Standard already includes type resolution rules for condition?p:q where
> p and q are pointers.  If the result of the conditional expression is used
> as an object, is there any reason the type resolution rules for
> *(condition ? &x : &y) couldn't be used for (condition ? x : y), but with
> the proviso that if the address of the expression isn't taken, x and y need
> not be regarded as having had their addresses taken by the expression, would
> not be adequate?

No reason I can think of (but I'd probably phrase the proviso
differently).  Of course (condition ? x : y) in the example above still
wouldn't be an lvalue.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101147

On Wednesday, January 4, 2017 at 5:20:55 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> > The Standard already includes type resolution rules for condition?p:q where
> > p and q are pointers.  If the result of the conditional expression is used
> > as an object, is there any reason the type resolution rules for
> > *(condition ? &x : &y) couldn't be used for (condition ? x : y), but with
> > the proviso that if the address of the expression isn't taken, x and y need
> > not be regarded as having had their addresses taken by the expression, would
> > not be adequate?
> 
> No reason I can think of (but I'd probably phrase the proviso
> differently).  Of course (condition ? x : y) in the example above still
> wouldn't be an lvalue.

Under the existing rules, it wouldn't be an lvalue, but that the whole
point of this discussion is how things might behave if the language were
changed to allow for ternary expressions to yield lvalues.  I'm curious
how you'd word the proviso.

[toc] | [prev] | [next] | [standalone]

#101150

supercat@casperkitty.com writes:
> On Wednesday, January 4, 2017 at 5:20:55 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > The Standard already includes type resolution rules for condition?p:q where
>> > p and q are pointers.  If the result of the conditional expression is used
>> > as an object, is there any reason the type resolution rules for
>> > *(condition ? &x : &y) couldn't be used for (condition ? x : y), but with
>> > the proviso that if the address of the expression isn't taken, x and y need
>> > not be regarded as having had their addresses taken by the expression, would
>> > not be adequate?
>> 
>> No reason I can think of (but I'd probably phrase the proviso
>> differently).  Of course (condition ? x : y) in the example above still
>> wouldn't be an lvalue.
>
> Under the existing rules, it wouldn't be an lvalue, but that the whole
> point of this discussion is how things might behave if the language were
> changed to allow for ternary expressions to yield lvalues.  I'm curious
> how you'd word the proviso.

Some ternary expressions would be lvalues, some would not.  If the
second and third operands are lvalues of the same type, the expression
as a whole would be an lvalue.  If they're of "sufficiently different"
types (whatever that turns out to mean), they're not.

    int a, b;
    int *p = &(cond ? a : b); /* ok */

    int x; double y;
    int *p = &(cond ? x : y); /* invalid, operand of & is not an lvalue */

This is consistent with the behavior of "g++ -std=c++11 -pedantic".

The first thing I'd do is look at how C++ specifies it.  *If* it were
considered worthwhile to add this feature to C, then C++'s
example should be followed unless there's a good reason to do something
different.

I haven't yet bothered to check the C++ standard.  You're welcome to do
so yourself.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101152

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> supercat@casperkitty.com writes:
>>Under the existing rules, it wouldn't be an lvalue, but that the whole
>>point of this discussion is how things might behave if the language were
>>changed to allow for ternary expressions to yield lvalues.
>
>   In C++, it is an lvalue. So you just might check out C++.

The point is that whether it's an lvalue only if the second and third
operands are lvalues *and* have the same type (not just compatible
types).

C++11 5.16 [expr.cond] paragraphs 4 and 5:

    If the second and third operands are glvalues of the same value
    category and have the same type, the result is of that type
    and value category and it is a bit-field if the second or the
    third operand is a bit-field, or if both are bit-fields.

    Otherwise, the result is a prvalue.

I think this could be adapted for C with a few tweaks:

    "glvalues" --> "lvalues"
    "value category" can probably be dropped
    "the result is a prvalue" --> "the expression is not an lvalue"

(Allowing a conditional expression to be an value if the second and
third operands are not of exactly the same type is not, in my opinion,
worth the effort.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101703

Keith Thompson <kst-u@mib.org> writes:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> supercat@casperkitty.com writes:
>>> Under the existing rules, it wouldn't be an lvalue, but that the whole
>>> point of this discussion is how things might behave if the language were
>>> changed to allow for ternary expressions to yield lvalues.
>>
>>   In C++, it is an lvalue.  So you just might check out C++.
>
> The point is that whether it's an lvalue only if the second and third
> operands are lvalues *and* have the same type (not just compatible
> types).

Note that C++ doesn't share C's notion of compatible types (I'm
not sure what C++ does have exactly, but for sure it isn't the
same as C), so the C++ definition doesn't translate as nicely to
C as one would like.  In C I think one would want compatible
types taken into account.

> C++11 5.16 [expr.cond] paragraphs 4 and 5:
>
>     If the second and third operands are glvalues of the same value
>     category and have the same type, the result is of that type
>     and value category and it is a bit-field if the second or the
>     third operand is a bit-field, or if both are bit-fields.
>
>     Otherwise, the result is a prvalue.
>
> I think this could be adapted for C with a few tweaks:
>
>     "glvalues" --> "lvalues"
>     "value category" can probably be dropped
>     "the result is a prvalue" --> "the expression is not an lvalue"
>
> (Allowing a conditional expression to be an value if the second and
> third operands are not of exactly the same type is not, in my opinion,
> worth the effort.)

IMO the whole thing is not worth the effort.  If there is a need
to use a conditional expression in an lvalue context, that is
easily done in C as it is now, with two address-of operators and
a dereference operator.  That gets the compatible type stuff for
free, besides not needing a language extension.  All that's
missing relative to C++ is conditional-expression-lvalues for
bitfield operands.  And IMO is it _way_ not important enough
to add a new language feature just to be able to use bitfields
in conditional-expression-lvalues.

By the way, something that surprised me (assuming I got this
right, which I may not have) is this:

    struct {
        unsigned a: 2;
        unsigned b:15;
    } it;

    // ...

    (some_test() ? it.a : it.b) = 49;

AFAICT this example is legal C++, despite 'it.a' and 'it.b'
having different widths.  And does the value of the assignment
expression depend on whether 'some_test()' is true or false?  In
C, I think it would (assuming of course that C has been augmented
to have conditional lvalues for such cases).

[toc] | [prev] | [next] | [standalone]

#101710

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]

Context: Allowing a conditional epxression to be an value, like
    (cond ? x : y) = 42;

> IMO the whole thing is not worth the effort.

I agree.

> By the way, something that surprised me (assuming I got this
> right, which I may not have) is this:
>
>     struct {
>         unsigned a: 2;
>         unsigned b:15;
>     } it;
>
>     // ...
>
>     (some_test() ? it.a : it.b) = 49;
>
> AFAICT this example is legal C++, despite 'it.a' and 'it.b'
> having different widths.  And does the value of the assignment
> expression depend on whether 'some_test()' is true or false?  In
> C, I think it would (assuming of course that C has been augmented
> to have conditional lvalues for such cases).

It is, and it does, based on a quick experiment with g++ 6.2.

clang++ 3.8.1 complains about the assignment:

    error: cannot compile this conditional operator yet

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#101923

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>
> Context:  Allowing a conditional epxression to be an value, like
>     (cond ? x : y) = 42;
>
>> IMO the whole thing is not worth the effort.
>
> I agree.
>
>> By the way, something that surprised me (assuming I got this
>> right, which I may not have) is this:
>>
>>     struct {
>>         unsigned a: 2;
>>         unsigned b:15;
>>     } it;
>>
>>     // ...
>>
>>     (some_test() ? it.a : it.b) = 49;
>>
>> AFAICT this example is legal C++, despite 'it.a' and 'it.b'
>> having different widths.  And does the value of the assignment
>> expression depend on whether 'some_test()' is true or false?  In
>> C, I think it would (assuming of course that C has been augmented
>> to have conditional lvalues for such cases).
>
> It is, and it does, based on a quick experiment with g++ 6.2.

Thank you, it's good to know my expectation matched how the
language is actually defined.

[toc] | [prev] | [next] | [standalone]

#101701

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

> Manfred <noname@invalid.add> writes:
>
>> On 9/28/2016 1:23 AM, Ben Bacarisse wrote:
>>> I consider special cases to be a sort of intellectual cost.
>>
>> I am 100% with you.
>>
>>>   But my
>>> remark about it being a shame is not intended to be a considered
>>> weighing-up of hard engineering costs but simply a sad observation on
>>> there being yet another exception I would not have expected.  If I did
>>> not know better, I would assume that that any expression that could
>>> reasonably be a lvalue would be an lvalue.
>>
>> Maybe the keyword here is "reasonably", which would point out that
>> what is reasonable for C++ is not for C.
>
> Yes, its a hopelessly woolly word.  Almost as soon as I'd written it I
> thought:  well, that doesn't say much, does it?
>
>> Here the C rationale appears to be "result of expressions are rvalues"
>> i.e. value-oriented, while the C++ rationale appears to be "result of
>> expressions are objects" i.e. more symbol-oriented.
>
> I can't comment on C++'s abstract model because I have not studied the
> standard, but, in C, expressions /evaluate/ to values (we could call
> them rvalues but that's probably unnecessary and the standard doesn't),
> whereas some syntactic forms of expression /are/ lvalues.  So you are
> right that there is no kind of "value" (in C's abstract semantics) that
> could be used to denote objects.  lvalues are simply expressions, not
> values, despite the name.
>
> But I don't think that gets us any closer to knowing what might or might
> not be "reasonable" in C.  The C standard enumerates all the expression
> forms that are lvalues and, as in the case of x.y for example, it
> sometimes depends on whether one or other part of the expression is
> itself an lvalue.  So there's no obvious reason that it could not say
> that a conditional expression is an lvalue if both arms are lvalue
> expressions.

For what it's worth (and I know it may not be much), the current
choices in C make sense to me intuitively because I think of
"lvalue" as meaning roughly the same thing as "address".  (Note:
in the sense of a machine address, not in the sense of C's &
operator.)  All of C's lvalue expressions identify a particular
object, and the "lvalue" of that expression is the "address" of
the object.  Moreover there is a sense in which that is all they
do, is to identify a single object.  Compound literals might seem
like an exception to that;  I don't see them that way, probably
because I think of a compound literal as a declarationless
variable, and variables are of course lvalues.

Seen from this perspective, a conditional expression would stand
out because there is (potentially) more than one object, and
there is more to the operator than just identifying an object.
Of course conditional expressions could be used to construct
lvalues, but that construction doesn't fit with my (admittedly
historical) view of what "lvalue" means.

To be clear, I don't mean to offer any sort of philosophical
truth here.  I am just explaining my own views and reactions, in
case doing that might help someone form a useful mental model
for C's current choices.

[toc] | [prev] | [next] | [standalone]

#101714

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Manfred <noname@invalid.add> writes:
>>
>>> On 9/28/2016 1:23 AM, Ben Bacarisse wrote:
>>>> I consider special cases to be a sort of intellectual cost.
>>>
>>> I am 100% with you.
>>>
>>>>   But my
>>>> remark about it being a shame is not intended to be a considered
>>>> weighing-up of hard engineering costs but simply a sad observation on
>>>> there being yet another exception I would not have expected.  If I did
>>>> not know better, I would assume that that any expression that could
>>>> reasonably be a lvalue would be an lvalue.
>>>
>>> Maybe the keyword here is "reasonably", which would point out that
>>> what is reasonable for C++ is not for C.
>>
>> Yes, its a hopelessly woolly word.  Almost as soon as I'd written it I
>> thought:  well, that doesn't say much, does it?
>>
>>> Here the C rationale appears to be "result of expressions are rvalues"
>>> i.e. value-oriented, while the C++ rationale appears to be "result of
>>> expressions are objects" i.e. more symbol-oriented.
>>
>> I can't comment on C++'s abstract model because I have not studied the
>> standard, but, in C, expressions /evaluate/ to values (we could call
>> them rvalues but that's probably unnecessary and the standard doesn't),
>> whereas some syntactic forms of expression /are/ lvalues.  So you are
>> right that there is no kind of "value" (in C's abstract semantics) that
>> could be used to denote objects.  lvalues are simply expressions, not
>> values, despite the name.
>>
>> But I don't think that gets us any closer to knowing what might or might
>> not be "reasonable" in C.  The C standard enumerates all the expression
>> forms that are lvalues and, as in the case of x.y for example, it
>> sometimes depends on whether one or other part of the expression is
>> itself an lvalue.  So there's no obvious reason that it could not say
>> that a conditional expression is an lvalue if both arms are lvalue
>> expressions.
>
> For what it's worth (and I know it may not be much), the current
> choices in C make sense to me intuitively because I think of
> "lvalue" as meaning roughly the same thing as "address".  (Note:
> in the sense of a machine address, not in the sense of C's &
> operator.)  All of C's lvalue expressions identify a particular
> object, and the "lvalue" of that expression is the "address" of
> the object.

A bit-field member of a lvalue is an lvalue and need have no machine
address in any literal sense.  But I know what you mean -- lvalues are
location designators.

> Moreover there is a sense in which that is all they
> do, is to identify a single object.  Compound literals might seem
> like an exception to that;  I don't see them that way, probably
> because I think of a compound literal as a declarationless
> variable, and variables are of course lvalues.
>
> Seen from this perspective, a conditional expression would stand
> out because there is (potentially) more than one object, and
> there is more to the operator than just identifying an object.

A half-way house between your view and mine would have the comma
operator be an lvalue expression if the second part of it were one.
Here there is only one object and there is not much more to the operator
than there might be in other complex lvalue expressions.  It would be a
close analogue to the fact the (E) is a lvalue is E is one.

I'm tempted to point to _Generic expressions as a precedent sine
multiple objects may be involved, but the expression is doing nothing
more but a type-based, compile-time selection of a location so it's not
directly analogous.

> Of course conditional expressions could be used to construct
> lvalues, but that construction doesn't fit with my (admittedly
> historical) view of what "lvalue" means.

Yes, that was my view too, but then I learned Algol 68 and no one is
ever quite the same after Algol 68.

But, all in all, I think you are right that C's current choices are both
simple and intuitive to anyone with a sound picture of what a typical
computer is doing.  What's happened to me is that my view of what a
programming language should be has become more and more abstract so what
might be going on in terms of addresses matters less and less with every
passing decade.

> To be clear, I don't mean to offer any sort of philosophical
> truth here.  I am just explaining my own views and reactions, in
> case doing that might help someone form a useful mental model
> for C's current choices.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101922

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Manfred <noname@invalid.add> writes:
>>>
>>>> On 9/28/2016 1:23 AM, Ben Bacarisse wrote:

[cutting out most of the first part, hopefully not too much]

>> For what it's worth (and I know it may not be much), the current
>> choices in C make sense to me intuitively because I think of
>> "lvalue" as meaning roughly the same thing as "address". [...]
>> Seen from this perspective, a conditional expression would stand
>> out because there is (potentially) more than one object, and
>> there is more to the operator than just identifying an object.
>
> A half-way house between your view and mine would have the comma
> operator be an lvalue expression if the second part of it were one.
> [...]

Interesting example.  A bit later I will expand on the word
"view".

>> Of course conditional expressions could be used to construct
>> lvalues, but that construction doesn't fit with my (admittedly
>> historical) view of what "lvalue" means.
>
> Yes, that was my view too, but then I learned Algol 68 and no one
> is ever quite the same after Algol 68.
>
> But, all in all, I think you are right that C's current choices
> are both simple and intuitive to anyone with a sound picture of
> what a typical computer is doing.  What's happened to me is that
> my view of what a programming language should be has become more
> and more abstract so what might be going on in terms of addresses
> matters less and less with every passing decade.

I found your comments quite interesting, especially the later
ones.  Although I did have some exposure to Algol 68, I can't say
I ever learned the language, only bits and pieces, so I didn't
experience the sort of transformation due to Algol 68 that
you did.

I want to say something about the word "view".  Even though I
didn't ever /learn/ Algol 68, I am familiar enough with its
underlying principles to say I feel comfortable being in that
space.  However, when I make comments about "lvalues" in C, my
comments are less about what programming languages should be
like than they are about what the word "lvalue" presumably
connotes in that context.  For me the word itself has a certain
amount of historical force.  It isn't a coincidence that a lot
of that historical force carries over into C, since the term and
the language more or less grew up together;  and if C gave that
up to move more in the direction of Algol 68 then C would become
a fairly different language.  So I think our views may not be
that different from each other.  That hasn't been evident in our
discussion largely because I'm presuming the character of C is
going to (or should) stay relatively fixed, whereas your
reactions reflect a perception from a loftier place.  I don't
know that I really have a point here, I just thought the
contrasts were interesting.

[toc] | [prev] | [next] | [standalone]

#102023

On Friday, January 13, 2017 at 7:09:00 PM UTC-6, Tim Rentsch wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
> > Manfred <noname@invalid.add> writes:
> >

> >> Here the C rationale appears to be "result of expressions are rvalues"
> >> i.e. value-oriented, while the C++ rationale appears to be "result of
> >> expressions are objects" i.e. more symbol-oriented.
> >
> > I can't comment on C++'s abstract model because I have not studied the
> > standard, but, in C, expressions /evaluate/ to values (we could call
> > them rvalues but that's probably unnecessary and the standard doesn't),
> > whereas some syntactic forms of expression /are/ lvalues.  So you are
> > right that there is no kind of "value" (in C's abstract semantics) that
> > could be used to denote objects.  lvalues are simply expressions, not
> > values, despite the name.
> >
> > But I don't think that gets us any closer to knowing what might or might
> > not be "reasonable" in C.  The C standard enumerates all the expression
> > forms that are lvalues and, as in the case of x.y for example, it
> > sometimes depends on whether one or other part of the expression is
> > itself an lvalue.  So there's no obvious reason that it could not say
> > that a conditional expression is an lvalue if both arms are lvalue
> > expressions.
> 
> For what it's worth (and I know it may not be much), the current
> choices in C make sense to me intuitively because I think of
> "lvalue" as meaning roughly the same thing as "address".  (Note:
> in the sense of a machine address, not in the sense of C's &
> operator.)  All of C's lvalue expressions identify a particular
> object, and the "lvalue" of that expression is the "address" of
> the object.  Moreover there is a sense in which that is all they
> do, is to identify a single object.  Compound literals might seem
> like an exception to that;  I don't see them that way, probably
> because I think of a compound literal as a declarationless
> variable, and variables are of course lvalues.
> 
> Seen from this perspective, a conditional expression would stand
> out because there is (potentially) more than one object, and
> there is more to the operator than just identifying an object.
> Of course conditional expressions could be used to construct
> lvalues, but that construction doesn't fit with my (admittedly
> historical) view of what "lvalue" means.
> 
> To be clear, I don't mean to offer any sort of philosophical
> truth here.  I am just explaining my own views and reactions, in
> case doing that might help someone form a useful mental model
> for C's current choices.

FWIW, my conception of an lvalue is slightly different. To me it
is "a thing which can be on the left of an assignment operator". 
I suppose this is more of a "functional" definition. In the 
implementation I know it's an address, but it's also in a sense
the object itself *in situ* since the same form will evaluate
to the value therefrom in any context requiring a value.

-- 
FCVO "thing"

[toc] | [prev] | [next] | [standalone]

#102123

On 1/17/2017 8:09 AM, luser droog wrote:
> FWIW, my conception of an lvalue is slightly different. To me it
> is "a thing which can be on the left of an assignment operator".
This is the same definition that appeared in Dennis Ritchie's "C 
Reference Manual" from Bell Labs.

[toc] | [prev] | [next] | [standalone]

#102137

Manfred <noname@invalid.add> writes:
> On 1/17/2017 8:09 AM, luser droog wrote:
>> FWIW, my conception of an lvalue is slightly different. To me it
>> is "a thing which can be on the left of an assignment operator".
> This is the same definition that appeared in Dennis Ritchie's "C 
> Reference Manual" from Bell Labs.

That is of course an incomplete definition.  There are plenty of
lvalues that can't appear on the LHS of an assignment, including
array names and names of const-qualified objects.  Nevertheless that
is the origin of the "L" in "lvalue", and it's a good mnemonic.

BTW, the 1974 and 1975 editions of the C Reference Manual both say:

    An object is a manipulatable region of storage; an lvalue is an
    expression referring to an object. An obvious example of an lvalue
    expression is an identifier.

I'll check K&R1 later today.

The C90, C99, and C11 standards all have different definitions of
"lvalue", and the C90 and C99 definitions are incorrect.  (It's
difficult for a definition to be incorrect, but they managed.)
The C90 definition implies that *ptr may or may not be an lvalue
(a compile-time concept) depending on the run-time value of ptr.
The C99 definition implies that 42 is an lvalue, and that evaluating
it has undefined behavior.  Obviously neither of these expressed
the intent.

In the original meaning, apparently from CPL (one of C's distant
ancestors), an lvalue was a kind of value, resulting from evaluating
an expression in a certain way.  In C, an lvalue is not a value
but a kind of expression.

I've discussed this at greater length here:
https://github.com/Keith-S-Thompson/the-flat-trantor-society/blob/master/005-c-standard-quibbles.md#what-is-an-lvalue
or if the long URL is a problem:
https://goo.gl/SwL2eK

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web