So I have a class called List which stores a vector of pointers to classes of type Object. List has a function called add which initialises an Object class and adds it's pointer to the vector. I thought that once the add function ended that the Object class would be destroyed and accessing the pointer would cause an exception. When I wrote a test program to test this it turned out that the Object class was never destroyed.
Are classes initialised inside a function ever destroyed once the function ends?
When are classes automatically destroyed?
Depends how you're creating the object. If you are doing it like this:
void add() {
Object obj;
vec.push_back(&obj);
}
Then you are creating obj with automatic storage duration. That means it will be destroyed when the add function ends. The pointer you have pushed into the vector will no longer point to a valid Object, so definitely don't do this.
You may, however, be doing this:
void add() {
Object* obj = new Object();
vec.push_back(obj);
}
If you are, you are creating the Object with dynamic storage duration and it will not be destroyed at the end of the function. The pointer you push into the vector will remain valid. However, if you do this, you need to remember to delete the object at a later time. If you don't, you'll have a leak.
The best option is to avoid using pointers at all, if you can. Just make the vector a std::vector<Object> and copy objects into it:
void add() {
vec.push_back(Object());
}
Or in C++11:
void add() {
vec.emplace_back();
}
If you really need pointers, prefer smart pointers.
In C++, if you don't use any memory manager, smart pointers or some kind of "managed" environment, classes created using keyword new. To avoid misunderstanding could you please post constructor of Object and method List.Add?
So, when you are creating new object like:
Object* o = new Object();
you reserving space in the heap and store pointer to that space in pointer 'o'. If you never calling
delete o;
explicitly your object will never deleted.
Related
I'm new to C++, and I want to know, does a pointer gets automatically deleted when the class gets deleted / destroyed? Here is an example:
class A
{
public:
Object* b;
};
Will b get `deleted when the class is deleted?
The object that the pointer points to will not be deleted. That is why it is a bad idea to use a raw pointer to refer to an object created with dynamic storage duration (i.e. via new) like this if the class object is intended to be responsible for destroying that object. Instead use std::unique_ptr:
#include<memory>
//...
class A
{
public:
std::unique_ptr<Object> b;
};
And instead of new Object(/*args*/) use std::make_unique<Object>(/*args*/) to create the object and a smart pointer to the object to store to b.
Or, most likely, there is no reason to use a pointer indirection at all. You can have a Object directly in the class. (This only really doesn't work if Object is meant to be polymorphic.)
The memory reserved for the pointer itself is freed, so in that sense, b is 'deleted'. However, if b is not set to nullptr (any any object that b points appropriately dealt with) before b is deleted, then you will likely have a memory leak.
To sum up: the pointer itself will be deleted when the object is destroyed, but nothing will happen to the object that the pointer is pointing to. You will want to create an appropriate destructor to handle this.
No, for the simple reason that nothing says that the pointer was used to allocate data: there is no implicit new in the constructor, and maybe the pointer is not used for dynamic allocation at all but for other purposes.
An extra reason is that in your use case it could be undesirable to delete the pointed data, which might be shared elsewhere for instance.
In general, I always pass pointers through functions of any objects I create; if I need something done to an object, I would pass it by pointer rather than by reference. That's just a programming habit which some might describe as miniscule; but this is where I have to ask by example:
class someObject
{
public:
someObject();
~someObject();
void do(const char* smth)
{
cout << smth << endl;
}
private:
};
class doObject
{
public:
doObject();
~doObject();
void takeObject(someObject *so)
{
pObject = so;
so->do("Hi");
}
private:
someObject *pObject;
}
And in main.cpp:
int main()
{
someObject *so = new someObject();
so->do();
doObject *do = new doObject();
do->takeObject(so);
delete so;
delete do;
}
Should memory be allocated to doObject::pObject BEFORE it is assigned the pointer parameter so of type someObject?
If pObject is assigned the foresaid parameter, should it be deleted; e.g. delete pObject?
In main.cpp someObject is deleted BEFORE doObject is. This is vital to understand because doObject has an assignment of someObject called pObject. Deleting someObject before doObject means there's a dangling pointer which implies any actions on it would produce a segmentation fault.
If I delete doObject first in main.cpp, does that also delete pObject AS WELL AS 'so' of type someObject? After all, they are linked.
If I create a new class that also a function which also requires a parameter of someObject, does that mean pObject no longer points to 'so'? Should I instead use a shared pointer so that it's possible for both classes to be able to point to 'so' and change the object as necessary?
How can the code be improved? Should I consider the use of smart pointers to ensure that I do not delete an object more than once in various parts of a program?
Yes, the question is rather complex; but that's what you get with pointers!
Should memory be allocated to doObject::pObject BEFORE it is assigned the pointer parameter so of type someObject?
Memory is allocated in main and a pointer to that memory is assigned to so. The member variable pObject will just point at the same object as so does. So memory is allocated before you assigne the member pointer variable.
If pObject is assigned the foresaid parameter, should it be deleted; e.g. delete pObject?
Someone must delete the object pointed at to not get a memory leak. Either someone does it or the ownership is shared. You decide if you transfer the ownership when you pass the pointer to another function, or not. Being consistent is the key and using smart pointers is a help.
In main.cpp someObject is deleted BEFORE doObject is. This is vital to understand because doObject has an assignment of someObject called pObject. Deleting someObject before doObject means there's a dangling pointer which implies any actions on it would produce a segmentation fault.
If you allocate dynamic memory, always deallocate in reverse allocation order to prevent dangling pointers.
If I delete doObject first in main.cpp, does that also delete pObject AS WELL AS 'so' of type someObject? After all, they are linked.
No. If the doObject destructor had done delete pObject;, then it would.
If I create a new class that also a function which also requires a parameter of someObject, does that mean pObject no longer points to 'so'? Should I instead use a shared pointer so that it's possible for both classes to be able to point to 'so' and change the object as necessary?
pObject doesn't point at so, it points at the same dynamically allocated object as so does. Any number of pointers to that object can exist in any number of classes, but it's your resonsibility to make sure that after the object is deleed, no holder of a pointer to it uses that pointer. That's why it's important to dlete objects in the correct order.
How can the code be improved? Should I consider the use of smart pointers to ensure that I do not delete an object more than once in various parts of a program?
Yes, smart pointers if you want to share the ownership (shared_ptr) or ensure there's just one owner (unique_ptr), or have the guideline that a pointer parameter is only referring to an instance, never owning.
Also use automatic instances where possible instead of dynamic.
How can the code be improved? Should I consider the use of smart pointers to ensure that I do not delete an object more than once in various parts of a program?
I'd recommend learning manual memory management first and once you've mastered it, then start using smart pointers. But of course you can jump straight into smart pointers if you think you don't need to know manual memory management.
As far as I know, I should destroy in destructors everything I created with new and close opened filestreams and other streams.
However, I have some doubts about other objects in C++:
std::vector and std::strings: Are they destroyed automatically?
If I have something like
std::vector<myClass*>
of pointers to classes. What happens when the vector destructor is called?
Would it call automatically the destructor of myClass? Or only the vector is destroyed but all the Objects it contains are still existant in the memory?
What happens if I have a pointer to another class inside a class, say:
class A {
ClassB* B;
}
and Class A is destroyed at some point in the code. Will Class B be destroyed too or just the pointer and class B will be still existent somewhere in the memory?
std::vector and std::strings: Are they destroyed automatically?
Yes (assuming member variables are not pointers to std::vector and std::string).
If I have something like std::vector what happens when the vector destructor is called?
Would it call automatically the destructor of myClass? Or only the vector is destroyed but all the Objects it contains are still existant in the memory?
If vector<MyClass> then all objects contained in the vector will be destroyed. If vector<MyClass*> then all objects must be explicitly deleted (assuming the class being destructed owns the objects in the vector). A third alternative is vector of smart pointers, like vector<shared_ptr<MyClass>>, in which case the elements of the vector do not need to be explictly deleted.
What happens if I have a pointer to another class inside a class
The B must be explicitly deleted. Again, a smart pointer could be used to handle the destruction of B.
You only need to worry about for the memory you have created dynamically (When you reserve memory with new.)
For example:
Class Myclass{
private:
char* ptr;
public:
~Myclass() {delete[] ptr;};
}
if they are in automatic storage, yes. You can have std::string* s = new std::string, in which case you have to delete it yourself.
nothing, you need to manually delete memory you own (for memory allocated with new).
if you allocated b with new, you should destroy it in the destructor explicitly.
A good rule of thumb is to use a delete/delete[] for each new/new[] you have in your code.
A better rule of thumb is to use RAII, and use smart pointers instead of raw pointers.
It depends. std::vector and std::string and MyClass all have 1 thing in common - if you declare a variable to be any of those types, then it will be allocated on stack, be local to the current block you're in, and be destructed when that block ends.
E.g.
{
std::vector<std::string> a;
std::string b;
MyClass c;
} //at this point, first c will be destroyed, then b, then all strings in a, then a.
If you get to pointers, you guessed correctly: Only the memory the pointer itself occupies (usually a 4 byte integer) will be automatically freed upon leaving scope. Nothing happens to the memory pointed to unless you explicitly delete it (whether it's in a vector or not). If you have a class that contains pointers to other objects you may have to delete them in the destructor (depending on whether or not that class owns those objects). Note that in C++11 there are pointer classes (called smart pointers) that let you treat pointers in a similar fashion to 'normal' objects:
Ex:
{
std::unique_ptr<std::string> a = make_unique<std::string>("Hello World");
function_that_wants_string_ptr(a.get());
} //here a will call delete on it's internal string ptr and then be destroyed
If I have something like std::vector what happens when the vector destructor is called?
It depends.
If you have a vector of values std::vector <MyClass>, then the destructor of the vector calls the destructor for every instance of MyClass in the vector.
If you have a vector of pointers std::vector <MyClass*>, then you're responsible for deleting the instances of MyClass.
What happens if I have a pointer to another class inside a class
ClassB instance would remain in memory. Possible ways to have ClassA destructor to make the job for you are to make B an instance member or a smart pointer.
std::vector, std::string and as far as I know all other STL containers have automatic destructors. This is the reason why it is often better to use these containers instead of new and delete since you will prevent memory leaks.
Your myClass destructor will only be called if your vector is a vector of myClass objects (std::vector< myClass >) instead of a vector of pointers to myClass objects (std::vector< myClass* >).
In the first case the destructor of std::vector will also call the destructor of myClass for each of its elements; in the second case the destructor of std::vector will call the destructor of myClass*, which means it will free the space taken to store each pointer but will not free the space taken to store the myClass objects themselves.
The Class B objects you point to will not be destroyed, but the space assigned to store its pointer will be freed.
Yes. std::vector and std::stringare automatically when they finish out of scope, calling also the destructor of the objects contained (for std::vector).
As said before, std::vectoris destroyed when it finish out of scope, calling the destructor of the objects contained. But in fact, in this case, the objects contained are the pointers, not the object pointed by the pointers. So you have to delete them manually.
The same as (2). A will be destroyed and so the pointer, but not the class B pointed. You have to provide a destructor for A that delete B.
In C++11 there is a very useful solution: use std::unique_pointer. Can be use only to point a single object and this will be deleted when the pointer goes out of scope (for example when you destroy your std::vector).
http://en.cppreference.com/w/cpp/memory/unique_ptr
Example:
Class *_obj1;
Class *_obj2;
void doThis(Class *obj) {}
void create() {
Class *obj1 = new Class();
Class obj2;
doThis(obj1);
doThis(&obj2);
_obj1 = obj1;
_obj2 = &obj2;
}
int main (int argc, const char * argv[]) {
create();
_obj1->doSomething();
_obj2->doSomething();
return 0;
}
This creates 2 objects, creates pointers to them, then main() calls a method on each. The Class object creates a char* and stores the C string "Hello!" in it; the ~Class() deallocator frees the memory. The doSomething() method prints out "buff: %s" using printf(). Simple enough. Now if we run it we get this:
Dealloc
Buff: Hello!
Buff: ¯ø_ˇ
Obviously the stack object does not work here - it's obvious that when the function exits the pointer _obj2 is pointing at a location in the stack. This is why I used heap objects in my previous question, which people told me was "stupid".
So, the first question is: if how can I convert the stack object (obj2) to a heap object so it's not deallocated after create() exits? I want a straight answer, not an arrogant "you're doing it wrong" as so many have done. Because in this case stack objects cannot work so heap objects seem to be the only way. EDIT: Also, converting back to a stack object would be useful as well.
The second question: the specific example of heap objects being "wrong" was creating a new vector<string>* using the new operator. If dynamically allocating STL objects is wrong, then what's the right way? Obviously if you create them as stack objects it fails because they're immediately deallocated, but I've been told (again, by a very high-ranking member) that dynamically allocating them can corrupt the heap. So what's the right way to do it?
So, the first question is: if how can I convert the stack object (obj2) to a heap object so it's not deallocated after create() exits? I want a straight answer,
The straight answer is: You can't "convert" an object between the stack and heap. You can create a copy of the object that lives in the other space, as others have pointed out, but that's it.
The second question: the specific example of heap objects being "wrong" was creating a new vector* using the new operator. If dynamically allocating STL objects is wrong, then what's the right way? Obviously if you create them as stack objects it fails because they're immediately deallocated, but I've been told (again, by a very high-ranking member) that dynamically allocating them can corrupt the heap.
Dynamically allocating STL objects will not on its own corrupt the heap. (No idea where you might have heard that.)
If you want to use a stack-allocated STL object outside of the function that you created it in, you can't, since the stack space in which the object resides is only valid inside the function that created it.
You can, however, return a copy of the object:
std::vector<char> SomeFunc()
{
std::vector<char> myvector;
// myvector.operations ...
return myvector;
}
As I said, though, this will return a copy of the object, not the original object itself -- that would be impossible, since the stack that contains the object is unwound after the function returns.
One other option is to have the caller pass in a reference / pointer to the object that your function manipulates, if this makes sense for your particular scenario:
void SomeFunc(std::vector<char>& destination)
{
// destination.operations ...
}
void AnotherFunc()
{
std::vector<char> myvector;
SomeFunc(myvector);
}
As you can see, you've still allocated everything on the stack, and you avoid the (sometimes consequential) overhead of relying on the copy-constructor to return a copy of the object.
So, the first question is: if how can I convert the stack object (obj2) to a heap object so it's not deallocated after create() exits?
This line:
_obj2 = &obj2;
Change to:
_obj2 = new Class(obj2); // Create an object on the heap invoking the copy constructor.
I want a straight answer, not an arrogant "you're doing it wrong" as so many have done.
Thats as straight an answer as you can get. Obviously you are new to C++, So I am sure this will nto work as intended because you have probably made a couple of mistakes in the defintion of the class "Class" (by the way terrible name).
Also, converting back to a stack object would be useful as well.
class obj3(*_obj2); // dereference the heap object pass it to the copy constructor.
The second question: the specific example of heap objects being "wrong" was creating a new vector<string>* using the new operator. If dynamically allocating STL objects is wrong, then what's the right way?
Why do you dynamically allocate the vector. Just create it locally.
std::vector<std::string> funct()
{
std::vector<std::string> vecString;
// fill your vector here.
return vecString; // Notice no dynamic allocation with new,
}
Using new/delete is using C++ like C. What you need to read up on is smart pointers. These are obejcts that control the lifespan of the object and automatically delete the object when they go out of scope.
std::auto_ptr<Class> x(new Class);
Here x is a smart pointer (of type auto_ptr) when it goes out of scope the object will be deleted. But you can return an auto_ptr to the calling function and it will be safely transfered out of the function. Its actually a lot more complicated than that and you need a book.
Obviously if you create them as stack objects it fails because they're immediately deallocated,
Its de'allocated when it goes out of scope.
but I've been told (again, by a very high-ranking member) that dynamically allocating them can corrupt the heap.
If you do it incorrectly. Which given your knowledge is very likely. But hard to verify since you have not provided the definition of Class.
So what's the right way to do it?
Learn why you should use stack objects
Learn what smart pointers are.
Learn how to use smart pointers to control lifespans of objects.
Learn the different types of smart pointers.
Look up what the separation of concerns is (you are not following this basic principle).
You have to either copy-construct a new heap object (Class * foo = new Class(obj2)) or assign the stack object to a heap object (*obj1 = obj2).
the only way is to copy object.
Change declaration to:
Class _obj2;
and assign:
_obj2 = obj2;
Taking the address of a stack variable won't magically transfer it into heap. You need to write a proper copy-constructor for your class and use _obj2 = new Class(obj2);.
As for STL containers, they allocate their data on the heap anyway, why would you want to allocate container itself on the heap? Put them in a scope that will keep them alive as long as you need them.
Your stack object is created inside the create function and is deallocated as soon you get out of scope of the function. The pointer is invalid.
You could change Class* obj2 to Class obj2 and the assign (which means copy) the object by obj2 = obj2;
I think you're really trying to ask "How can I return an object created inside my function?" There are several valid ways:
Allocate on the heap and return a pointer
Use an automatic variable and return its value, not a pointer (the compiler will copy it)
Let the caller provide storage, either by pointer or reference parameter, and build your object there.
I have a C++ memory management doubt, that's (obviously) related to references and pointers. Suppose I have a class Class with a method my_method:
OtherClass& Class::my_method( ... ) {
OtherClass* other_object = new OtherClass( ... );
return *other_object;
}
Meanwhile in a nearby piece of code:
{
Class m( ... );
OtherClass n;
n = m.my_method( ... );
}
So, I know that there's a general rule about pointers (~ "anything new-ed, must be delete-d") to avoid memory leaks. But basicly I'm taking a reference to my heap-allocated object, so when n goes out of scope, shouldn't the destructor of OtherClass be called thus freeing the memory previously pointed by other_object?
So in the end the real question is: will this lead to a memory leak?
Thanks.
Yes that will lead to a memory leak.
What you'll do is, in the return statement, dereference the new object you created. The compiler will invoke the assignment operator as part of the returning and copy the CONTENTS of your new object to the object it's assigned to in the calling method.
The new object will be left on the heap, and its pointer cleared from the stack, thus creating a memory leak.
Why not return a pointer and manage it that way?
It's fairly obvious that you want to return a new object to the caller that you do not need to keep any reference to. For this purpose, the simplest thing to do is to return the object by value.
OtherClass Class::my_method( ... ) {
return OtherClass( ... );
}
Then in the calling code you can construct the new object like this.
{
Class m( ... );
OtherClass n( m.mymethod( ... ) );
}
This avoids any worries about returning reference to temporaries or requiring the client to manager deletion of a returned pointer. Note, that this does require your object to be copyable, but it is a legal and commonly implemented optimization for the copy to be avoided when returning by value.
You would only need to consider a shared pointer or similar if you need shared ownership or for the object to have a lifetime outside the scope of the calling function. In this latter case you can leave this decision up to the client and still return by value.
E.g.
{
Class m( ... );
// Trust me I know what I'm doing, I'll delete this object later...
OtherClass* n = new OtherClass( m.mymethod( ... ) );
}
Calling the destructor and freeing the memory are two distinct things in C++.
delete does both call the destructor and free the memory. delete[] calls the destructor for the allocated number of elements, then frees the memory.
When OtherClass goes out of scope, the destructor is called, but the memory is not freed.
As a suggestion, when you feel you have thoroughly understood pointers in C++, look into smart pointers, e.g. boost smart pointers to ease your memory management life in C++. (e.g. see the article here for an introduction)
You have 2 OtherClass objects:
One is n, which is created on the stack, and successfully deleted when goes out of scope.
The other one is the one that you create on the heap, inside my_method. This one is never deleted, and it will lead to memory leak.
If possible you can consider std::auto_ptr or boost/c0x shared_ptr to ease the memory management.
Usually, when a local object gets out of scope, it's memory is freed only because it's allocated on the stack and the stack gets cleaned up automatically. Since your object is allocated on the heap, there's no way it can get automatically freed. The only way to free it is to call delete explicitly.
I think you probably can do this:
Declare another class DummyClass, which contain a public member that is a pointer to OtherClass object. In the constructor of DummyClass, clear the pointer to NULL. In your function, declare an object of type DummyClass, and its member pointer to create another object of type OtherClass. Then in the destructor of DummyClass, check if the pointer is NULL, if it is not, delete it. In this way your object will be cleaned up automatically when DummyClass object goes out of scope.
If you insist on stack-allocation, don't use the new operator in my_method() and pass a reference to n instead, ie:
void Class::my_method( OtherClass& other_object, ... ) {
other_object.init( ... );
}
Then call my_method() like this:
{
Class m( ... );
OtherClass n;
m.my_method( n, ... );
}
For this pattern to work, Class must implement some kind of init() method which allows to correctly initialize objects without calling the constructor.