Just wondering, if I statically create an object that has a pointer as a data member and then the object goes out of scope, what happens to the pointer?
Chuma
Nothing happens to the pointer at all, it just ceases to exist. If it was pointing to something that needed to be freed, you just got a memory leak.
Either add code to the destructor that does the proper cleanup of the pointer, or use "smart pointers" that clean up after themselves automatically.
Edit: If you actually meant you were creating a static object, by declaring it with the static keyword inside a function, then the answer is different. A static object, once constructed by the first execution of the function that declares it, continues to live until the program ends. Its data members, including pointers, will remain valid. Subsequent calls to the function will access the same object. If the object has allocated any memory, it will remain allocated unless something explicitly deletes it.
The pointer gets destroyed with the rest of your object. Whatever it was pointing at isn't affected at all (unless the object's destructor does something with it).
Revised answer
There are two properties of a variable which are relevant here - scope and lifetime - and I think the question is conflating the two.
In all the contexts I can think of, a statically allocated object has a lifetime that is essentially the lifetime of the process. There are some technical details about exactly when the object is first initialized (constructed), but the net result is essentially the same - a statically allocated object exists for the duration of the process.
However, an object may come into scope, and go out of scope, as the thread of control moves between functions in the program. The scope of the object is where it is visible by name. It may be accessible elsewhere if a pointer to it (or reference to it) is passed to other functions where it would not otherwise be in scope.
Since a statically allocated object has a lifetime of the duration of the program, pointer members of that object do not change because the object goes out of scope; the object continues to exist unchanged, and the pointer members continue to point to the same place. Clearly, if a pointer in the statically allocated object points to a variable that had automatic duration and that pointed-to variable ceases to exist because it is destroyed, then the pointer in the statically allocated object points to an invalid location.
However, the key point is that the statically allocated object is not changed, and the pointer members are not changed, but changes in scope. And there are no leaks caused by the changes in scope.
Original answer
In all the contexts I can think of, a statically allocated object can't go out of scope, pretty much by definition. I suppose that if a shared library was loaded and then unloaded, then a statically allocated object might go 'out of scope', but otherwise...
If this premise is correct, then the second half of the question is easy. You can take either of two views:
Since the static object never goes out of scope, nothing happens to the static object and its pointer member, and it will be pointing to the same place when the object comes back into scope - where scope here means 'into a function that could access the static object'.
When the thread of control leaves a scope that could access the static object, nothing happens to the static object and its pointer member, and it will be pointing to the same place when the object next comes back into scope.
Which is basically saying the same thing, twice. If I said it a third time, it would automatically be true, wouldn't it? So, a statically allocated object doesn't go out of scope (even if it is not always accessible from the current function) and so nothing happens to the pointer members. There...what I said is so. I think!
What am I missing? Does 'statically created object' have a meaning I've not thought of?
Related
I have a few questions regarding dynamic variables and pointers so I can understand them better.
Are dynamic variables automatically disposed of when their scope expires? If not, then what happens?
Is the value of a pointer a memory address? If not, then what are they?
It's important to understand that there two complete separate, discreet, independent "things" that you are asking about.
A pointer to an object that was created in dynamic scope (i.e. with the new statement).
And the object itself, that the pointer is pointing to.
It's important for you two separate the two in your mind, and consider them as independent entities, in of themselves. Insofar as the actual pointer itself, its lifetime and scope are no different than any other object's. When it goes out of scope it gets destroyed.
But this has no effect on the object the pointer was pointing to. Only delete destroys the object. If there's some other pointer, that's still in scope, that points to the same object, you can use that pointer for the requisite delete.
Otherwise you end up with a memory leak.
And the value of the pointer is, for all practical purposes, a memory address. This is not specified in any form or fashion in the C++ standard, which defines pointers and objects in dynamic scope in terms of how their behavior is specified. However on all run-of-the-mill operating systems you'll see a memory address in the pointer.
It's also important to understand that since a pointer is an independent object, a pointer doesn't have to point to an object in dynamic scope. There are many pointers that don't. It's not a trivial task to keep track of all objects, all pointers, and to figure out which ones need to be deleted properly. Modern C++ has additional classes and templates that will help you do that, which you'll learn about in due time.
This is an educational question:
If I have created a class
class bank_account
And in the main function, I declared
bank_account *pointer = new bank_account();
Then I am initializing variables such as follows
(*pointer).account_name ="Random Name";
My confusion is what is happening here because I usually declare an object with a NAME, not a pointer, if that object is a pointer, and a pointer is just some variable which holds an address to a variable. What does it mean if a pointer is declared as an object and what it is actually representing? Is the pointer to an object is referring to an invisible object?
and a pointer is just some variable which holds an address to a variable
Correction: A pointer can point at any object; Not necessarily a variable. Variables have names. There can be objects that are not directly named by a variable such as sub-objects, temporaries, and objects in dynamic storage.
In your program for example, the expression new bank_account() creates an object in dynamic storage.
What does it mean if a pointer is declared as an object
It's really unclear what you mean by "declared as an object". If you declare a pointer to have the type bank_account*, it means that it can point at an object of type bank_account, which happens to be a class.
If you declare a variable to have a pointer type, then the object named by the variable is a pointer.
and what it is actually representing?
A pointer represents the address of an object. Besides containing an address of an object, it can also have the null pointer value (which points to no object) or it can have an invalid value (an address that may have contained an object, but that object no longer exists).
Then I am initializing variables such as follows
(*pointer).account_name ="Random Name";
To be pedantic, this technically does not initialise a variable. Initialisation is performed on objects when they are created. This member variable has been created earlier and this expression assigns a value to it. But if the variable is previously uninitialised, then colloquially speaking, it would not be terribly wrong to talk about initialisation.
when I declare an object as pointer what is the pointer pointing to?
In your example program, pointer points to an object that was created in dynamic storage, using the keyword new.
In general, pointer points at some object whose address is stored in the pointer, or a pointer might not point at an object at all (invalid, or null value).
You said an object is created
Yes. The new-expression creates an object in dynamic storage.
but I declared a pointer
Yes. You did.
so the pointer is pointing to the object?
You've initialised the value of the pointer with the result of the new-expression. The pointer points at the object that was created in dynamic storage.
and what is the name of that object then?
Objects do not have names. However: Variables do have names, and variables are associated with an object, so one could colloquially say that those objects associated with a variable have a name. But objects in dynamic storage are not named by a variable.
a pointer is a variable which contains an address of another variable. Any pointer uses space in memory needed to keep the address. on 64-bit platforms it usually needs 8 bytes.
When you create an class object, it also is resided in memory and occupies as many bytes as it needs. The pointer gets assigned a value of the address of this class object.
bank_account *pointer = new bank_account();
The above declares a pointer to the object of type bank_account. new allocates space for the object in the memory and returns its address. It also calls a constructor of the class. The address returned by the new gets assigned to the pointer variable named pointer. Later you can use it to access the object as
(*pointer).account_name ="Random Name";
or equivalently
pointer->account_name ="Random Name";
pointer is just an address. Pointer type is just a syntactic sugar which allows the compiler to do its job and to provide you with useful information about your program.
A pointer is a variable that holds a memory address, and it exists wherever it is pointing to something that makes sense or not, meaning you can declare this pointer and not necessarily instance an object for it to point to, it can just point to nullptr which generally signifies the object does not exist at that moment. This alone is useful. You can use it as place holder or to keep track of the program's state.
Another property is that it can point to an array of objects, so you may use it to create a dynamic number of objects at once instead of just one or a predetermined number of objects.
But the most important property is that the object you instance with new does not belong to that particular scope, if the function ends it will not be automatically deleted. This object can be created in a subroutine and then exist throughout the program's life or until you delete it, and all you have to do to pass this object around is pass it's pointer, which is a quite small piece of data compared to doing something silly like copying the object around, this is huge for performance.
You have to pay attention to memory leaks though. Since this object is not deleted automatically, you have to do it yourself when necessary, otherwise the longer the program runs, more memory it will use until it runs out of it.
You can also have multiple pointers pointing to the same place, which is very useful when iterating through linked lists, arrays and all sorts of structures, so a pointer's purpose doesn't necessarily have to be that of holding a specific object, but that of a tool to browse data in memory efficiently.
As objects are created from same class. Each object contains the variable defined in the class except those which are defined in the methods of that class. Variable in functions of the same object are shared memory right? If we have a function where we create an object of the same class, where will be the reference reside? Isnt that reference be shared too?
Methods are no different from any other function with regard to memory use: local variables are created when execution reaches their declaration, and (unless static) they are destroyed, and their memory reclaimed, when execution leaves the block it. (This happens, at latest, when the function returns.) There is no connection to the this object or any of its members. Nor does the variable having the same type as the method’s class make any difference.
In some sense, that does make the memory “shared”: it will be rapidly reclaimed and (typically) reused. But that’s nothing special, and don’t think that it means more than it does: if a method is recursive, or invoked concurrently by more than one thread, each copy has its own locals—again, just like any other function.
Finally, any function or method can allocate memory dynamically; the lifetime and sharing of the allocated object may be unrelated to that of the variable used to refer to it.
I am writing a quad tree which stores pointers to collidable objects in an stl list.
I want the quad tree to be able to move the objects from node to node depending on their position in the world, and would like to just get something confirmed:
If I remove the pointer from the list, to insert the object into another tree node (such as the parent tree node), will the destructor for the pointed-to object be called? For clarification, I do not want the object destroyed, as it is used & managed elsewhere in the program.
Thanks, in advance.
The actual object in the list (i.e. the pointer) will be destructed, but not what the pointer points to.
It might be a little confusing to begin with, but if you see the pointer, and what it points to, as completely separate entities it makes a lot more sense.
The destruction of an object is determined by its storage duration. If an object has automatic storage duration (like a local variable), it will be destroyed when it goes out of scope. If an object is dynamically allocated (using new), it will only be destroyed when you do delete on it. If it has static storage duration, it will be destroyed when the program ends.
If you are just copying the pointer out of one node and into another and as long as the object it points at hasn't been destroyed according to the above rules, the pointer will continue to point at the same valid object.
no, destructors are never called on pointers in STL. It only gets destroyed when you call delete explicitly on the object pointed to (or if the object when stored on the stack goes out of scope) or if you use smart pointers.
I'm not sure if what you say will happen, but anyway it might be a good practise to reset your pointer to NULL before deleting the instance. Also, remember to make the pointed-object to be pointed by the correct node, that probably will be the node that was pointing to the node you erased.
Assume I have a function like this:
MyClass &MyFunction(void)
{
static MyClass *ptr = 0;
if (ptr == 0)
ptr = new MyClass;
return MyClass;
}
The question is at program exit time, will the ptr variable ever become invalid (i.e. the contents of that ptr are cleaned up by the exiting process)? I realize that this function leaks, but it is only an example for simplicity.
The same question also applies to other primitives besides pointers as well. How about if I have a static integer, does the value of that integer always persist throughout exit or is variable due to static destruction order issues?
EDIT:
Just to clarify, I want to know what actually happens to the contents of the static pointer (or any other primitive type like an int or a float) and not to the memory it is pointing to. For instance, imagine that the ptr points to some memory address which I want to check in the destructor of some other static class. Can I rely on the fact that the contents of the ptr won't be changed (i.e. that the pointer value won't be cleaned up during the static destruction process)?
Thanks,
Joe
When you process exits the all memory pages allocated to it will be freed by the OS (modulo shared memory pages that someone else may be using).
However, as others point out the destructor for MyClass is never called. Nor is the value pointed to by ptr ever changed. If you have a static int with the value 123 then its value will stay 123 through to the very end of the process' lifetime.
In modern operating systems, all of an application's memory is allocated on a "heap" specific to that application. When the application exits, all of the memory in that heap will be freed.
So, the memory will be deallocated, but: the destructor for MyClass will never be called. This can be an issue if the destructor is responsible for releasing any non-memory resources (file system locks are a common example).
To answer your question:
'imagine that the ptr points to some memory address which I want to check in the destructor of some other static class'
The answer is yes.
You can see the value of the pointer (the address).
You can look at the content if you have not called delete on the pointer.
Static function variables behave in the same way as static class variables and global variables (aka non local static), in that there destructors will be called in reverse order of creation. Integers, floats and pointers (POD) do not have destructors so nothing happens to them until the processes is removed.
POD objects: Data can safely by referenced from the destructor of other objects (even global s).
Other static objects (i.e. those with destructors): In the general case, it is not safe to accesses these objects after main() has exited because the order of destruction is not know (it is the reverse of the order of creation, but the order of creation is complex see: Construction Order ). It can be done but you have to take explicit precautions to make sure the object is still alive.
Note: non local static:
The memory will always be there, the object will just not be valid after a destructor is called (note POD does not have a destructor).
Note: Stack:
Only valid until the scope in which they are declared is left.
After the stack is popped the memory page that it is on could potentially be dropped resulting in SEG faults if you attempt to access it.
Note: Heap:
Valid until you call delete on the pointer that allocated it.
Once a pointer is delete the value is potentially random as it may be re-used.
Potentially the page the memory was on can also be dropped. Any access to a dropped page would result in a SEG fault.
To answer your updated question, I would say yes: you can rely on the value of that static pointer remaining throughout the static destruction process. The memory it points to may have been freed, but the value of the pointer itself should remain unchanged, unless the destructor of another static class makes a change to it.
The short answer is "no": your pointer will not "become invalid" at program exit time. I.e. the pointer value will not automatically be reset to null, and destructor of the MyClass object to which it points will not automatically be called.
This is because a pointer is a "primitive type", i.e. not an object.
If you have a non-local (i.e. global or static) variable which is an object, then the rules are different: the destructor of the object will be called when the program terminates by calling exit() or by returning from the main function. It will not be called if the program terminates by calling abort().