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

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

Re: Size of an arraylist in bytes

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: Size of an arraylist in bytes Joe Wright <joewwright@comcast.net> - 2011-11-21 16:25 -0500
    Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2011-11-21 14:03 -0800
      Re: Size of an arraylist in bytes pete <pfiland@mindspring.com> - 2011-11-21 17:45 -0500
        Re: Size of an arraylist in bytes Ark <akhasin@macroexpressions.com> - 2011-11-21 21:19 -0500
          Re: Size of an arraylist in bytes Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-21 22:06 -0500
            Re: Size of an arraylist in bytes Ark <akhasin@macroexpressions.com> - 2011-11-22 03:07 -0500
              Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2011-11-22 06:51 -0500
          Re: an instance of an object (was: Size of an arraylist in bytes) Keith Thompson <kst-u@mib.org> - 2011-11-21 21:54 -0800
          Re: Size of an arraylist in bytes pete <pfiland@mindspring.com> - 2011-11-22 01:49 -0500
            Re: Size of an arraylist in bytes Ark <akhasin@macroexpressions.com> - 2011-11-22 03:17 -0500
              Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2011-11-22 00:48 -0800
              Re: Size of an arraylist in bytes pete <pfiland@mindspring.com> - 2011-11-23 05:16 -0500
            Re: Size of an arraylist in bytes Kaz Kylheku <kaz@kylheku.com> - 2011-11-22 16:49 +0000
          Re: Size of an arraylist in bytes pete <pfiland@mindspring.com> - 2011-11-23 09:30 -0500
    Re: Size of an arraylist in bytes Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-22 00:07 -0800
      Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2011-11-22 00:24 -0800
        Re: Size of an arraylist in bytes Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 05:06 -0800
          Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2012-01-25 12:15 -0800
            Re: Size of an arraylist in bytes Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 18:49 -0800
              Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2012-02-01 13:53 -0800
                Re: Size of an arraylist in bytes lawrence.jones@siemens.com - 2012-02-01 18:53 -0500
                  Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2012-02-01 20:06 -0800
                Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-01 21:40 -0500
                  Re: Size of an arraylist in bytes jgk@panix.com (Joe keane) - 2012-02-02 03:45 +0000
                    Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2012-02-01 20:14 -0800
                    Re: Size of an arraylist in bytes Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-01 23:14 -0500
                      Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-02 18:38 -0500
                      Re: Size of an arraylist in bytes jgk@panix.com (Joe keane) - 2012-02-03 16:32 +0000
                        Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-03 11:57 -0500
                          Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-03 20:07 -0500
                          Re: Size of an arraylist in bytes jgk@panix.com (Joe keane) - 2012-02-04 22:35 +0000
                            Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-04 18:43 -0500
                              Re: Size of an arraylist in bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-05 01:50 +0000
                                Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-04 21:37 -0500
                                  Re: Size of an arraylist in bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-05 14:48 +0000
                                    Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-05 10:20 -0500
                                      Re: Size of an arraylist in bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-05 16:25 +0000
                                        Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-05 12:06 -0500
                                          Re: Size of an arraylist in bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-05 19:21 +0000
                                          Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-05 15:29 -0500
                                          Re: Size of an arraylist in bytes Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:46 -0800
                                Re: Size of an arraylist in bytes Kaz Kylheku <kaz@kylheku.com> - 2012-02-05 02:39 +0000
                                  Re: Size of an arraylist in bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-05 15:17 +0000
                                    Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-05 12:06 -0500
                                      Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-05 15:06 -0500
                                Re: Size of an arraylist in bytes jgk@panix.com (Joe keane) - 2012-02-07 17:35 +0000
                                  Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-07 19:51 -0500
                                    Re: Size of an arraylist in bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-08 01:14 +0000
                              Re: Size of an arraylist in bytes Kaz Kylheku <kaz@kylheku.com> - 2012-02-05 02:31 +0000
                        Re: Size of an arraylist in bytes Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-03 21:26 -0500
                          Re: Size of an arraylist in bytes Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-03 21:31 -0500
                          Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-04 06:57 -0500
                            Re: Size of an arraylist in bytes Kaz Kylheku <kaz@kylheku.com> - 2012-02-04 18:32 +0000
                              Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-05 22:51 -0500
                          Re: Size of an arraylist in bytes jgk@panix.com (Joe keane) - 2012-02-04 21:25 +0000
                            Re: Size of an arraylist in bytes Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-04 17:08 -0500
                              Re: Size of an arraylist in bytes Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:52 -0800
                            Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-04 17:32 -0500
                              Re: Size of an arraylist in bytes Kaz Kylheku <kaz@kylheku.com> - 2012-02-05 02:19 +0000
                                Re: Size of an arraylist in bytes Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-05 09:20 -0500
                                  Re: Size of an arraylist in bytes James Kuyper <jameskuyper@verizon.net> - 2012-02-05 09:42 -0500
                                  Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-05 16:17 -0500
                            Re: Size of an arraylist in bytes Zoltan Kocsi <zoltan@bendor.com.au> - 2012-02-05 17:49 +1100
                            Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-05 16:48 -0500
                              Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-05 16:52 -0500
                    Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-02 01:07 -0500
                Re: Size of an arraylist in bytes lawrence.jones@siemens.com - 2012-02-03 11:29 -0500
                  Re: Size of an arraylist in bytes Keith Thompson <kst-u@mib.org> - 2012-02-03 12:42 -0800
                    lvalue "potentially" designates an object (was Re: Size of an arraylist in bytes) Kenneth Brody <kenbrody@spamcop.net> - 2012-02-04 12:47 -0500
                      Re: lvalue "potentially" designates an object (was Re: Size of an arraylist in bytes) Kaz Kylheku <kaz@kylheku.com> - 2012-02-04 18:39 +0000
                    Re: Size of an arraylist in bytes lawrence.jones@siemens.com - 2012-02-04 14:46 -0500
                  Re: Size of an arraylist in bytes Kaz Kylheku <kaz@kylheku.com> - 2012-02-03 22:35 +0000
                    Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-06 00:01 -0500
                      Re: Size of an arraylist in bytes Kaz Kylheku <kaz@kylheku.com> - 2012-02-06 08:46 +0000
                        Re: Size of an arraylist in bytes Shao Miller <sha0.miller@gmail.com> - 2012-02-06 23:17 -0500
              Re: Size of an arraylist in bytes lawrence.jones@siemens.com - 2012-02-01 18:34 -0500
                Re: Size of an arraylist in bytes Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:54 -0800
      Re: Size of an arraylist in bytes Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 05:00 -0800

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

