Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   memory use global vs auto (http://www.velocityreviews.com/forums/t441731-memory-use-global-vs-auto.html)

ok 03-10-2006 07:53 PM

memory use global vs auto
 
I have the following code:

void foo(void)
{
const int array[100] = ....;

// do stuff with array
}

I mostly use code like this so my program doesnt waste memory because array
only gets allocated when foo is called.
But now I heard from somebody that the following code is the same in terms
of memory footprint:

static int array[100] = .....

void foo(void)
{
// do stuff with array
}

is that true?



Ben Pfaff 03-10-2006 08:21 PM

Re: memory use global vs auto
 
"ok" <la@hm.com> writes:

[question about comparative memory footprint of two examples
below]
> void foo(void)
> {
> const int array[100] = ....;
>
> // do stuff with array
> }


> static int array[100] = .....


I imagine that these would have approximately the same memory
footprint on many implementations, given that the former array is
const. If it was non-const, then it would likely take *more*
memory than the latter, because the implementation would likely
initialize the array by copying a statically allocated copy.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield

Christian Bau 03-10-2006 10:21 PM

Re: memory use global vs auto
 
In article <duslfk$jbu$1@news5.zwoll1.ov.home.nl>, "ok" <la@hm.com>
wrote:

> I have the following code:
>
> void foo(void)
> {
> const int array[100] = ....;
>
> // do stuff with array
> }
>
> I mostly use code like this so my program doesnt waste memory because array
> only gets allocated when foo is called.


Think for ten minutes what kind of code your compiler would have to
produce to implement this. Then have a look at the assembler code that
it generates. It will be a good learning experience.

=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?= 03-11-2006 09:46 AM

Re: memory use global vs auto
 
ok wrote:
> I have the following code:
>
> void foo(void)
> {
> const int array[100] = ....;
>
> // do stuff with array
> }
>
> I mostly use code like this so my program doesnt waste memory because array
> only gets allocated when foo is called.
> But now I heard from somebody that the following code is the same in terms
> of memory footprint:
>
> static int array[100] = .....
>
> void foo(void)
> {
> // do stuff with array
> }
>
> is that true?


That is entierly up to the implementation (your particular compiler),
possibly also which optimizations you enable, etc., too.

ok 03-11-2006 11:57 AM

Re: memory use global vs auto
 

"Christian Bau" <christian.bau@cbau.freeserve.co.uk> wrote in message
news:christian.bau-102539.22211010032006@slb-newsm1.svr.pol.co.uk...
> In article <duslfk$jbu$1@news5.zwoll1.ov.home.nl>, "ok" <la@hm.com>
> wrote:
>
>> I have the following code:
>>
>> void foo(void)
>> {
>> const int array[100] = ....;
>>
>> // do stuff with array
>> }
>>
>> I mostly use code like this so my program doesnt waste memory because
>> array
>> only gets allocated when foo is called.

>
> Think for ten minutes what kind of code your compiler would have to
> produce to implement this. Then have a look at the assembler code that
> it generates. It will be a good learning experience.


will do, installing my fav compiler now :)
So I guess it doesnt matter to use global static or auto in this case
mostly?



Richard G. Riley 03-11-2006 01:44 PM

Re: memory use global vs auto
 
"ok"posted the following on 2006-03-10:

> I have the following code:
>
> void foo(void)
> {
> const int array[100] = ....;
>
> // do stuff with array
> }
>
> I mostly use code like this so my program doesnt waste memory because array
> only gets allocated when foo is called.
> But now I heard from somebody that the following code is the same in terms
> of memory footprint:
>
> static int array[100] = .....
>
> void foo(void)
> {
> // do stuff with array
> }
>
> is that true?
>
>


Memory footprint aside, its certainly not in terms of modularised
programming :)

However, firing up gdb and stepping into foo() gave me code like this
for an array of "const int array[3]={255,2,3}"

Dump of assembler code for function foo:
0x08048378 <foo+0>: push %ebp
0x08048379 <foo+1>: mov %esp,%ebp
0x0804837b <foo+3>: sub $0x10,%esp
0x0804837e <foo+6>: mov 0x80484cc,%eax
0x08048383 <foo+11>: mov %eax,0xfffffffc(%ebp)
0x08048386 <foo+14>: leave
0x08048387 <foo+15>: ret
End of assembler dump.

As you can see, there is no "function time" reinitialising and
creation of your array. If you want to generate an assembler file then
you will probably see your array as a global data object.

Now change the initiliasation of your array to include a run time
variable in foo and you will see the array re-initialised each
function call e.g

int i=255;
const int array[3]={1,i,3]; //const initialisation is fine

Stepping in with instructions displayed gives:

Dump of assembler code for function foo:
0x08048378 <foo+0>: push %ebp
0x08048379 <foo+1>: mov %esp,%ebp
0x0804837b <foo+3>: sub $0x28,%esp
0x0804837e <foo+6>: movl $0xff,0xfffffff8(%ebp)
0x08048385 <foo+13>: movl $0x1,0xffffffec(%ebp)
0x0804838c <foo+20>: mov 0xfffffff8(%ebp),%eax
0x0804838f <foo+23>: mov %eax,0xfffffff0(%ebp)
0x08048392 <foo+26>: movl $0x3,0xfffffff4(%ebp)
0x08048399 <foo+33>: mov 0xffffffec(%ebp),%eax
0x0804839c <foo+36>: mov %eax,0xfffffffc(%ebp)
0x0804839f <foo+39>: sub $0x8,%esp
0x080483a2 <foo+42>: pushl 0xfffffffc(%ebp)
0x080483a5 <foo+45>: push $0x80484ec
0x080483aa <foo+50>: call 0x80482b0 <_init+56>
0x080483af <foo+55>: add $0x10,%esp
0x080483b2 <foo+58>: mov 0xfffffffc(%ebp),%eax
0x080483b5 <foo+61>: leave
0x080483b6 <foo+62>: ret
End of assembler dump.

Of course, Gcc specific, but it can be fun to see how C is compiled
into native code : and often no real need to generate seperate
assembler files.


All times are GMT. The time now is 01:13 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.