reference operator following return type?

This is a discussion on reference operator following return type? within the C++ Programming forums, part of the General Programming Boards category; Ah, thanks guys....

  1. #16
    Registered User
    Join Date
    Jun 2008
    Posts
    14
    Ah, thanks guys.

  2. #17
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,625
    Quote Originally Posted by pantherse View Post
    should have printed "1", which is the value of x that was passed to func() but it didn't. What happened is that the execution of func() completed and returned the memory address that "a" used to occupy. However, before the value was printed your kernel decided that it'll put your program on hold, and let another process run. For whatever reason, the kernel gave the memory address that func() returned to that process who wrote something else in the same location. So instead of you getting 1 in your output you got whatever that value was.
    That's not true (not for modern operating systems anyway).
    Why? Because Virtual Memory separates memory for each process. That means the kernel CAN'T give away the memory location in your program to some other program. The other program writes somewhere else.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by thracian View Post
    what do you mean by reference? isn't a pointer a reference?
    Stop here, and go back to your book.

  4. #19
    Registered User
    Join Date
    Jun 2008
    Posts
    17
    Quote Originally Posted by Elysia View Post
    That's not true (not for modern operating systems anyway).
    Why? Because Virtual Memory separates memory for each process. That means the kernel CAN'T give away the memory location in your program to some other program. The other program writes somewhere else.
    Elysia, you are correct. However, it is still possible for a Virtual Memory location to be in one physical location one second, and be relocated by the OS the next. I can get back to you once I get home if you want more details. I don't have my OS theory book on me.

  5. #20
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by pantherse View Post
    Elysia, you are correct. However, it is still possible for a Virtual Memory location to be in one physical location one second, and be relocated by the OS the next. I can get back to you once I get home if you want more details. I don't have my OS theory book on me.
    Sure, that happens all the time, but the application itself still can't give that memory to any other application (unless it is asking the OS nicely to share it between the two apps).

    Also, if the OS swaps the physical location of the memory, it's the OS's responsibility to make sure that the page being swapped is not being used at the exact moment it is being replaced. So the contents of a memory page should (assuming the OS is bug-free) always be consistent with what the application can expect. So if a value is written to a particular memory location, and the physical memory is being relocated or some such, the same value should be found in the same virtual location after the relocation is done. This is of course tricky stuff, and doing such operations require good understanding of what the machine does, and understanding what processes are able to access such a page, and ensuring that any process that may be accessing that memory is blocked (not running), or things will go (very horribly) wrong in a hurry.

    So whether the memory is being "moved" or not, it should have it's content valid whenever the memory is available (if it's not immediately available, the application will cause a page-fault, and the PF handler will block the process, fix up the page so it has it's valid content before making the process runnable again).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #21
    Registered User
    Join Date
    Jun 2008
    Posts
    17
    Sure, that happens all the time, but the application itself still can't give that memory to any other application (unless it is asking the OS nicely to share it between the two apps).

    Also, if the OS swaps the physical location of the memory, it's the OS's responsibility to make sure that the page being swapped is not being used at the exact moment it is being replaced. So the contents of a memory page should (assuming the OS is bug-free) always be consistent with what the application can expect. So if a value is written to a particular memory location, and the physical memory is being relocated or some such, the same value should be found in the same virtual location after the relocation is done. This is of course tricky stuff, and doing such operations require good understanding of what the machine does, and understanding what processes are able to access such a page, and ensuring that any process that may be accessing that memory is blocked (not running), or things will go (very horribly) wrong in a hurry.

    So whether the memory is being "moved" or not, it should have it's content valid whenever the memory is available (if it's not immediately available, the application will cause a page-fault, and the PF handler will block the process, fix up the page so it has it's valid content before making the process runnable again).
    Ok, so now I'm the one who has a question: In the case of the sample code, the variable "a" has been deallocated since func() has already gone out of scope. The OS doesn't have to necessarily guarantee the content of that memory location correct?

  7. #22
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    A local variable lives on the stack. It is unlikely (although not ENTIRELY impossible) that the OS will deallocate the stack - in which case you would get a page-fault for it being unavailable when it's returned from the function - and if the OS decided that the stack is no longer neede there [unless the stack is grown in an official way, such as calling a function again], then the application would just crash. I do not know of any OS that deallocates the stack after it has shrunk - it will swap it out to disk after it has been out of use for some time, but not deallocate it.

    The more likely scenario is that the same area of stack is used by another function, which overwrites the location returned by func(), and the stack content is now something completely different - so the value of "the reference to a" will change at random[1], possibly many times if you call different functions (or the same function with different values). That is because the memory location on the stack that held a whilst in the function, gets re-used for whatever purpose the code wants to use it for when you call those other functions - and that may change if you compile the code with a different compiler or even different compiler switches.

    [1] Not random like a random number generator, but random in relation to what you may expect by just looking at the function itself if you didn't realize it was returning a reference to a local variable that will go out of scope.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #23
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,625
    A likely scenario might be:
    Code:
    int* foo()
    {
        int x = 0;
        return &x;
    }
    
    int main()
    {
        int* x = foo();
        cout << *x << endl; // It's likely the value is still intact here.
    }
    However, when we take the following:
    Code:
    int* foo()
    {
        int x = 0;
        return &x;
    }
    
    int main()
    {
        int* x = foo();
        int y = 1000;
        cout << *x << endl; // You'll probably see 1000 here, instead of 0.
        cout << y << endl;
    }
    We see that "y" overwrites the data stored in the local variable x inside foo.
    This is not guaranteed and should not be relied upon in any sort of way.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  2. Another weird error
    By rwmarsh in forum Game Programming
    Replies: 4
    Last Post: 09-24-2006, 10:00 PM
  3. Please Help - Problem with Compilers
    By toonlover in forum C++ Programming
    Replies: 5
    Last Post: 07-23-2005, 10:03 AM
  4. problem with open gl engine.
    By gell10 in forum Game Programming
    Replies: 1
    Last Post: 08-21-2003, 04:10 AM
  5. Dynamic list of Objects in External File
    By TechWins in forum C++ Programming
    Replies: 3
    Last Post: 12-18-2002, 01:05 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21