Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Size of an arraylist in bytes

Reply
Thread Tools

Re: Size of an arraylist in bytes

 
 
Keith Thompson
Guest
Posts: n/a
 
      11-22-2011
Nick Keighley <(E-Mail Removed)> writes:
> On Nov 21, 9:25*pm, Joe Wright <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      11-22-2011
Ark <(E-Mail Removed)> 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) (E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-22-2011
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
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      11-22-2011
pete <(E-Mail Removed)> 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.

 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-22-2011
On 2011-11-22, Stefan Ram <(E-Mail Removed)-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.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      11-22-2011
Kaz Kylheku <(E-Mail Removed)> writes:
>On 2011-11-22, Stefan Ram <(E-Mail Removed)-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>.

 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      11-26-2011
On 11/21/2011 3:06 PM, Stefan Ram wrote:
> Patricia Shanahan<(E-Mail Removed)> 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

 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-25-2012
Nick Keighley <(E-Mail Removed)> writes:

> On Nov 21, 9:25 pm, Joe Wright <(E-Mail Removed)> 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<(E-Mail Removed)> 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).
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-25-2012
Keith Thompson <(E-Mail Removed)> writes:

> Nick Keighley <(E-Mail Removed)> writes:
>> On Nov 21, 9:25 pm, Joe Wright <(E-Mail Removed)> 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 (N154.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-25-2012
Tim Rentsch <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> Nick Keighley <(E-Mail Removed)> writes:
>>> On Nov 21, 9:25 pm, Joe Wright <(E-Mail Removed)> 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 (N154.


(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) (E-Mail Removed) <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"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Size of an arraylist in bytes sara Java 21 11-26-2011 04:15 AM
Could a struct with size 44 bytes point always points to a char array with size 2024 bytes? eagle_jyjh@citiz.net C++ 8 04-10-2006 03:05 PM
Could a struct with size 44 bytes point always points to a char array with size 2048 bytes? eagle_jyjh@citiz.net C Programming 5 04-09-2006 02:49 PM
a class inherited from ArrayList, is saved to ViewState, why the type of the object read from ViewSate is not the class, but the parent, ArrayList leal ting ASP .Net 1 02-10-2004 07:45 PM
Iterate through ArrayList using an another ArrayList Saravanan Rathinavelu ASP .Net 3 08-19-2003 07:03 AM



Advertisments