What is a Global Array?
- Thread starter TechBoyJK
- Start date
yep. it would help if you explained a little more about the context in which you are asking this question. i could then get more specific about a particular programming language. in general, many languages support an array construct, and many languages support having variables in both global and local scope. object oriented languages also support variables whose scope is the object (rather than local to a function).
the prefix of the array(global,local) just has to do with where it can be applied. Global is throughout the entire application, where as local would be for a certain function or object..... Am I on the right track?? This question was actually derived by my reading of a php tutorial, but I am really just looking for overall concepts, not just php, even though I do realize it changes somewhat from language to language.
The specifics of global arrays are entirely dependant on the language. In PHP Iwouldn't worry about it.
But in C, you use global arrays because arrays passed as parameters to functions can severely impact the stack size and utlimtely overflow the main system stack, which is 1 MB for each thread. This is especially true with large arrays or arrays in recursive functions.
But in C, you use global arrays because arrays passed as parameters to functions can severely impact the stack size and utlimtely overflow the main system stack, which is 1 MB for each thread. This is especially true with large arrays or arrays in recursive functions.
An array is just a variable. Forget that we are talking about arrays here and focus on the concept of "global variables."
Each function generally has its own namespace. You can grab stuff from the global namespace by various methods.
In C, I'm not totally sure of the semantics of this. Generally, all global variable-esque things I need are constants, so I just #define them, and they work globally.l
In PHP, you do
global $variable;
And that global variable will now be in your local namespace for you to play with. You can also fudge around with the $GLOBALS superglobal array and access it all you want by using:
$GLOBALS["variable"]
Python is about the same.
global variable
In python, if you only need to read from the variable, you don't need to do this. Python will go up the namespace hierarchy and find it. However, if you want to assign something to it, you will need to use the global keyword.
In bourne shell, functions don't have their own namespaces, so you can just access global variables like normal. Shell scripting isn't exactly elegant though
Each function generally has its own namespace. You can grab stuff from the global namespace by various methods.
In C, I'm not totally sure of the semantics of this. Generally, all global variable-esque things I need are constants, so I just #define them, and they work globally.l
In PHP, you do
global $variable;
And that global variable will now be in your local namespace for you to play with. You can also fudge around with the $GLOBALS superglobal array and access it all you want by using:
$GLOBALS["variable"]
Python is about the same.
global variable
In python, if you only need to read from the variable, you don't need to do this. Python will go up the namespace hierarchy and find it. However, if you want to assign something to it, you will need to use the global keyword.
In bourne shell, functions don't have their own namespaces, so you can just access global variables like normal. Shell scripting isn't exactly elegant though
technically global is not through the whole application it is relavent to the process under which it is run. an app can contain sevral processes.
when passing arrays in C you always pass a pointer to the first element in the array, a good convention is also pass the size of the array with it. As far as I know its impossible to pass an array directly by value, they always go by reference.
you could do:
struct foo
{
int foo[100];
}
and then pass a foo into a function to pass an array by value but that is an asshole thing to do. i believ Elemental is talking out his ass.
not only could you not do it normaly but you wouldn't need to pass around a global array as it is in fact global and all your functions would have access to it in the first place.
what does that mean?
Exactly what it says: I know you're an experienced C programmer and would be able to definitively comment.
You might want to actually learn how C works you start accusing me of talking me out of my ass. The problem with most of these damn C courses is you never actually understand how the compiler works, other than you hit a little 'play' button and some stuff happens and a console pops up.
When you dynamically malloc() a variable, it goes onto a system heap. The only heap implementation that I've studied in detail is a Knuth heap which is more of an idealistic representation of a heap than anything else. When you allocate a global variable, it goes into a seperate block of memory that has been allocated by the system for all global variables. When you allocate a local variable (AKA A NON-GLOBAL VARIABLE) it goes onto the system stack. The variables are moved in LIFO order and the maximum stack size of each process is 1 MB.
Now, imagine that you locally define a variable of 10,000 double-precision numbers. Assuming its 32-bits per the IEEE floating point spec, its 8 bytes x 10,000 elements = 80,000 bytes for the array. So roughly slightly less than .1 MB of memory.
Those variables go onto the stack. Now, if you are using that function to call itself, it will push another copy of that function onto the stack, and reallocate another .08 MB array. Since most recursive functions are called thousands of times, you can see how you can crash the stack, right?
Now, if you were being smart and globally allocated that array, it would have been in seperate block of memory not tied to the stack.
Now, don't believe me? Fire up your compiler and define a series of global variables, then create main and call some other function and define the variables in there. Then malloc() another variable and print the addresses of each.
I await your apology.
You should reread your first post where you say that passing array as variable makes big inpact on stack usage, while now
you start talking about recursive functions and local arrays which based on your example arent reused after recursive call (because if they would,
you could not use global array effectively overwriting data every call) but still
you don't consider:
void tmp()
{
int *arr = (int *)malloc(100000);
// do stuff
free(arr);
tmp();
return;
}
malloc() doesn't allocate memory in stack, doesn't matter from where you call it.
you start talking about recursive functions and local arrays which based on your example arent reused after recursive call (because if they would,
you could not use global array effectively overwriting data every call) but still
you don't consider:
void tmp()
{
int *arr = (int *)malloc(100000);
// do stuff
free(arr);
tmp();
return;
}
malloc() doesn't allocate memory in stack, doesn't matter from where you call it.
What you describe in your post is the fact that you would prefer to not have the memory for an array allocated on the stack. You want it allocated on the heap. Allocating memory on the heap is separate from the question of if the variable that is used to access the array is global or local. If I had a local variable, and I used malloc to allocate memory for a large array, it would be heap allocated, but it would still be a local variable. It would not be a global array.
hahaha your such a dumbass, a global array can be declared on the stack as a simple pointer which is the common convention (if you have any real world experince or a brain in your head you would know that). When your initilization routine in your app is run you can then dynamically allocate the memory needed for the array, having a global array doesnt not imply that it was statically allocated, it just means that the variable is declared at the globabl scope. Furthermore you were shooting your mouth off about passing a global array by value in a recursive function in your original post talking about stack overflows which btw are not neccesarly caused at 1MB, the amount of stack space reserved is system specific and not part of the c or c++ standard. In fact many compilers have options for you to specify this as a parameter to the build process. BTW I have actually written a compiler from scratch so dont presume to lecture me or try to educate others when you obviously have a very weak and rudimentary grasp of memory allocation.
I don't really want an apolgoy from you. hahaha
BFG10K
Lifer
- Aug 14, 2000
- 22,709
- 3,000
- 126
That's nice but it has absolutely nothing to do with the issue at hand since no-one is using malloc(), new or any other derivatives of such. In fact your example uses dynamic memory allocation into the application's heap space while passing parameters (which is what we're discussing) only uses the stack.
Arrays in C/C++ are just pointers and thus char* and char [] are basically the same thing. So why do you possibly expect the compiler to pass around the entire array when the array by definition is just a pointer?
Now THAT'S a good one!
There are two concepts here that need some clarification: scope and lifetime.
Scope refers to where you can access a variable you have declared. For instance, if you declare a variable inside a function, the only place you can USE the variable's identifier to refer to that variable is inside that function. Outside of the function's "scope", the variable's identifier has no meaning. Global scope would mean that the identifier can be used ANYWHERE to access that variable.
Lifetime refers to the length of time a variable exists (i.e., has some memory storage allocated to it). A variable usually either has "program" lifetime (also referred to inappropriately as "global" lifetime) or "limited" lifetime. Local variables defined in a function, for instance, lose storage allocation the instant the function ends, so such variables only have "limited" lifetime. Variables declared outside of any function have allocation for the entire length of the program, and hence have "program" lifetime. Dynamically allocated variables have "limited" lifetime because by definition they do not exist when the program starts, and they could be de-allocated at any point during the runtime of the application.
I think part of the confusion here is that there are, in fact, TWO kinds of arrays that can have "global" scope in C.
The first case (the one traditionally referred to as a "global" variable) is the an array that is declared outside of any function. Such an array has "file" global scope and is statically allocated in the process's .DATA segment by the compiler (giving it program lifetime). Although theoretically the compiler could allocate this storage in some other bizarre way, traditionally the .DATA segment (which typically sits just above the .TEXT segment where your code resides) is where global variables are allocated. So in other words, this type of C global array would exist NEITHER on the stack NOR on the global heap. So forget what others have told you earlier if this is the type of array you're talking about.
The second kind of global array, as others have pointed out, is a dynamically allocated array which is stored on the "global" heap using malloc() or some other system-dependent dynamic allocation strategy (in Windows, GlobalHeapAlloc() would do the trick). The C runtime library's global heap has lifetime scope, so any array allocated there is guaranteed to be available for the lifetime of your program once it is allocated, and any function or block of code with a pointer to that array can access it (and abuse it, for that matter). Note that in advanced systems there are things called "local heaps" which complicate matters a bit, since such heaps themselves are dynamically allocated and therefore do not have program lifetime; any variables declared in them have global scope, but finite lifetime. But those are quite exotic creatures, so don't worry too much about "local heaps." Unless you're writing Windows C code that uses HeapAlloc() somewhere, you're probably JUST using the C runtime's global heap.
In all likelihood, I think the poster was referring to the FIRST kind of global array. So there is your answer. Does that help?
its probably out scope (pun intended) of this audience to discuss where static and global variables are allocated. If i rember right its in a place called .BSS but i forgot what that stood for.
BSS stands for "block starting symbol", and the .BSS segment is where only uninitialized data is allocated. And that is not where global arrays are allocated, because global variables are initialized automatically to zero.
Global arrays are allocated in the .DATA segment, as I stated earlier.
And I disagree that learning where variables are allocated is too detailed for this audience: it is the only way to really know what happens when you use such variables. If you don't know WHERE your variables are stored, WHO put them there, and WHEN they get created and destroyed, you probably don't understand what you're doing. And that means you should be programming in Perl or Basic, not C, where you can easily get yourself into trouble if you don't understand what you're doing.
BTW, when I say "you" I'm not referring to you Ameesh. I'm using it in the editorial sense.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 19K
-
-
-
Facebook
Twitter