Confused about Memory

ok .. I am confused when it comes to memory ...

Say, when someone stores a file ID at a certain location in memory...

Code:

---

#define FILE_ID 0xFA34AF    // or whatever hexadecimal number

---

or does this ...

Code:

---

case 0xFA6A3:  // or whatever hexadecimal number again

---

I don't know if these are relavent questions.. or if I am even asking the right questions...

How is this address available, and how do programmers know where to store a variable, or macro?

Can a programmer accidently use the addresses of memory from another program, or process?

Is there a certain local memory block that is available for use to program with, that is not used for the OS, or other processes? (ex. heap, stack)

What address does the memory start with?

Is it different on all computers?

Where is the memory, used to program, stored on a computer?

It just that everytime I look at a program that has a hexidecimal address... i get confused...

Why is "0xFA34AF" referring to an address? Isn't it really just an integer? Just because it's in hexadecimal doesn't mean it's referring to a memory address. What if I did this:

Code:

---

#include <iostream>

#define NUM1 0x54F107
#define NUM2 0xFF3715

int main() {
  std::cout << NUM2 << " - " << NUM1 << " = " << NUM2 - NUM1
            << std::endl;
  return 0;
}

---

or this:

Code:

---

#include <iostream>

int main() {
  for(int i = 0; i < 5; i++) {
      switch(i) {
        case 0x00:
          std::cout << "This is 0" << std::endl;
          break;
        case 0x01:
          std::cout << "This is 1" << std::endl;
          break;
        case 0x02:
          std::cout << "This is 2" << std::endl;
          break;
        case 0x03:
          std::cout << "This is 3" << std::endl;
          break;
        case 0x04:
          std::cout << "This is 4" << std::endl;
          break;
      }
  }
  return 0;
}

---

Why don't you try writing a switch statement with a pointer and tell me what the result is.

oook... i just figured that because if you use an address-of operator of an integer to cout, it sends a hexidecimal value...i guess i just got confused with that...soo that could just be an integer then... gotcha... but why would people do this, instead of just saying 1, 2, 3, 4, 5?

And when would somebody define a memory location? Or can you?

And also, I think the questions above are still relevant? Like, how is memory availability predetermined?

Memory availability isn't predetermined. No memory addresses are defined on the compilation of a program. What's defined is merely offsets in memory from the start of the program's memory block. When a program is run, the OS can put it anywhere in memory, so the variables won't have the same addresses, but they will always be the same distance from each other.

You can't "define" a memory location, because as you said, you'll never know what's available to your program. Yes, all pointers really hold are integers, but it's the fact that it's a pointer that tells the computer it's a memory address. When you get into assembly, you'll see there are different registers for regular data and pointers.

ahhhh i get ya now... so its like the OS has a memory map sorda... and so does the program itself.... but the OS places the program somewhere on it's map...so the program's map is unaffected...just offsetted in memory... but the variable addresses remain parrallel within the program....

Code:

---

Program Orignal Starting Memory: OxFFFFFF
Program Variable: 0xFFFFFA

Program Starting Memory After OS Movement: 0xFFFFFF + 1(or whatever value to get to the memory specified on the OS map)
Program Variable After OS Movement: 0xFFFFFA + 1(or whatever value to get to the memory specified on the OS map)

---

So its like saying that the OS controls Global Addresses? And the program controls local addresses that are just offsets of the Global Addresses?

> How Stuff works "How C Programming Works" - The Heap

ahhh i see...and ive looked up a defintion... and they are synonymes right?

Stack: Static;
Heap: Dynamic;

And somethin about like the stack has variable addresses right?
And I don't know about the heap...

All memory has an address, not just the stack.

The OS puts a restraint on all application's usable stack space, this is why it is static because this never changes. The usuable stack space will always bea certain size. However the heap is dynamic because there may be a lot available or there may be a little available, and this availability will grow as programs finish running, and get smaller as more and more programs are run.

This is news to me.

How does the computer then deside before runtime how much stack space a program will need? Furthermore why does it do that? Why not provide a mechanism to split the stack up, to allow for a larger stack if needed?

