I know it's basic question but I'm quite new to C++ and I'd like to know if for example I have 2 classes:
class MyClass1 {
private:
vector<int> iVals;
std::string name;
public:
MyClass1(std::string name) {
this->name = name;
}
~MyClass1() {
//empty
}
};
class MyClass2 {
private:
vector<int>* iVals;
std::string* name;
public:
MyClass2(std::string name) {
this->iVals = new vector<int>();
this->name = new std::string(name);
}
~MyClass2() {
delete this->iVals;
delete this->name;
}
};
Instances of both classes I can initialize statically or dynamically in main() method
int main() {
MyClass1 c_1("one");
MyClass1* c_11 = new MyClass1("one one");
MyClass2 c_2("two");
MyClass2* c_22 = new MyClass2("two two");
}
My question is what is better way to implement such classes? With "static"(no the static keyword) or dynamic fields?
If I do
MyClass1* c_11 = new MyClass1("one one");
If I'm correct, objects fields, which are not allocated dynamically, will be allocated also on heap. So is there any practical reason to allocate any class member dynamically?
While there is sometimes a use for dynamically allocated members (I basically use them for polymorphic members and that's about it), I would not use it like you implemented MyClass2. This has many possibilities for bugs, the foremost (in my opinion) beeing:
You did not define a copy/move constructor and copy/move assignment. The implicit constructors would only work on the value of the pointer and not the object it's pointing to. So if you have MyClass2 a("Hi"); MyClass2 b = a; both of them would point to the same std::string. If one goes out of scope, this object is deleted and the other pointer is dangling. Hence, we have the so called rule of five.
Hence, if you have an object owning memory, you should use std::unique_ptr. It is a wrapper around a pointer, which deletes it if the object is deleted. Due to this the default constructors and deleter work perfectly well and you dont have to worry at all about managing the memory. All of this comes with minor runtime overhead.
If you come to the point, where multiple objects share some memory and you cannot say that one of those outlives all others, working with raw pointers becomes very troublesome. Then you should look at std::shared_ptr. But be careful, it is easy to get a hefty overhead if not used in the right way.
It is ok to use raw pointers if you just want to look at an object or modify it and are absolutely sure that the object pointed to will not get deleted while doing so. But having raw new and delete in your code should always make you think whether it is really needed.
Related
My following question is on memory management. I have for example an int variable not allocated dynamically in a class, let's say invar1. And I'm passing the memory address of this int to another classes constructor. That class does this:
class ex1{
ex1(int* p_intvar1)
{
ptoint = p_intvar1;
}
int* ptoint;
};
Should I delete ptoint? Because it has the address of an undynamically allocated int, I thought I don't need to delete it.
And again I declare an object to a class with new operator:
objtoclass = new ex1();
And I pass this to another class:
class ex2{
ex2(ex1* p_obj)
{
obj = p_obj;
}
ex1* obj;
};
Should I delete obj when I'm already deleting objtoclass?
Thanks!
Because it has the address of an undynamically allocated int I thought I don't need to delete it.
Correct.
Should I delete obj when I'm already deleting objtoclass?
No.
Recall that you're not actually deleting pointers; you're using pointers to delete the thing they point to. As such, if you wrote both delete obj and delete objtoclass, because both pointers point to the same object, you'd be deleting that object twice.
I would caution you that this is a very easy mistake to make with your ex2 class, in which the ownership semantics of that pointed-to object are not entirely clear. You might consider using a smart pointer implementation to remove risk.
just an appendix to the other answers
You can get rid of raw pointers and forget about memory management with the help of smart pointers (shared_ptr, unique_ptr).
The smart pointer is responsible for releasing the memory when it goes out of scope.
Here is an example:
#include <iostream>
#include <memory>
class ex1{
public:
ex1(std::shared_ptr<int> p_intvar1)
{
ptoint = p_intvar1;
std::cout << __func__ << std::endl;
}
~ex1()
{
std::cout << __func__ << std::endl;
}
private:
std::shared_ptr<int> ptoint;
};
int main()
{
std::shared_ptr<int> pi(new int(42));
std::shared_ptr<ex1> objtoclass(new ex1(pi));
/*
* when the main function returns, these smart pointers will go
* go out of scope and delete the dynamically allocated memory
*/
return 0;
}
Output:
ex1
~ex1
Should I delete obj when I'm already deleting objtoclass?
Well you could but mind that deleting the same object twice is undefined behaviour and should be avoided. This can happen for example if you have two pointers for example pointing at same object, and you delete the original object using one pointer - then you should not delete that memory using another pointer also. In your situation you might as well end up with two pointers pointing to the same object.
In general, to build a class which manages memory internally (like you do seemingly), isn't trivial and you have to account for things like rule of three, etc.
Regarding that one should delete dynamically allocated memory you are right. You should not delete memory if it was not allocated dynamically.
PS. In order to avoid complications like above you can use smart pointers.
You don't currently delete this int, or show where it's allocated. If neither object is supposed to own its parameter, I'd write
struct ex1 {
ex1(int &i_) : i(i_) {}
int &i; // reference implies no ownership
};
struct ex2 {
ex2(ex1 &e_) : e(e_) {}
ex1 &e; // reference implies no ownership
};
int i = 42;
ex1 a(i);
ex2 b(a);
If either argument is supposed to be owned by the new object, pass it as a unique_ptr. If either argument is supposed to be shared, use shared_ptr. I'd generally prefer any of these (reference or smart pointer) to raw pointers, because they give more information about your intentions.
In general, to make these decisions,
Should I delete ptoint?
is the wrong question. First consider things at a slightly higher level:
what does this int represent in your program?
who, if anyone, owns it?
how long is it supposed to live, compared to these classes that use it?
and then see how the answer falls out naturally for these examples:
this int is an I/O mapped control register.
In this case it wasn't created with new (it exists outside your whole program), and therefore you certainly shouldn't delete it. It should probably also be marked volatile, but that doesn't affect lifetime.
Maybe something outside your class mapped the address and should also unmap it, which is loosely analogous to (de)allocating it, or maybe it's simply a well-known address.
this int is a global logging level.
In this case it presumably has either static lifetime, in which case no-one owns it, it was not explicitly allocated and therefore should not be explicitly de-allocated
or, it's owned by a logger object/singleton/mock/whatever, and that object is responsible for deallocating it if necessary
this int is being explicitly given to your object to own
In this case, it's good practice to make that obvious, eg.
ex1::ex1(std::unique_ptr<int> &&p) : m_p(std::move(p)) {}
Note that making your local data member a unique_ptr or similar, also takes care of the lifetime automatically with no effort on your part.
this int is being given to your object to use, but other objects may also be using it, and it isn't obvious which order they will finish in.
Use a shared_ptr<int> instead of unique_ptr to describe this relationship. Again, the smart pointer will manage the lifetime for you.
In general, if you can encode the ownership and lifetime information in the type, you don't need to remember where to manually allocate and deallocate things. This is much clearer and safer.
If you can't encode that information in the type, you can at least be clear about your intentions: the fact that you ask about deallocation without mentioning lifetime or ownership, suggests you're working at the wrong level of abstraction.
Because it has the address of an undynamically allocated int, I
thought I don't need to delete it.
That is correct. Simply do not delete it.
The second part of your question was about dynamically allocated memory. Here you have to think a little more and make some decisions.
Lets say that your class called ex1 receives a raw pointer in its constructor for a memory that was dynamically allocated outside the class.
You, as the designer of the class, have to decide if this constructor "takes the ownership" of this pointer or not. If it does, then ex1 is responsible for deleting its memory and you should do it probably on the class destructor:
class ex1 {
public:
/**
* Warning: This constructor takes the ownership of p_intvar1,
* which means you must not delete it somewhere else.
*/
ex1(int* p_intvar1)
{
ptoint = p_intvar1;
}
~ex1()
{
delete ptoint;
}
int* ptoint;
};
However, this is generally a bad design decision. You have to root for the user of this class read the commentary on the constructor and remember to not delete the memory allocated somewhere outside class ex1.
A method (or a constructor) that receives a pointer and takes its ownership is called "sink".
Someone would use this class like:
int* myInteger = new int(1);
ex1 obj(myInteger); // sink: obj takes the ownership of myInteger
// never delete myInteger outside ex1
Another approach is to say your class ex1 does not take the ownership, and whoever allocates memory for that pointer is the responsible for deleting it. Class ex1 must not delete anything on its destructor, and it should be used like this:
int* myInteger = new int(1);
ex1 obj(myInteger);
// use obj here
delete myInteger; // remeber to delete myInteger
Again, the user of your class must read some documentation in order to know that he is the responsible for deleting the stuff.
You have to choose between these two design decisions if you do not use modern C++.
In modern C++ (C++ 11 and 14) you can make things explicit in the code (i.e., do not have to rely only on code documentation).
First, in modern C++ you avoid using raw pointers. You have to choose between two kinds of "smart pointers": unique_ptr or shared_ptr. The difference between them is about ownership.
As their names say, an unique pointer is owned by only one guy, while a shared pointer can be owned by one or more (the ownership is shared).
An unique pointer (std::unique_ptr) cannot be copied, only "moved" from one place to another. If a class has an unique pointer as attribute, it is explicit that this class has the ownership of that pointer. If a method receives an unique pointer as copy, it is explicit that it is a "sink" method (takes the ownership of the pointer).
Your class ex1 could be written like this:
class ex1 {
public:
ex1(std::unique_ptr<int> p_intvar1)
{
ptoint = std::move(p_intvar1);
}
std::unique_ptr<int> ptoint;
};
The user of this class should use it like:
auto myInteger = std::make_unique<int>(1);
ex1 obj(std::move(myInteger)); // sink
// here, myInteger is nullptr (it was moved to ex1 constructor)
If you forget to do "std::move" in the code above, the compiler will generate an error telling you that unique_ptr is not copyable.
Also note that you never have to delete memory explicitly. Smart pointers handle that for you.
Does the delete() operator destroy all the sub-objects of an object too?
Or do I need to call the delete of sub-object before deleting the parent object?
class equipment
{
public:
int model_id;
...
}
class player
{
public:
int x, y;
equipment * Equipment;
player(void) { Equipment = new equipment[2];};
~player(void) { delete [] Equipment; }
};
int main (....)
{
player = new Player;
...
...
delete Player;
}
you need to delete the dynamically allocated subobjects in the destructor of the main object and you have properly done this by deleting array Equipment
Delete operator does delete all "subobjects" as you say, but usually and in your case you need to delete not only "sub objects" but also memory, where member pointers point to.
So if you used vector object, for example, it would be deleted automatically, but in this case you need to delete it explicitly, which you did correctly
To put it simply, during destruction of the object :
Member objects are themselves destroyed
Objects pointed by member pointers aren't
That means that you have to delete them manually (like your Equipement pointer), if you own them. There might be case when your class ends up with a pointer it does not own (for example, a handle to some other object you need in this class), and thus should not delete.
You can use smart pointers (i.e.:std::shared_ptr, std::unique_ptr, etc.) to manage memory in a safer way (they, notably, automatically delete the pointers they manage, following the RAII principle ).
One thing you are missing is the destructor in class equipment
The stuff you do in your example is sufficient, you
delete[] Equipment;
in the destructor of player, so all contained equipments will be deleted as soon as a player gets deleted.
Nicely done!
Im new to this and just wanted to ask a quick question about deleting objects.
I have an object called MyClass1 and from it I have a number of other classes, MyClassA, MyClassB etc.
Now should I do this in MyClass1:
MyClass1::~MyClass1()
{
delete MyClassA;
delete MyClassB;
}
Or will everything created in MyClass1 automatically be deleted when I delete MyClass1?
Also, if I have more objects created in MyClassA and MyClassB, will these also have to be deleted manually in their respective class?
Thanks
If you're asking this, you're just learning C++, so the best advice is - neither. You should know about this stuff (dynamic allocation & memory management - see Guillaume's answer for this), but what you really should do is use RAII (google this). The proper C++ way of doing it would be:
struct MyClass1
{
MyClassA mA;
std::shared_ptr<MyClassB> mB;
MyClass1() : mB(new MyClassB)
{
}
};
See? No more destructor, which means you also don't need a copy constructor or copy assignment operator (which is where Guillaume's answer is flawed - it's missing the last two).
call delete operator only if you have created your objects with new operator
struct MyClass1
{
MyClassA mA;
MyClassB * mB;
MyClass1()
{
mB = new MyClassB;
}
~MyClass1()
{
delete mB;
}
};
You can't delete objects that aren't pointers because that's not the purpose of delete. It's meant to free dynamic memory associated with an object. That is, whatever is created with new must be deleted. You can have pointers to a class, and they can be deleted. But since nothing was allocated with new, there's no need to use delete. The class will in fact be destructed from memory at the end of the scope in which it is created. Those objects are allocated on the stack while dynamic memory is on the heap. Objects on the stack have automatic storage duration (deleted at the end of its scope, unless its declared static in which case it has "static" storage duration); moreover, objects on the heap have dynamic storage duration. Dynamic memory in C++ is controlled by you, that's why we are given new and delete (because C++ expects us to handle the memory ourselves). And otherwise deleting an object not constructed with new is undefined behavior and may lead to a crash.
If Qt, use QPointer! It is a smart pointer: nothing needed in destructor.
#include <QPointer>
class MyClass1
{
QPointer<MyClassA> pA;
QPointer<MyClassB> pB;
};
delete is applied to objects, not to classes. As a rule, calling delete (or arranging to have it called automatically, via a shared pointer, or with the RAII idiom in general) is necessary only if you called new to create the object. The exception is the return value of some (library?) call being an object that the (library's?) documentation states explicitly that the caller has to dispose of with delete (in which case, think of the call as a wrapper around a new that you have become responsible for.) Of course, APIs like that should be avoided if at all possible.
I've this C++ class:
class test{
char* p;
SomeClass* someObject;
test(){
...
p = (char*) malloc(1000);
someObject = new SomeClass();
...
}
~test(){}
}
Do I need to call free(p) or delete someObject explicitly in test destructor in order to free their allocated memory or that memory will free automatically?
You need to free all dynamically allocated memory in the destructor. This does not get done automatically.
Your class contains two pointers, and essentially has no control over what these point to. In fact, these could point to objects that you are not allowed to delete, for example:
struct Foo {};
struct Bar {
Foo* f_;
Foo(Foo* f) : f(f_) {}
};
int main() {
Foo f;
Bas b(&f); // b has a Foo ptr, but should it delete it?
}
So you can see that it doesn't really make sense for pointer data members to be deleted automatically.
As a general rule, if your class manages resources1, then you should take care of copy construction and assignment; that means, you should either disable them if that makes sense for the class, or provide implementation for them because the compiler generated ones would not work. For detail discussion on this topic, see the rule of three, and extensive discussions on stackoverflow:
What is The Rule of Three?
Rule-of-Three becomes Rule-of-Five with C++11?
If you don't follow this rule, then the default copy constructor and assignment operation will make a shallow copy and you will have more than one instance having pointers to the same dynamically allocated objects, which they will all try to delete upon destruction.
You can avoid manually deleting objects created with new by using smart pointers. In your case, where the class obviously owns the dynamically allocated object,you should look at C++11's std::unique_ptr or boost::scoped_ptr
Finally, you can really avoid all memory management problems by avoiding pointers all together, unless you really need to. You could replace your char* by an std::string for example:
class test{
std::string p;
SomeClass someObject;
//test() : someObject() {} // default construction is probably OK...
};
1. That is, it allocates and deallocates memory, or opens and closes network connection, or creates and destroy mutexes and so on.
Yes, you have to free anything you malloc and delete everything you new.
You can also avoid that by not storing pointers in your class.
class test{
public:
std::string p;
SomeClass someObject;
};
Yes, you need.
If you don't want, you can use the Smart Pointer
Yes, you need to free them explicitly. Pointer as a data type does not have any destructor. Compiler/execution enviroment does not have any means to guess if pointer points to anything meaningfull or not. Even if the value is meaningfull, it may point to some static object for example. Or it can point to some field of a bigger object. Compiler is not doing any automatic cleanup on pointers.
The memory is technically leaked if you do not reclaim it when the instance of test is destructed. You could use a smart pointer instead to avoid calling free or delete explicitly in the destructor.
struct Free { void operator () (void *p) const { free(p); } };
class test {
std::unique_ptr<char, Free> p;
std::unique_ptr<SomeClass> someObject;
test () : p(static_cast<char *>(malloc(1000)),
someObject(new SomeClass)
{ //...
}
~test () {}
};
This uses the destructor of the smart pointer to perform the clean up action for you.
If test were only used as const global instances, then it is less important to implement the cleanup since the memory would not be reclaimed until the execution had ended anyway. But it is good practice to always implement the cleanup, because it would make the code correct now, and test may be used differently in the future.
I am not experienced in handling of the memory in a C++ program, so I would like a piece of advice in that case:
I want to create a new Object in a function in a class which is essential till the end of the program. As far as I am concerned, if I use the operator new, I should sometimes delete it. Taking into account that it must be initialized inside a class, when and how must I finally delete it?
I suggest the smart pointer idiom
#include <memory>
struct X
{
void foo() { }
};
std::share_ptr<X> makeX() // could also be a class member of course
{
return std::make_shared<X>();
}
int main()
{
std::share_ptr<X> stayaround = makeX();
// can just be used like an ordinary pointer:
stayaround->foo();
// auto-deletes <sup>1</sup>
}
If the pointer is truly a static variable, you can substitute a unique_ptr (which works similarly, but passes ownership on assignment; this means that the pointer doesn't have to keep a reference count)
Note To learn more about C++ smart pointers in general, see smart pointers (boost) explained
Note If you don't have the TR1/C++0x support for this, you can just use Boost Smartpointer
1 unless you are leaking copies of the shared_ptr itself; that would be some strange use of smart pointers previously unseen :)
Edit: Using some sort of smart pointer is often a good idea, but I believe it is still essential to have a solid understanding of manual memory management in C++.
If you want an object in a class to persist until the end of the program, you can simply make it a member variable. From what you've said, there's nothing to suggest you need to use new or delete here, just make it an automatic variable. If you did want to use new and delete for practice, you should read up on constructors and destructors for a class (you can and will use new and delete outside of classes, but I'm trying to keep this relevant to your question). Here's one I prepared earlier:
class Foo
{
public:
Foo(); // Default constructor.
~Foo(); // Destructor.
private:
int *member;
}
Foo::Foo() // Default constructor definition.
{
member = new int; // Creating a new int on the heap.
}
Foo::~Foo() // Destructor.
{
delete member; // Free up the memory that was allocated in the constructor.
}
This is a simple example, but it will hopefully help you out. Note that the variable will only persist as long as the object is alive. If the object is destroyed or goes out of scope, the destructor will be called and the memory will be freed.
You can use the smart pointer as suggested by Sehe or you can create a static object in the function and return a reference to it. You need not explictly delete the object, when the process terminates the object will be deleted. Like:
struct X {};
X& makeX() // could also be a class member of course
{
static X x;
return x;
}
int main()
{
X& stayaround = makeX();
}
On most operating systems (in particular Linux), if you allocate an object pointer with new Object, and don't bother delete-ing because you'll need it till the program ends, no harm is really done. There is some memory leak inside your program (you can use valgrind to hunt such leaks) but the kernel will release all the memory used by a process when it has ended.
A better alternative is to have a singleton class for the application data, like e.g. QApplication in Qt, ahd construct a single instance in that class early in your main, and have that class contain a smart or dumb pointer to your Object. The destructor should delete that object.