Thread: Confused about Memory

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.

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

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."

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);
}

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?

> 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.

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]

As an aside:

> 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
);

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**

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?