Re: Size of an arraylist in bytes

Discussion in 'C Programming' started by Stefan Ram, Nov 21, 2011.

  1. Stefan Ram

    Stefan Ram Guest

    Newsgroups: comp.lang.java.programmer,comp.lang.c
    Followup-To: comp.lang.c

    Patricia Shanahan <> writes:
    >My main concern with C's pointers is that they were called "pointers",
    >not "addresses". They behave far more like assembly language addresses
    >than like something more abstract, whose only job is to point.


    An important difference between address arithmetics
    and pointer arithmetics can be seen here:

    #include <stdio.h>

    int addressdiff( void const * const b, void const * const a )
    { return( char const * const )b -( char const * const )a; }

    int main( void )
    { char address[ 2 ];
    int pointer[ 2 ];
    printf( "%d\n", addressdiff( address + 1, address ));
    printf( "%d\n", addressdiff( pointer + 1, pointer )); }

    1
    4

    Newsgroups: comp.lang.java.programmer,comp.lang.c
    Followup-To: comp.lang.c
    Stefan Ram, Nov 21, 2011
    #1
    1. Advertising

  2. Stefan Ram

    Stefan Ram Guest

    Pointers (was: Size of an arraylist in bytes)

    Joe Wright <> writes:
    >A pointer is a variable object in storage which can hold the address of
    >another object in storage. The address is a value, the pointer is an object.


    You might read this from:

    »A pointer type describes an object whose value provides
    a reference to an entity of the referenced type.« (p20)

    ISO/IEC 9899:1999 (E), 6.2.5, #20

    . But p20 must be wrong, because, for example:

    ( char * )0

    does have a pointer type, but does not describe an object,
    and

    ""

    does have a pointer type, but its value is not an object
    whose value provides a reference to char, but instead is
    directly a reference to char itself.

    So, one should best ignore p20 in this regard.

    ISO/IEC 9899:1999 (E) is more sane in footnote 53:

    »As a further example, if E is a unary expression
    that is a pointer to an object, *E is an lvalue that
    designates the object to which E points.«,

    which allows E to be any unary expression, not just an
    expression designating an object whose value provides a
    reference.

    »Otherwise, the result [of &] is a pointer to the
    object or function designated by its operand.« 6.5.3.2p3

    Thus, in »{ int v; &v; }«, the value of »&v« is a pointer.
    But this value clearly is not »a variable object in storage
    which can hold the address of another object in storage«.

    This, again, shows that p20 and some similar uses must
    be changed in ISO/IEC 9899:1999 (E) to get a consistent
    use of the word »pointer«.

    >A pointer is an object. A function cannot return an object. Consider..


    >char *strcat(char *d, char *s);


    >..does not return a pointer, but an address of (char*) type.


    But »char *« /is/ a pointer type, which again shows that p20
    is wrong.
    Stefan Ram, Nov 21, 2011
    #2
    1. Advertising

  3. Joe Wright <> writes:
    [...]
    > A pointer is a variable object in storage which can hold the address of
    > another object in storage. The address is a value, the pointer is an object.
    >
    > This concept is too complicated (or too simple) to some of my old friends
    > but it works for me. Keith Thompson beat me into semi-submission several
    > years ago until I got too tired to play. But here I am again.
    >
    > A pointer is an object. A function cannot return an object. Consider..
    >
    > char *strcat(char *d, char *s);
    >
    > ..does not return a pointer, but an address of (char*) type.


    That's an entirely consistent and sensible way to look at it.

    Unfortunately, it's entirely inconsistent with the way standard uses the
    word "pointer". See for example, C99 7.20.3.3p3:

    The malloc function returns either a null pointer or a pointer to
    the allocated space.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 21, 2011
    #3
  4. Stefan Ram

    Ark Guest

    On 11/21/2011 5:45 PM, pete wrote:
    > Keith Thompson wrote:
    >>
    >> Joe Wright<> writes:
    >> [...]
    >>> A pointer is a variable object in storage which can hold the address of
    >>> another object in storage. The address is a value, the pointer is an object.
    >>>
    >>> This concept is too complicated (or too simple) to some of my old friends
    >>> but it works for me. Keith Thompson beat me into semi-submission several
    >>> years ago until I got too tired to play. But here I am again.
    >>>
    >>> A pointer is an object. A function cannot return an object. Consider..
    >>>
    >>> char *strcat(char *d, char *s);
    >>>
    >>> ..does not return a pointer, but an address of (char*) type.

    >>
    >> That's an entirely consistent and sensible way to look at it.
    >>
    >> Unfortunately,
    >> it's entirely inconsistent with the way standard uses the
    >> word "pointer". See for example, C99 7.20.3.3p3:
    >>
    >> The malloc function returns either a null pointer or a pointer to
    >> the allocated space.

    >
    > A null pointer constant, may be converted to null pointer.
    >
    > I refer to any expression of any type,
    > as an instance of that type.
    >
    > (0.0) is a double.
    >

    I wonder if an expression (i.e. a critter with a type and a value) is in
    some sense "an instance". Is there any point in distinguishing an
    instance and an object? If so, what is it?
    Ark, Nov 22, 2011
    #4
  5. Stefan Ram

    Stefan Ram Guest

    an instance of an object (was: Size of an arraylist in bytes)

    Ark <> writes:
    >I wonder if an expression (i.e. a critter with a type and a value)


    An expression has a type, but generally not always specific value.
    An /evaluation/ of an expression yields a value (unless the type
    of the expression is »void«).

    For example, what is the value of the expression »x«?
    This cannot be answered generally. However, a specific evaluation
    of this expression might yield a value. Think of

    void( int x ){ return x; }

    >is in some sense "an instance".


    An expression is never an instance of an object, because an
    instance of an object is a part of the run-time model, while
    an expression is part of the source-code model.

    Also, one needs to be more precise: ISO/IEC 9899:1999 (E)
    knows instances

    - of objects
    - of structs
    - of macro names
    - of preprocessing tokens
    - ...

    Personally, I consider »instance of an object« to be just
    a redundant wording for »object«.

    >Is there any point in distinguishing an
    >instance and an object? If so, what is it?


    Well, ISO/IEC 9899:1999 (E) says:

    »If [a] block is entered recursively, a new
    instance of the object is created each time.«

    But I would prefer another wording, like

    »When a block is entered recursively, a new
    object is created each time.« (for each automatic
    variable)

    But, in this case, one must not identify objects
    with addresses. For example:

    void f( int const x ){} ... f( 1 ); f( 2 );

    There are clearly two instances of the parameter x,
    but they might share the same address since their
    lifetimes do not overlap. So, one might say it was
    »the same object« (the address and type is the same),
    but that there were »two instances of that object«.

    But to me, conceptually, there are two different
    objects, and when they share the same address, this
    is just a meaningless implementation detail.
    Stefan Ram, Nov 22, 2011
    #5
  6. Stefan Ram

    Eric Sosman Guest

    On 11/21/2011 9:19 PM, Ark wrote:
    >
    > I wonder if an expression (i.e. a critter with a type and a value) is in
    > some sense "an instance". Is there any point in distinguishing an
    > instance and an object? If so, what is it?


    The Standard doesn't use "instance" this way, or not much. There's
    6.2.4p6 "a new instance of the object is created," and 6.7.5.2p5 "each
    instance of a variable length array type," but those are the only two
    "instance" usages I can find that seem connected to "object."

    "Object," on the other hand, is used quite frequently, and is even
    given a definition in 3.14p1: An object is a "region of data storage in
    the execution environment, the contents of which can represent values."
    (You'll note that objects can store values, but it does not follow that
    all values belong to objects: Where is the "one" in "x++"?)

    So: "Object" is formal and defined, while "instance" seems to be an
    informal, undefined term used (in this connection) as amplification or
    explanation. In other words, "instance" is pretty much whatever you
    understand it to be, and any distinction between "instance" and
    "object" is mostly of your own choosing.

    --
    Eric Sosman
    d
    Eric Sosman, Nov 22, 2011
    #6
  7. Re: an instance of an object (was: Size of an arraylist in bytes)

    -berlin.de (Stefan Ram) writes:
    [...]
    > But, in this case, one must not identify objects
    > with addresses. For example:
    >
    > void f( int const x ){} ... f( 1 ); f( 2 );
    >
    > There are clearly two instances of the parameter x,
    > but they might share the same address since their
    > lifetimes do not overlap. So, one might say it was
    > »the same object« (the address and type is the same),
    > but that there were »two instances of that object«.
    >
    > But to me, conceptually, there are two different
    > objects, and when they share the same address, this
    > is just a meaningless implementation detail.


    They may or may not have the same machine address. It's not
    meaningful to ask whether they have the same address in the sense of
    a C pointer value. A portable program cannot compare the addresses
    of the two "x"s. You could save the address of x in the first call
    in a global variable, but that variable's value becomes indeterminate
    as soon as x goes out of scope.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 22, 2011
    #7
  8. Stefan Ram

    Ark Guest

    On 11/21/2011 10:06 PM, Eric Sosman wrote:
    > On 11/21/2011 9:19 PM, Ark wrote:
    >>
    >> I wonder if an expression (i.e. a critter with a type and a value) is in
    >> some sense "an instance". Is there any point in distinguishing an
    >> instance and an object? If so, what is it?

    >
    > The Standard doesn't use "instance" this way, or not much. There's
    > 6.2.4p6 "a new instance of the object is created," and 6.7.5.2p5 "each
    > instance of a variable length array type," but those are the only two
    > "instance" usages I can find that seem connected to "object."
    >
    > "Object," on the other hand, is used quite frequently, and is even
    > given a definition in 3.14p1: An object is a "region of data storage in
    > the execution environment, the contents of which can represent values."
    > (You'll note that objects can store values, but it does not follow that
    > all values belong to objects: Where is the "one" in "x++"?)
    >
    > So: "Object" is formal and defined, while "instance" seems to be an
    > informal, undefined term used (in this connection) as amplification or
    > explanation. In other words, "instance" is pretty much whatever you
    > understand it to be, and any distinction between "instance" and
    > "object" is mostly of your own choosing.
    >

    Thanks, Eric. IOW, in everyday usage of the word "instance", we can say
    that an object is an instance of a type, as in "an embodiment of a
    type". As to 6.2.4p6 "a new instance of the object is created," I don't
    know what to make of it: the one and the only instance of an object is
    the object itself, isn't it?
    OTOH, "instance" can be used in the sense of "encounter in the text" as
    it is obviously used elsewhere e.g. w.r.t. macros.
    --
    Ark
    Ark, Nov 22, 2011
    #8
  9. On Nov 21, 9:25 pm, Joe Wright <> wrote:
    > On 11/21/2011 15:06, Stefan Ram wrote:
    >
    >
    >
    > > Newsgroups: comp.lang.java.programmer,comp.lang.c
    > > Followup-To: comp.lang.c

    >
    > > Patricia Shanahan<>  writes:
    > >> My main concern with C's pointers is that they were called "pointers",
    > >> not "addresses". They behave far more like assembly language addresses
    > >> than like something more abstract, whose only job is to point.

    >
    > >    An important difference between address arithmetics
    > >    and pointer arithmetics can be seen here:

    >
    > > #include<stdio.h>

    >
    > > int addressdiff( void const * const b, void const * const a )
    > > { return( char const * const )b -( char const * const )a; }

    >
    > > int main( void )
    > > { char address[ 2 ];
    > >    int  pointer[ 2 ];
    > >    printf( "%d\n", addressdiff( address + 1, address ));
    > >    printf( "%d\n", addressdiff( pointer + 1, pointer )); }

    >
    > > 1
    > > 4

    >
    > > Newsgroups: comp.lang.java.programmer,comp.lang.c
    > > Followup-To: comp.lang.c

    >
    > A pointer is a variable object in storage which can hold the address of
    > another object in storage. The address is a value, the pointer is an object.
    >
    > This concept is too complicated (or too simple) to some of my old friends
    > but it works for me. Keith Thompson beat me into semi-submission several
    > years ago until I got too tired to play. But here I am again.
    >
    > A pointer is an object. A function cannot return an object.


    surely this happens all the time

    struct point
    {
    int x;
    int y;
    };

    struct point make_point (int a, int b)
    { struct point p; p.x = a; p.y = b; return p; }

    isn't that returning an object? In fact doesn't this return an object?

    int f (void) { return 1; }



    Consider..
    >
    > char *strcat(char *d, char *s);
    >
    > ..does not return a pointer, but an address of (char*) type.
    >
    > --
    > Joe Wright
    > "If you rob Peter to pay Paul you can depend on the support of Paul."- Hide quoted text -
    >
    > - Show quoted text -
    Nick Keighley, Nov 22, 2011
    #9
  10. Stefan Ram

    Ark Guest

    On 11/22/2011 1:49 AM, pete wrote:
    > Ark wrote:
    >>
    >> On 11/21/2011 5:45 PM, pete wrote:

    >
    >>> A null pointer constant, may be converted to null pointer.
    >>>
    >>> I refer to any expression of any type,
    >>> as an instance of that type.
    >>>
    >>> (0.0) is a double.
    >>>

    >> I wonder if an expression
    >> (i.e. a critter with a type and a value) is in
    >> some sense "an instance".
    >> Is there any point in distinguishing an
    >> instance and an object? If so, what is it?

    >
    > The assignment expression statement
    > a = 0;
    > implies that there is an object named (a)
    > and that after the assignment
    > that (a) will have a value of (0).
    >
    > The assignment expression (a = 0)
    > does *not* imply that prior to the assignment
    > that there is a region of storage with a value of (0)
    > waiting to be loaded and moved into (a).
    >

    Is it so? I believe that in C abstract machine, object a exists in the
    block it is declared whether it is assigned to or not. Think of
    "volatile int a;"
    --
    Ark
    Ark, Nov 22, 2011
    #10
  11. Nick Keighley <> writes:
    > On Nov 21, 9:25 pm, Joe Wright <> wrote:
    >> On 11/21/2011 15:06, Stefan Ram wrote:

    [...]
    >> A pointer is a variable object in storage which can hold the address of
    >> another object in storage. The address is a value, the pointer is an object.
    >>
    >> This concept is too complicated (or too simple) to some of my old friends
    >> but it works for me. Keith Thompson beat me into semi-submission several
    >> years ago until I got too tired to play. But here I am again.
    >>
    >> A pointer is an object. A function cannot return an object.

    >
    > surely this happens all the time
    >
    > struct point
    > {
    > int x;
    > int y;
    > };
    >
    > struct point make_point (int a, int b)
    > { struct point p; p.x = a; p.y = b; return p; }
    >
    > isn't that returning an object? In fact doesn't this return an object?
    >
    > int f (void) { return 1; }


    I'd say no. In both cases, the function returns a value, not an
    object. (There might be a "region of data storage" (from C99 3.14,
    the definition of "object") that's allocated to hold the value, but
    logically what the function returns is the value, not the object.)

    The value returned by a call to

    int f (void) { return 1; }

    is no more an object than the evaluation of the RHS of

    n = 1;

    results in an object. In particular, objects generally have
    addresses; function results don't.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 22, 2011
    #11
  12. Ark <> writes:
    > On 11/22/2011 1:49 AM, pete wrote:

    [...]
    >> The assignment expression statement
    >> a = 0;
    >> implies that there is an object named (a)
    >> and that after the assignment
    >> that (a) will have a value of (0).
    >>
    >> The assignment expression (a = 0)
    >> does *not* imply that prior to the assignment
    >> that there is a region of storage with a value of (0)
    >> waiting to be loaded and moved into (a).
    >>

    > Is it so? I believe that in C abstract machine, object a exists in the
    > block it is declared whether it is assigned to or not. Think of
    > "volatile int a;"


    Certainly the object "a" exists. The question is whether the
    expression "0" implies the existence of an object (of type int,
    holding the value 0) whose contents are copied into the object "a"
    by the assignment. (And the answer is no.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 22, 2011
    #12
  13. Stefan Ram

    James Kuyper Guest

    On 11/22/2011 03:07 AM, Ark wrote:
    ....
    > Thanks, Eric. IOW, in everyday usage of the word "instance", we can say
    > that an object is an instance of a type, as in "an embodiment of a
    > type". As to 6.2.4p6 "a new instance of the object is created," I don't
    > know what to make of it: the one and the only instance of an object is
    > the object itself, isn't it?


    I know what I make of that sentence; that the same object identifier in
    the same scope can refer to a different location in memory each time
    that execution passes through a given scope (including passages that
    occur in recursive calls of the same function - in which case "can"
    changes to "must"), but it must continue referring to that location for
    the entire time that execution of the program is passing through that
    scope. These are considered to be different instances of the same object
    during different passes through the scope, even if they happen to reside
    in the same location in memory.

    I'm fairly certain that this is what the writers of the standard meant
    by that section; whether the definition of "object" allows it to be
    interpreted that way is open to question. It might have been clearer to
    describe them as different objects identified by the same identifier,
    rather than as different instances of the same object.
    --
    James Kuyper
    James Kuyper, Nov 22, 2011
    #13
  14. Stefan Ram

    Stefan Ram Guest

    pete <> writes:
    >The assignment expression statement
    > a = 0;
    >implies that there is an object named (a)


    A statement is an entity. »There is an object«
    is a proposition. An entity cannot imply a proposition.
    (Only a proposition can imply a proposition.)

    Moreover, in

    void f( void ){ int a; a = 0; } int main( void ){}

    , there is the statement »a = 0;«, but there is
    no object named »a« during the execution. In

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

    , there also is no object if that program never
    happens to be executed. Or, if this program is
    executed four times in parallel, there will be
    four objects named »a« at the same time.

    Now let's look at

    int main( void ){ int a; a = 0; ++a; ++a; printf( "%d\n", a ); }

    . I, as an entity that knows ISO/IEC 9899:1999 (E),
    can choose to execute this program using my brain and
    eventually arrive at saying »2«, i.e., giving the
    correct output. But was there ever an object »a« during
    this execution? After all, ISO/IEC 9899:1999 (E) only
    requires »as-if semantics«.

    Statements are part of the source-code model,
    objects are part of the run-time model. The relationship
    between these two is more complicated than one-to-one.

    In the run-time model also, objects do not have names.
    (Try to print the name of a variable with C.) The name
    of a variable is part of the source-code. So, at run-time,
    there cannot be »an object named "a"«. But at other times,
    there is no object at all.
    Stefan Ram, Nov 22, 2011
    #14
  15. Stefan Ram

    Kaz Kylheku Guest

    On 2011-11-22, Stefan Ram <-berlin.de> wrote:
    > int main( void ){ int a; a = 0; ++a; ++a; printf( "%d\n", a ); }
    >
    > . I, as an entity that knows ISO/IEC 9899:1999 (E),
    > can choose to execute this program using my brain and
    > eventually arrive at saying »2«, i.e., giving the
    > correct output. But was there ever an object »a« during
    > this execution? After all, ISO/IEC 9899:1999 (E) only
    > requires »as-if semantics«.


    The contrast between this sort of erudite discussion and its background (the C
    language) is quite comical.
    Kaz Kylheku, Nov 22, 2011
    #15
  16. Stefan Ram

    Stefan Ram Guest

    Kaz Kylheku <> writes:
    >On 2011-11-22, Stefan Ram <-berlin.de> wrote:
    >>int main( void ){ int a; a = 0; ++a; ++a; printf( "%d\n", a ); }
    >>. I, as an entity that knows ISO/IEC 9899:1999 (E),
    >>can choose to execute this program using my brain and
    >>eventually arrive at saying »2«, i.e., giving the
    >>correct output. But was there ever an object »a« during
    >>this execution? After all, ISO/IEC 9899:1999 (E) only
    >>requires »as-if semantics«.

    >The contrast between this sort of erudite discussion and its background (the C
    >language) is quite comical.


    I, as an entity that knows ISO/IEC 9899:1999 (E), should
    have preceded the program with: »#include <stdio.h>«.
    Stefan Ram, Nov 22, 2011
    #16
  17. Stefan Ram

    Arne Vajhøj Guest

    On 11/21/2011 3:06 PM, Stefan Ram wrote:
    > Patricia Shanahan<> writes:
    >> My main concern with C's pointers is that they were called "pointers",
    >> not "addresses". They behave far more like assembly language addresses
    >> than like something more abstract, whose only job is to point.

    >
    > An important difference between address arithmetics
    > and pointer arithmetics can be seen here:
    >
    > #include<stdio.h>
    >
    > int addressdiff( void const * const b, void const * const a )
    > { return( char const * const )b -( char const * const )a; }
    >
    > int main( void )
    > { char address[ 2 ];
    > int pointer[ 2 ];
    > printf( "%d\n", addressdiff( address + 1, address ));
    > printf( "%d\n", addressdiff( pointer + 1, pointer )); }
    >
    > 1
    > 4


    more like != completely like

    Arne
    Arne Vajhøj, Nov 26, 2011
    #17
  18. Stefan Ram

    Tim Rentsch Guest

    Nick Keighley <> writes:

    > On Nov 21, 9:25 pm, Joe Wright <> wrote:
    >> On 11/21/2011 15:06, Stefan Ram wrote:
    >>
    >>
    >>
    >> > Newsgroups: comp.lang.java.programmer,comp.lang.c
    >> > Followup-To: comp.lang.c

    >>
    >> > Patricia Shanahan<> writes:
    >> >> My main concern with C's pointers is that they were called "pointers",
    >> >> not "addresses". They behave far more like assembly language addresses
    >> >> than like something more abstract, whose only job is to point.

    >>
    >> > An important difference between address arithmetics
    >> > and pointer arithmetics can be seen here:

    >>
    >> > #include<stdio.h>

    >>
    >> > int addressdiff( void const * const b, void const * const a )
    >> > { return( char const * const )b -( char const * const )a; }

    >>
    >> > int main( void )
    >> > { char address[ 2 ];
    >> > int pointer[ 2 ];
    >> > printf( "%d\n", addressdiff( address + 1, address ));
    >> > printf( "%d\n", addressdiff( pointer + 1, pointer )); }

    >>
    >> > 1
    >> > 4

    >>
    >> > Newsgroups: comp.lang.java.programmer,comp.lang.c
    >> > Followup-To: comp.lang.c

    >>
    >> A pointer is a variable object in storage which can hold the address of
    >> another object in storage. The address is a value, the pointer is an object.
    >>
    >> This concept is too complicated (or too simple) to some of my old friends
    >> but it works for me. Keith Thompson beat me into semi-submission several
    >> years ago until I got too tired to play. But here I am again.
    >>
    >> A pointer is an object. A function cannot return an object.

    >
    > surely this happens all the time
    >
    > struct point
    > {
    > int x;
    > int y;
    > };
    >
    > struct point make_point (int a, int b)
    > { struct point p; p.x = a; p.y = b; return p; }
    >
    > isn't that returning an object? In fact doesn't this return an object?
    > [snip]


    It does, as 6.2.4 p8 in N1548 makes clear.

    Presumably the same was true in C99, just not explained as
    clearly (nor as extensively with regard to storage duration).
    Tim Rentsch, Jan 25, 2012
    #18
  19. Stefan Ram

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Nick Keighley <> writes:
    >> On Nov 21, 9:25 pm, Joe Wright <> wrote:
    >>> On 11/21/2011 15:06, Stefan Ram wrote:

    > [...]
    >>> A pointer is a variable object in storage which can hold the address of
    >>> another object in storage. The address is a value, the pointer is an object.
    >>>
    >>> This concept is too complicated (or too simple) to some of my old friends
    >>> but it works for me. Keith Thompson beat me into semi-submission several
    >>> years ago until I got too tired to play. But here I am again.
    >>>
    >>> A pointer is an object. A function cannot return an object.

    >>
    >> surely this happens all the time
    >>
    >> struct point
    >> {
    >> int x;
    >> int y;
    >> };
    >>
    >> struct point make_point (int a, int b)
    >> { struct point p; p.x = a; p.y = b; return p; }
    >>
    >> isn't that returning an object? In fact doesn't this return an object?
    >>
    >> int f (void) { return 1; }

    >
    > I'd say no. In both cases, the function returns a value, not an
    > object. (There might be a "region of data storage" (from C99 3.14,
    > the definition of "object") that's allocated to hold the value, but
    > logically what the function returns is the value, not the object.)
    >
    > The value returned by a call to
    >
    > int f (void) { return 1; }
    >
    > is no more an object than the evaluation of the RHS of
    >
    > n = 1;
    >
    > results in an object. In particular, objects generally have
    > addresses; function results don't.


    In C99 this point could be argued. Under the new Standard,
    however, it's clear that struct/union expressions do in
    fact return objects, not just values. See 6.2.4 p8 (N1548).
    Tim Rentsch, Jan 25, 2012
    #19
  20. Tim Rentsch <> writes:
    > Keith Thompson <> writes:
    >> Nick Keighley <> writes:
    >>> On Nov 21, 9:25 pm, Joe Wright <> wrote:
    >>>> On 11/21/2011 15:06, Stefan Ram wrote:

    >> [...]
    >>>> A pointer is a variable object in storage which can hold the address of
    >>>> another object in storage. The address is a value, the pointer is an object.
    >>>>
    >>>> This concept is too complicated (or too simple) to some of my old friends
    >>>> but it works for me. Keith Thompson beat me into semi-submission several
    >>>> years ago until I got too tired to play. But here I am again.
    >>>>
    >>>> A pointer is an object. A function cannot return an object.
    >>>
    >>> surely this happens all the time
    >>>
    >>> struct point
    >>> {
    >>> int x;
    >>> int y;
    >>> };
    >>>
    >>> struct point make_point (int a, int b)
    >>> { struct point p; p.x = a; p.y = b; return p; }
    >>>
    >>> isn't that returning an object? In fact doesn't this return an object?
    >>>
    >>> int f (void) { return 1; }

    >>
    >> I'd say no. In both cases, the function returns a value, not an
    >> object. (There might be a "region of data storage" (from C99 3.14,
    >> the definition of "object") that's allocated to hold the value, but
    >> logically what the function returns is the value, not the object.)
    >>
    >> The value returned by a call to
    >>
    >> int f (void) { return 1; }
    >>
    >> is no more an object than the evaluation of the RHS of
    >>
    >> n = 1;
    >>
    >> results in an object. In particular, objects generally have
    >> addresses; function results don't.

    >
    > In C99 this point could be argued. Under the new Standard,
    > however, it's clear that struct/union expressions do in
    > fact return objects, not just values. See 6.2.4 p8 (N1548).


    (N1570 is newer.)

    No, that paragraph refers *only* to a struct or union that contains a
    member with array type:

    A non-lvalue expression with structure or union type, where
    the structure or union contains a member with array type
    (including, recursively, members of all contained structures
    and unions) refers to an object with automatic storage duration
    and temporary lifetime. Its lifetime begins when the
    expression is evaluated and its initial value is the value
    of the expression. Its lifetime ends when the evaluation of
    the containing full expression or full declarator ends. Any
    attempt to modify an object with temporary lifetime results in
    undefined behavior.

    That's a special case that was added to deal with code like this:

    #include <stdio.h>

    struct s {
    int arr[3];
    };

    struct s func(void) {
    struct s result = { { 10, 20, 30 } };
    return result;
    }

    int main() {
    printf("func().arr[1] = %d\n", func().arr[2]);
    return 0;
    }

    "func().arr" is of array type, so it decays to a pointer to the first
    element of the array object. The problem in C99 is that there is
    no array object; the array is a member of the *value* returned by
    the function. (Of course the object "result" no longer exists by
    that time.)

    In C99, there's no more an "object" created by func() than there is
    one created by "int foo(void) { return 42; }". C11 creates an object
    (with a newly invented storage duration) for this particular case.

    If the struct returned by the function doesn't contain an array
    member, then it's still covered by the old rules which don't imply
    that there's an object. (Implementations might treat both cases
    the same way, but they needn't do so.)

    --
    Keith Thompson (The_Other_Keith) <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"
    Keith Thompson, Jan 25, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Saravanan Rathinavelu

    Iterate through ArrayList using an another ArrayList

    Saravanan Rathinavelu, Aug 16, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    2,724
    Natty Gur
    Aug 19, 2003
  2. Kaidi
    Replies:
    4
    Views:
    2,320
    Kaidi
    Jan 3, 2004
  3. Replies:
    5
    Views:
    510
    Flash Gordon
    Apr 9, 2006
  4. Replies:
    8
    Views:
    476
    Bob Hairgrove
    Apr 10, 2006
  5. sara
    Replies:
    21
    Views:
    1,801
Loading...

Share This Page