Why do we need heap ?

[DEhqDjzh]

why do we need heap if we can simply do this:

  Player *player;
void createplayer()
{
Player newplayer;
newplayer.health = 100;
newplayer.immortal = false;
player = &newplayer


}

[Peter87]

The newplayer object is destroyed when the createplayer() function ends.

[DEhqDjzh]

but we saved the newplayer to player pointer

[Peter87]

The player pointer points to newplayer but that doesn't prevent the object from being destroyed when the function ends.

[Repeater]

but we saved the newplayer to player pointer

No we didn't.

A pointer-to-Player object is NOT the same as a player object.

A pointer is a number. A single number, representing a memory address. A location in memory.

Player newplayer;
With this line, the Player object "newplayer" was created. It was created somewhere in memory. That place in memory is identifed by a number. For example, 0x40003000. Just a number, identifying a place in memory.

player = &newplayer
With this line, that memory location is stored in the pointer player. It's just a number. So now the pointer has a value. In this example, 0x40003000.

At the end of the function, the Player object is destroyed. It was in memory location 0x40003000. Now, that memory can be reused and something else put there.

The pointer hasn't changed. The pointer, which is just a number, is still the number 0x40003000. So when you use that pointer, and look in the memory at location 0x40003000, what's there? Could be anything. The object newplayer has been destructed and the memory location 0x40003000 is available for reuse.

[JLBorges]

From 'Accelerated C++: Practical Programming by Example' by Andrew Koenig and Barbara E. Moo
(Chapter 10. Managing memory and low-level data structures)

10.6 Three kinds of memory management

So far, we have seen two distinct kinds of memory management, although we have not discussed them explicitly. The first kind is usually called automatic memory management, and is associated with local variables: A local variable occupies memory that the system allocates when it encounters the variable's definition during execution. The system automatically deallocates that memory at the end of the block that contains the definition.

Once a variable has been deallocated, any pointers to it become invalid. It is the programmer's responsibility to avoid using such invalid pointers. For example,

// this function deliberately yields an invalid pointer.
// it is intended as a negative example—don't do this!
int* invalid_pointer()
{
    int x;
    return &x; // instant disaster!
}

This function returns the address of the local variable x. Unfortunately, when the function returns, doing so ends execution of the block that contains the definition of x, which deallocates x. The pointer that &x created is now invalid, but the function tries to return it anyway. What happens at this point is anybody's guess. In particular, C++ implementations are not required to diagnose the error—you get what you get.

If we want to return the address of a variable such as x, one way to do so is to use the other kind of memory management, by asking for x to be statically allocated:

// This function is completely legitimate.
int* pointer_to_static()
{
    static int x;
    return &x;
}

By saying that x is static, we are saying that we want to allocate it once, and only once, at some point before the first time that pointer_to_static is ever called, and that we do not want to deallocate it as long as our program runs. There is nothing wrong with returning the address of a static variable; the pointer will be valid as long as the program runs, and it will be irrelevant afterward.

However, static allocation has the potential disadvantage that every call to pointer_to_static will return a pointer to the same object! Suppose we want to define a function such that each time we call it, we get a pointer to a brand new object, which stays around until we decide that we no longer want it. To do so, we use dynamic allocation, which we request by using the new and delete keywords.

[DEhqDjzh]

@repeater
but in visual studio when i try to go address of newplayer object it gives me health as result even its out of scope ?

[doug4]

but in visual studio when i try to go address of newplayer object it gives me health as result even its out of scope ?

Remember that @Repeater stated:

At the end of the function, the Player object is destroyed. It was in memory location 0x40003000. Now, that memory can be reused and something else put there.

The memory can be reused for something else, but if there is no immediate need for the memory, it may remain untouched. You have a pointer pointing to the block of memory which was deallocated but not yet reused by the program. You happen to see "valid" data referring to what was contained before the object was deallocated. You got lucky and saw the health you were looking for.

However, this is not behavior to depend on. When the program re-allocates the block at 0x40003000 (in this example), the memory will get overwritten, and you will get corrupted results.