#13739 — Re: Size of an arraylist in bytes

On 11/21/2011 15:06, Stefan Ram wrote:
> Newsgroups: comp.lang.java.programmer,comp.lang.c
> Followup-To: comp.lang.c
>
> Patricia Shanahan<pats@acm.org>  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. 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."

[toc] | [next] | [standalone]

#13743

Joe Wright <joewwright@comcast.net> 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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#13749

Keith Thompson wrote:
> 
> Joe Wright <joewwright@comcast.net> 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.

-- 
pete

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

#13761

On 11/21/2011 5:45 PM, pete wrote:
> Keith Thompson wrote:
>>
>> Joe Wright<joewwright@comcast.net>  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?

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

#13764

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
esosman@ieee-dot-org.invalid

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

#13767

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

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

#13779

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

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

#13765 — Re: an instance of an object (was: Size of an arraylist in bytes)

ram@zedat.fu-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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#13766

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).

-- 
pete

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

#13769

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

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

#13771

Ark <akhasin@macroexpressions.com> 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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#13812

Ark wrote:
> 
> 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.

That's what I believe too.

I don't understand what it is 
that you think you're replying to.

-- 
pete

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

#13788

On 2011-11-22, Stefan Ram <ram@zedat.fu-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.

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

#13818

Ark wrote:
> 
> On 11/21/2011 5:45 PM, pete wrote:
> > Keith Thompson wrote:
> >>
> >> Joe Wright<joewwright@comcast.net>  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?

