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

Groups > comp.std.c > #1785

Re: Description of "." operator

Show all headers | View raw

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> N1570 6.5.2.3p3 says:
>>
>>     A postfix expression followed by the . operator and an identifier
>>     designates a member of a structure or union object. The value
>>     is that of the named member, and is an lvalue if the first
>>     expression is an lvalue.
>>
>> Consider the use of the word "object" in the first sentence.
>>
>> An expression of struct type doesn't necessarily refer to an *object* of
>> that type.  For example:
>>
>>     struct pair { int x; int y; };
>>     struct pair func(void) {
>>         struct pair result = { 10, 20 };
>>         return result;
>>     }
>>     ...
>>     int y = func().y;
>>
>> And the second quoted sentence seems to explictly acknowledge that the
>> left operand needn't refer to an object.
>>
>> Shouln't the phrase "a member of a structure or union object" be "a
>> member of a structure or union *value*"?
>>
>> If not, in the example code above, what object is being referred to?
>> ("result" no longer exists after the function returns.)
>
> I agree the point should be addressed, but I think the problem is
> more fundamental than just this operator.  Consider the very
> definition of the types, eg,
>
>     A /structure type/ describes a sequentially allocated nonempty
>     set of member objects, ...
>
> Kind of implies that struct's exist only as objects, doesn't it?
>
> A better solution, I think, is for all expressions with struct or
> union type, or at least those that aren't produced directly from
> lvalue conversion, be objects with temporary lifetime in the same
> way that ones with array members are.  Surely that corresponds to
> the behavior (at least abstractly) that most people expect, eg,
> with struct-returning functions -- right?  And of course this
> wouldn't have to result in storage being reserved during actual
> execution, because of the abstract machine principles and the
> as if rule, so what's the downside?  ISTM the end result would
> be smaller, simpler, and more consistent than what there is now.
> Am I missing something?

That's one way to approach it; the only way to have a struct value would
be for it to be the value of some object.

But I'd prefer to recognize that struct values can exist even in the
absence of any object.

Structs can be passed as function arguments, returned as function
results, and assigned, very much like scalars.  This function:

    int answer(void) { return 42; }

doesn't create an object of type int; why then should this function:

    struct foo func(void) { struct foo result; return result; }

create a struct foo object that exists after the function has
returned?

On the other hand, compound literals are specified to refer to
anonymous objects rather than just yielding values, so I suspect
the committee would agree with you more than with me.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-07 18:34 -0800
  Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-08 10:43 -0800
    Re: Description of "." operator Jens Gustedt <jens.gustedt@loria.fr> - 2012-12-10 00:35 +0100
      Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-09 20:02 -0800
  Re: Description of "." operator jgk@panix.com (Joe keane) - 2012-12-09 23:34 +0000
    Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-09 20:00 -0800
  Re: Description of "." operator Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 23:32 -0800
    Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2012-12-21 02:08 -0800
      Re: Description of "." operator Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-21 09:18 -0500
        Re: Description of "." operator Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 08:45 -0800
      Re: Description of "." operator Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 08:37 -0800
  Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-06 01:23 -0500
    Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2013-01-05 23:51 -0800
      Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-06 13:49 -0500
        Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2013-01-06 22:12 -0800
          Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-17 23:19 -0500
            Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-18 20:47 -0500
              Re: Description of "." operator Keith Thompson <kst-u@mib.org> - 2013-01-18 20:14 -0800
              Re: Description of "." operator jgk@panix.com (Joe keane) - 2013-01-20 20:07 +0000
                Re: Description of "." operator Shao Miller <sha0.miller@gmail.com> - 2013-01-20 15:36 -0500

csiph-web