when are Arrays allocated memory? are they affected by code blocks?

[Noobzo]

Hello, i'm learning about arrays and my question is, when do arrays
get their memory reserved? here are some exaples

1)
void Function1()
{
int arr[10];
arr[0] = 1;
}

int main( )
{
Function1();
}

////////////////////////////////////////////////////
2)
int main( )
{
Array1[5];

{
Array2[15];

{
Array3[20];
}
}
}// does the block prevent the array from being allocated until it
reaches execution?

thank you.

 

[Branimir Maksimovic]

Hello, i'm learning about arrays and my question is, when do arrays
get their memory reserved? here are some exaples

1)
void Function1()
{
int arr[10];
arr[0] = 1;
}

int main( )
{
Function1();
}

2)
int main( )
{
Array1[5];

{
Array2[15];

{
Array3[20];
}
}
}// does the block prevent the array from being allocated until it
reaches execution?

I believe that with optimization turned on, none of those arrays would
be allocated at all , it's up to implementation

For example g++ creates code by the book with -O0 but with -O2,
generates completely different code ...

All in all you can't access arrays out of their scope...
I mean you can, but code won;t work...

Greets

 

[Noobzo]

thanks Branimir Maksimovic for your reply,

but given that these arrays were used and the optimizer didn't remove
them, would putting an array in a scope help reducing overheads?
because sometimes in big functions, many arrays would be defined for
small tasks, would it help to place these arrays in smaller code
blocks inside the functions? something like this:


void function()
{
int array1[100];
.
.
.
.

{
//will this array get on the stack now? or once the
function entered its scope?

int array2[100];//would it be removed from the stack
after existing this code block?
.
.
.
.

}

int array3[100];
.
.
.
.

}

 

[Jerry Coffin]

[ ... ]

int main( )
{
Array1[5];

{
Array2[15];

{
Array3[20];
}
}
}// does the block prevent the array from being allocated until it
reaches execution?

At least in theory, it could vary between compilers. All of them I've
looked at, however, did all the stack allocations for a function upon
entry to that function.

 

[Branimir Maksimovic]

{
//will this array get on the stack now? or once the
function entered its scope?

int array2[100];//would it be removed from the stack
after existing this code block?
.
.
.
.

}

Stack is just memory area of very limited size. If you have too much
local arrays sooner or later you'll reach maximum size, which
will trigger exception,segfault etc
Perhaps os can grow stack (run time overhead with cooperation form
compiler?), perhaps not. I don;t know.
Answer depends a lot on how stack frame is set up.
Usually you have place for parameters , return address, and local
variables, something else ? So anyhow if you want to grow/shrink
stack local vars should be down below, which is not always, possible
and simple I guess.

Greets

 

[jamm]

Hello, i'm learning about arrays and my question is, when do arrays
get their memory reserved? here are some exaples

1)
void Function1()
{
int arr[10];
arr[0] = 1;
}

int main( )
{
Function1();
}

////////////////////////////////////////////////////
2)
int main( )
{
Array1[5];

{
Array2[15];

{
Array3[20];
}
}
}// does the block prevent the array from being allocated until it
reaches execution?

thank you.

Allocated on the stack upon entry of function.

--
*From the 1966 TV series:*
Robin: You can't get away from Batman that easy!
Batman: Easily.
Robin: Easily.
Batman: Good grammar is essential, Robin.

 

[James Kanze]

thanks Branimir Maksimovic for your reply,
but given that these arrays were used and the optimizer
didn't remove them, would putting an array in a scope help
reducing overheads? because sometimes in big functions,
many arrays would be defined for small tasks, would it help
to place these arrays in smaller code blocks inside the
functions? something like this:
void function()
{
int array1[100];
.
.
.
.

{
//will this array get on the stack now? or once the
function entered its scope?
int array2[100];//would it be removed from the stack
after existing this code block?
.
.
.
.
}
int array3[100];
.
.
.
.
}

Typically stack space is reserved for arrays just the once on
entry to the function even if the array exists in a child
scope within the function.

Yes, but there's no way a conforming program can tell, so the
question is rather irrelevant.

If the arrays are in non overlapping blocks, e.g.:

void f()
{
{
int array1[20];
// ...
}
{
int array2[20]
// ...
}
}

I would hope that the compiler didn't reserve two distinct,
non-overlapping areas on the stack for the two arrays. But
again, there's no way to really know from within the program.

 

[Noobzo]

well thank you guys for the helpful discussion, am gonna try to find
my specific compiler documentation about this, hope that Microsoft has
it documented though lol, thanks

 

[Nick Keighley]

Hello, i'm learning about arrays and my question is, when do arrays
get their memory reserved? here are some exaples

1)
void Function1()
{
        int arr[10];
        arr[0] = 1;

}

int  main( )
{
        Function1();

}

////////////////////////////////////////////////////
2)
int  main( )
{
        Array1[5];

        {
                Array2[15];

                {
                        Array3[20];
                }
        }}// does the block prevent the array from being allocated until it

reaches execution?

and generally speaking use std::vector rather tha arrays

 

[Bart van Ingen Schenau]

Hello, i'm learning about arrays and my question is, when do arrays
get their memory reserved? here are some exaples

That is completely up to the compiler. Basically, the only requirement
is that it happens somewhere between starting your program and the
moment when execution reaches the definition of your array. Typically,
it is more restricted to between entering the function and reaching
the definition of the array.

Modern compilers are reasonably good at reducing the amount of memory
that is needlessly allocated. For example, if you have two or more
variables (or arrays) that do not exist at the same time, most
compilers will try let them share the same memory locations.

Bart v Ingen Schenau