Destructors and Malloc'd Members - c++

Question

Lets say, for example, that I have a class that requires the use of some old C stuff (like pthreads or something), so for one reason or another, I've ended up with a malloc() call in my constructor, like so:
class Foo
{
public:
Foo()
{
someMutex = malloc(sizeof(pthread_mutex_t));
pthread_mutex_init(someMutex);
someString = new string("yay string!");
}
private:
pthread_mutex_t * someMutex;
string * someString;
}
It seems like there is a lot of misinformation about destructors out there. I keep seeing examples of explicitly defined destructors calling delete on pointer based members, but I also keep reading that I don't need to explicitly define a destructor for a class to manage memory; all I need a destructor for are things like file handle cleanups and the like.
Thus leads to my question then: Even though someMutex was allocated with malloc and not the C++ new command, will the implicitly defined destructor still take care of it, or do I have to do it?
Also, lets just settle another question of mine, since its so closely related. In the class above, do I need to explicitly define a destructor in order to call delete on someString, or is that taken care of for me?

Answer 1

Not only do you need to define a destructor to do the cleanup, you also need to declare (and optionally define) a copy constructor and copy assignment operator for your class, to ensure that copies are made correctly.
The implicitly-defined destructor destroys member variables. So, for example, if you had a member variable of type string, the destructor will destroy that variable all on its own. However, the destructor for a pointer (like string*) is a no-op: you are responsible for destroying the pointed-to object.
You also need to define the copy operations for this class, or at least suppress generation of the default copy operations that the compiler provides for you. Why? Because by default, the copy operations just copy each member variable. So, if for example you were to write:
{
Foo x;
Foo y(x);
} // Uh oh
Both x and y are destroyed at the end of the block. At this point, both x and y point to the same dynamically allocated mutex and string, so the mutex and string would be destroyed twice (once for x and once for y).
The better option is not to use manual memory allocation at all. Rather, you should make someString a direct member of the class (i.e., declare it string someString;) or you should use a smart pointer of some kind to manage its lifetime (like unique_ptr or shared_ptr). Similarly, you should use a smart pointer with a custom deleter to manage the lifetime of the mutex, unless your class is noncopyable, in which case you can make the mutex a direct member of the class.

Answer 2

Yes, you have to define a destructor and destroy your objects (someMutex and someString).
But, as you have allocated someMutex with malloc, you must free it with free.
Take care for not to mix them.
Remember:
allocated with malloc, freed with free
allocated with new, freed with delete
allocated with new[], freed with delete[]

Answer 3

Instead of storing a pointer to a string in your class, I'd just store an instance of string as a data member (using "stack semantics").
Moreover, instead of storing a pointer to a "raw" pthread_mutex_t, I'd define a C++ class to wrap this pthread_mutex_t resource using RAII (creating the pthread_mutex_t in its constructor, and destroying it in its destructor), and then I'd store an instance of this C++ class as a data member of Foo.
//
// C++ RAII wrapper on raw C pthread_mutex_t resource.
//
class PThreadMutex
{
public:
// Creates a pthread_mutex_t.
PThreadMutex()
{
pthread_mutex_init(&m_mutex, ...);
// Check for errors, and throw exceptions on errors
}
// Destroys a pthread_mutex_t
~PThreadMutex()
{
pthread_mutex_destroy(&m_mutex);
}
// Other member functions
// ...
// May define move constructor and move assignment operator for C++11
// ...
private:
pthread_mutex_t m_mutex;
};
class Foo
{
public:
Foo()
: m_someString("yay string!")
// m_someMutex initialized by its default constructor
{
}
~Foo()
{
// Nothing to do: C++ compiler will call the destructors
// of class data members, releasing their associated resources.
}
private:
//
// Class "building blocks":
//
PThreadMutex m_someMutex;
string m_someString;
};
In this way, the compiler-generated destructor for Foo will automatically call each data members destructors, releasing their resources.
In general, each "raw" C resource (pthread_mutex_t, FILE *, etc.) should be wrapped in a C++ class using RAII, and instances of these classes (like they were kind of "building blocks") should be used as data members of other classes.
This helps simplify your code (and writing exception-safe code as well); if you use this pattern you can achieve a good level of code safety and composability.

Answer 4

No, destructor shouldn't delete those data (it may be pointer to memory allocated somewhere else in your application). So you have to write your own destructor.
And one more thing. Once you allocate memory with malloc you should free it with free().

Answer 5

Whether you need to define a destructor or not depends of if the current object OWNS the created objects or it just create them for some other object to manage, respectivelly.
When you allocate heap memory with malloc() you should free it with free().
When you create objects with new, then you must delete it with delete.
When you create an array with new[], then you must delete it with delete[].
Implicit destructors destroy member variables but in your case they are pointers so memory allocated for the pointers thenselves will be recovered, but not the allocated memory you just malloc'ed.
Another option is using a "smart pointer" (http://en.wikipedia.org/wiki/Smart_pointer), which will actually delete the pointed object when the current object is deleted (or get out of scope).