Speaking of which, there doesn't seem to a way of handleing low memmory when making function calls. Can't a C/++ program run out of stack space? Why is there no way to handle that?

For example:

Code:

---

void funk(int i)
{
    cout<<i<<endl;
    funk(++i);
}

int main(int argc, char **argv)
{
    funk(0);
}

---

> How does the computer then deside before runtime how much stack space a program will need?
It kind of doesn't. The stack is pretty much the same size for every program I think. I don't know how to prove it though.

> Can't a C/++ program run out of stack space?
Sure, but isn't this the same for any program coded in language X?

> Why is there no way to handle that?
Well you illustrated a good reason why not with recursion. How is a program supposed to decide what memory is important and what is not? It's your responsibility.

Quote:

---

Originally Posted by citizen

> How does the computer then deside before runtime how much stack space a program will need?
It kind of doesn't. The stack is pretty much the same size for every program I think. I don't know how to prove it though.

---

That's my point. What if I have a particularly large program and run out of stack space?

Quote:

---

> Can't a C/++ program run out of stack space?
Sure, but isn't this the same for any program coded in language X?

> Why is there no way to handle that?
Well you illustrated a good reason why not with recursion. How is a program supposed to decide what memory is important and what is not? It's your responsibility.

---

Right, but as I asked why is there no way to handle that? There is no exeption thrown, nothing. The program would presumably just crash. I can't deside what is unimportant if I don't know when I'm running out of stack space.

With the Heap, if an allocation fails, new throws an exeption and that can be handled by the Program. It might free up some memmory, or try to safely save and quit.

But if a function call fails, what is to be done?

A good program shouldn't get a stack overflow. A lot of your memory should be allocated dynamically and freed as soon as it's done its job.

Quote:

---

Originally Posted by SlyMaelstrom

A good program shouldn't get a stack overflow. A lot of your memory should be allocated dynamically and freed as soon as it's done its job.

---

He's right of course.

> But if a function call fails, what is to be done?
Well crashing is quitting in a crazy way so when a function call fails, that sort of happens anyway. So I guess you want to pop stuff off the stack frame yourself? You're risking corrupting the stack frame of that function unless you destroy it completely (i.e. return), so that doesn't really make much sense. You'd crash right after you'd finished messing with things C tried to hide from you.

And if you just returned early on an exception, then the function did nothing helpfull. It's not like calling it again will change your situation. Plus, in the case of recursion you would unwind the stack too early and get a wrong return value or something undefined, perhaps?

That idea makes C++ more complex than it already is.

[edit]
Who writes functions with variables they don't use, anyway? In a good function all the memory you request is essential.
[/edit]

Quote:

---

Originally Posted by citizen

He's right of course.

---

In the general case I would agree.

But exept for stack overflow, there is nothing inherrently wrong with having a lot of fixed size information on the stack rather than on the heap. eg: What would be wrong with keeping an object pool on the stack?(such as by using static arrays instead of dinamic arrays)(assuming of course all objects are of the same size)

Furthermore, what defines the max size of the stack? If stack sizes vary by machine, a program might run fine on one machine, but fail on another.

Quote:

---

> But if a function call fails, what is to be done?
Well crashing is quitting in a crazy way so when a function call fails, that sort of happens anyway. So I guess you want to pop stuff off the stack frame yourself? You're risking corrupting the stack frame of that function unless you destroy it completely (i.e. return), so that doesn't really make much sense. You'd crash right after you'd finished messing with things C tried to hide from you.

And if you just returned early on an exception, then the function did nothing helpfull. It's not like calling it again will change your situation. Plus, in the case of recursion you would unwind the stack too early and get a wrong return value or something undefined, perhaps?

That idea makes C++ more complex than it already is.

---

Well for starters, you might try to quit safely, log an error and maybe even create an recoverable active file (like with MS Word).

But really that's the problem with a fixed size stack. You can't do much to prevent it from happinig again.

Quote:

---

