Thread: Confused about Memory

  1. #1
    Registered User
    Join Date
    Apr 2005
    Posts
    76

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

  2. #2
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    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.
    Last edited by SlyMaelstrom; 06-17-2006 at 11:08 AM.
    Sent from my iPadŽ

  3. #3
    Registered User
    Join Date
    Apr 2005
    Posts
    76
    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?
    Last edited by gL_nEwB; 06-17-2006 at 11:17 AM.

  4. #4
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    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.
    Sent from my iPadŽ

  5. #5
    Registered User
    Join Date
    Apr 2005
    Posts
    76
    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?

  6. #6
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Last edited by whiteflags; 06-17-2006 at 11:49 AM.

  7. #7
    Registered User
    Join Date
    Apr 2005
    Posts
    76
    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...

  8. #8
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    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.

  9. #9
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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);
    }
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  10. #10
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    > 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.

  11. #11
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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?

    > 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?
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  12. #12
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    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.
    Sent from my iPadŽ

  13. #13
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    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]
    Last edited by whiteflags; 06-17-2006 at 10:26 PM.

  14. #14
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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.

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

    [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++. I sure hope nobody follows it.
    Last edited by King Mir; 06-17-2006 at 11:07 PM.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  15. #15
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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."
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problems with shared memory shmdt() shmctl()
    By Jcarroll in forum C Programming
    Replies: 1
    Last Post: 03-17-2009, 10:48 PM
  2. Replies: 4
    Last Post: 01-13-2008, 02:14 AM
  3. Copying memory, pointers and the like.
    By psychopath in forum C++ Programming
    Replies: 34
    Last Post: 12-12-2006, 01:37 PM
  4. Locating A Segmentation Fault
    By Stack Overflow in forum C Programming
    Replies: 12
    Last Post: 12-14-2004, 01:33 PM
  5. Memory leak trackers
    By Darkness in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 11-30-2004, 02:03 PM