What is the result of the following piece of code? What does it mean?
I am studying C ++ / OOP exam and am a little confused about this question in my practice test.
What is the result of the following piece of code?
int *list = new int[5];
int *ptr;
for (int i = 0; i < 5; i ++)
list [ i] = i+ 1;
ptr = list;
delete [ ] list;
cout << *ptr
- 1
- List address
- Ptr address
- Error - ptr refers to memory that no longer belongs to the program
I found the output which is -17891602, but am I correct in assuming that this is just a memory reference that no longer belongs to the program? Because I don't necessarily get the error.
It's been a while since I've been working with pointers, so I get but get twisted trying to figure out what the code is actually doing. (I know this is easy compared to some of the things you guys are working on, but I'm just starting to learn this stuff :))
source to share
The output can be anything (including -17891602
), since you are invoking undefined behavior by dereferencing the pointer that had its spare memory freed.
The relevant part of the standard C++11 3.7.4.2 Deallocation functions /4
(my bold font):
If the argument assigned to the disadaptation function in the standard library is a pointer that is not a null pointer value, the deallocation function frees the storage the pointer refers to, rendering is invalid for all pointers referencing any part of the freed storage. The effect of using an invalid pointer value (including passing it to the delete function) is undefined.
On my system, the following program (simulated from your snippet):
#include <iostream>
int main (void) {
int *list = new int[5];
int *ptr;
for (int i = 0; i < 5; i ++)
list [ i] = i+ 1;
ptr = list;
delete [ ] list;
std::cout << *ptr;
return 0;
}
outputs 1
, but it is by no means required.
The correct answer to your question is most likely 4, although this is not technically an output (you may not see the "error" line posted to the output stream) - this is, however, the result of running the code.
source to share
I wasn't going to get sucked into this, but HostileFork's answer (which I + 1ed) forked out, skipping a couple of points - too many to comment, so here I am ...
First, the question:
What is the result of the following piece of code?
For a given code, the output can be anything or nothing that is not one of the answers. However, the intended answer is obviously 4:
Error - ptr refers to memory that no longer belongs to the program
That said:
-
the memory is probably still owned by the program / process (most C ++ implementations do not free the memory used to satisfy small memory allocations for the OS until the program terminates), but it is no longer "owned" by the application - the level code you specified, as it
delete[]
returns the property to the memory allocation library -
the problem is not only that the references
ptr
, but in particular what is beingptr
dereferenced, pointing to the freed memory
In short, the question is loosely phrased, but the intent behind it is pretty clear.
I will not repeat the explanation of undefined behavior that addresses your "Because I am not necessarily getting an error". since HostileFork's answer does it well.
However, computer programs do not tend to do anything out of the ordinary, even if the compiler is not obligated by the C ++ standard to provide any particular behavior, and in this particular case, the observation I made above is the memory that the program still owns. coupled with the remark that the executable value *ptr
before delete[] list;
should be 1
leads to the question ...
Why did you see -17891602 and not 1?
Pending, I converted it to unsigned 32-bit hex (like everything): then value FEEEFEEE
. Wikipedia says about this "magic number" :
Used by Microsoft debug HeapFree () to mark freed heap memory.
So, a Microsoft function delete[]
caused the five int
locations to be overwritten with 0xFEEEFEEE
to make it easier for you, the programmer, to see that you had undefined behavior. Since overwriting memory takes time while the program is running, and this is only useful if the program actually broke anyway, which you hopefully understand and fix before building and distributing the "release" build, this FEEEFEEE
-fill behavior is done only in MS debug builds. Other compilers or malloc libraries often offer similar behavior, enabled via compiler flags / environment variables, etc.
source to share
The person writing this question either does not understand or does not write well. It could be fixed by inserting one word on each line:
- Definitely 1
- Definitely Address List
- Definitely ptr address
- Programmer error - ptr refers to memory that no longer belongs to the program
The problem affects something called "Undefined Behavior", which you can read about here:
https://softwareengineering.stackexchange.com/questions/99692/philosophy-behind-undefined-behavior
This sets out some of the reasons why, for example, the compiler didn't give you a "compile-time error" or "run-time exception". It is a mistake that it is generally impossible to detect a priori, and that runtime checking would add unwanted overhead.
source to share