It depends on context:
if you're talking about the pointer argument in a call to strlen,
then it doesn't make any difference 
whether or not the pointer is also an a lvalue.
If you're talking about assigning a value to a pointer,
then it does make a difference.


-- 
pete

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

#13768

On Nov 21, 9:25 pm, Joe Wright <joewwri...@comcast.net> 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<p...@acm.org>  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 -

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

#13770

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On Nov 21, 9:25 pm, Joe Wright <joewwri...@comcast.net> 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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16191

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

> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>> On Nov 21, 9:25 pm, Joe Wright <joewwri...@comcast.net> 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).

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

#16220

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>>> On Nov 21, 9:25 pm, Joe Wright <joewwri...@comcast.net> 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) 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"

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

#16544

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>>>> On Nov 21, 9:25 pm, Joe Wright <joewwri...@comcast.net> 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.)

It is.  Are N1548 and N1570 different in any way other than the
presence or absence of change bars?


> 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:
> [snip example]

Quite right.  Thank you for the correction.


> In C99, there's no more an "object" created by func() [which
> returns a struct that has an array member] than there is one
> created by "int foo(void) { return 42; }".  [snip C11 comment]

The Standard doesn't say so, but I argue that for all practical
purposes there is, because of how array conversion works.  In
particular, the resulting pointer value is AFAIK valid, eg, can
be compared against NULL or other pointers, etc.


> 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.)

Since member selection can be applied to the results of such
functions, the semantic descriptions of '.' and '->' imply that
there is.

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

#16618

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>>>>> On Nov 21, 9:25 pm, Joe Wright <joewwri...@comcast.net> 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.)
>
> It is.  Are N1548 and N1570 different in any way other than the
> presence or absence of change bars?

I don't know (is there a "diff" for PDF files?), but they're dated
2010-12-02 and 2011-04-12, respectively.  I presume the latter
reflects whatever changes the committee made in those 4+ months.

N1570 has change bars marking changes relative to N1539.

[...]

>> In C99, there's no more an "object" created by func() [which
>> returns a struct that has an array member] than there is one
>> created by "int foo(void) { return 42; }".  [snip C11 comment]
>
> The Standard doesn't say so, but I argue that for all practical
> purposes there is, because of how array conversion works.  In
> particular, the resulting pointer value is AFAIK valid, eg, can
> be compared against NULL or other pointers, etc.
>
>
>> 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.)
>
> Since member selection can be applied to the results of such
> functions, the semantic descriptions of '.' and '->' imply that
> there is.

Here's what both N1256 (C99) and N1570 (C11) 6.5.2.3p3 say about the
semantics of "." (C90 is very similar.)

    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. If the first expression has qualified
    type, the result has the so-qualified version of the type of
    the designated member.

The first sentence clearly implies that the prefix must refer to
an object.  The second sentence, though talks about what happens
if the prefix is not an lvalue.  An lvalue is an expression that
(potentially(!)) designates an object.

So if the prefix isn't an lvalue, and therefore doesn't designate an
object, what object's member does the expression designate?

Personally, I think it would have made more sense to say that the
prefix is an expression (lvalue or not) of struct or union type, and
that x.y, if x is not an lvalue, yields the value of the member of
the struct or union value.  In other words, values can have member
values even if there's no object in sight.  (Probably not the best
possible wording.)

(An aside: I've complained before that the C90 and C99 standards'
definitions of "lvalue" were flawed, and suggested "expression that
potentially designates an object" to fix the problem.  The word
"potentially" is needed to ensure that *ptr is an lvalue even if
ptr==NULL.  I just now noticed that N1570 has this updated wording.
Looks like somebody was listening.  I am inordinately pleased.)

-- 
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"

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

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

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

csiph-web