[edit]
Who writes functions with variables they don't use, anyway? In a good function all the memory you request is essential.
[/edit]

---

Attached is a more common programing error leading to stack overflow. This example program actually came with Dev C++. :rolleyes: I sure hope nobody follows it.

Quote:

---

Originally Posted by gL_nEwB

ahhh i see...and ive looked up a defintion... and they are synonymes right?

Stack: Static;

---

No, becouse static is a key word in C/++. It has many different uses.

The concept is correct, just don't assume that if somebody is talking about something static that it means "on the stack."

Quote:

---

Originally Posted by King Mir

What would be wrong with keeping an object pool on the stack?

---

Well for one... a stack overflow. :p
...and secondly, more often then not, most of those objects will be sitting idly when they don't need to be there at all. When you write more complex programs, you have to manage your memory and keep only what you need. You could keep static objects for all the rendering information for every map you make, but what's the point if you only render one map at a time.

I remember one of the first real programs I wrote was a trivia program. It have several games each with 10 questions. I decided to hard code all of the questions into strings, which totaled to about 400 strings between the questions and multiple choice answers. I only needed maybe 50 strings in memory at any given game. Not saying this is a prime example, but even when you get better at programming, there could still be bad memory management.

Crashing because of stack overflow is your friend. It lets you know in the most violent way possible that you failed at programming and need to do better. That's worth something.

Quote:

---

Furthermore, what defines the max size of the stack? If stack sizes vary by machine, a program might run fine on one machine, but fail on another.

---

Well the stack is sufficiently huge for that kind of stuff: it's really a combination of the OS and compiler magic that allows the stack to work the way it does, but the restriction needs to be there otherwise you could make the stack so huge that it interferes with other programs.

isn't the stack size determined by the amount of RAM and virtual memory of the computer?

How C Programming Works

btw...thanks for the link citizen...way better understand with memory... and pointers

> isn't the stack size determined by the amount of RAM and virtual memory of the computer?
Yeah but the OS does that kind of work. And in particular with functions your compiler will put in code to teach the OS how to build the function's stack frame.

As for the article, just don't pick up the bad habit of casting malloc without knowing what that could do. There are details in the FAQ about why that is bad, if you ever decide to code in C. Also be aware that new has a couple of ways to tell you allocation has failed. By throwing an exception:

Code:

---

#include <stdexcept>
try {
  int *p = new int;
}
catch (std::bad_alloc &error) {
  // spit out an error message and close or something
}

---

Or you can force new to return 0:

Code:

---

#include <new>
int *p = new (std::nothrow) int;
if (!p)
  // error message again...

---

Quote:

---

Originally Posted by citizen

Crashing because of stack overflow is your friend. It lets you know in the most violent way possible that you failed at programming and need to do better. That's worth something.

Well the stack is sufficiently huge for that kind of stuff: it's really a combination of the OS and compiler magic that allows the stack to work the way it does, but the restriction needs to be there otherwise you could make the stack so huge that it interferes with other programs.

---

Stack overflow would be less of a problem is there was a way to split the stack between two memmory blocks.

Sufficently huge is always a relitive term. If I have a big program, I'm more likely to run out of stack memmory. If I have a small program, it's wasteing memmory with a large stack.

Maybe I need to approach my replies in a different way.

Memory is a finite source. Period.

Even if you split up the stack for your program, that is not solving the stack overflow problem but just delaying it. No matter how many times you split up the stack you can still run out of memory. You can also run out of heap memory. So if you continually crash because of stack overflow, instead of blaming memory for your programming problems, maybe you need to turn a critical eye to the code.

Applications that are ready for the consumer typically handle memory very well and don't run out. You may run out on occassion but at least it's not every single time.

As an aside:

Quote:

---

> How does the computer then deside before runtime how much stack space a program will need?
It kind of doesn't. The stack is pretty much the same size for every program I think. I don't know how to prove it though.

---

Specific to Windows (found on MSDN):

Code:

---

HANDLE CreateThread(
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  SIZE_T dwStackSize,
  LPTHREAD_START_ROUTINE lpStartAddress,
  LPVOID lpParameter,
  DWORD dwCreationFlags,
  LPDWORD lpThreadId
);

---

Quote:

---

dwStackSize
[in] Initial size of the stack, in bytes. The system rounds this value to the nearest page. If this parameter is zero, the new thread uses the default size for the executable. For more information, see Thread Stack Size.
--- (Thread Stack Size)---
Each new thread or fiber receives its own stack space consisting of both reserved and initially committed memory. The reserved memory size represents the total stack allocation in virtual memory. As such, the reserved size is limited to the virtual address range. The initially committed pages do not utilize physical memory until they are referenced; however, they do remove pages from the system total commit limit, which is the size of the page file plus the size of the physical memory. The system commits additional pages from the reserved stack memory as they are needed, until either the stack reaches the reserved size minus one page (which is used as a guard page to prevent stack overflow) or the system is so low on memory that the operation fails.

It is best to choose as small a stack size as possible and commit the stack that is needed for the thread or fiber to run reliably. Every page that is reserved for the stack cannot be used for any other purpose.

A stack is freed when its thread exits. It is not freed if the thread is terminated by another thread.


The default size for the reserved and initially committed stack memory is specified in the executable file header. Thread or fiber creation fails if there is not enough memory to reserve or commit the number of bytes requested. The default stack size used by the linker is 1 MB. To specify a different default stack size for all threads and fibers, use the STACKSIZE statement in the module definition (.def) file. The linker rounds up the specified value to the nearest 4 bytes.

To change the initially committed stack space, use the dwStackSize parameter of the CreateThread, CreateRemoteThread, or CreateFiber function. This value is rounded up to the nearest page. Generally, the reserve size is the default reserve size specified in the executable header. However, if the initially committed size specified by dwStackSize is larger than the default reserve size, the reserve size is this new commit size rounded up to the nearest multiple of 1 MB.

To change the reserved stack size, set the dwCreationFlags parameter of CreateThread or CreateRemoteThread to STACK_SIZE_PARAM_IS_A_RESERVATION and use the dwStackSize parameter. In this case, the initially committed size is the default size specified in the executable header. For fibers, use the dwStackReserveSize parameter of CreateFiberEx. The committed size is specified in the dwStackCommitSize parameter.

The SetThreadStackGuarantee function sets the minimum size of the stack associated with the calling thread or fiber that will be available during any stack overflow exceptions.

---

**EDIT**

Quote:

---

Sufficently huge is always a relitive term. If I have a big program, I'm more likely to run out of stack memmory. If I have a small program, it's wasteing memmory with a large stack.

---

This is an ideal. A 'big' program, i.e. one that comes with 3 install CD's, will not necessarily use more stack space than a 'small one' (100kb standalone exe). In general, I believe the primary cause of increased stack use is function call depth.

If call depth gets larger than say, 50, there's probably something quite wrong with the program architecture (barring recursive algorithms). Say we're pigs and allocate an average of 4kb of buffers in each function call (anything larger goes on the heap since it probably needs to persist, i.e. so you don't have to re-load the data from disk each time you want it). The buffers are much larger than function call overhead, so we will assume that to be negligible. This means we require a maximum of 200kb of stack space in a worst-case scenario for normal operation. Give the app 512kb or 1mb and it should be happy for a long time. I suggest that the *only* way you will run out of stack space is by gross inefficiency (i.e. recursion instead of a loop, for iterating a list, while allocating large stack buffers inside the recursive function).

On the other hand, your system has at least 512mb of RAM, and probably as much swap space. That 'huge' 512kb is 0.1% of your resources. So who cares?

Yeah, I'm going to concead here.

One of the things a had misread/forgot was that Global and static variables are defined in a seperate block of memmory not part of the stack. Although they are still considered "stack variables" they are apparently not part of the same memmory block (at least according to that article).

I still hold however that there is nothing inherrently wrong with storing fixed size array data in static object members such as with Singletons. Object pool example I had earlier included.