I'm using a C library (libwebsockets) which allows some user-data for each client. The library owns this memory, passes it as a void*, and my code reinterpret_cast's it to my user-data type.
I'm trying to add a std::string field to this class and am now seeing segfaults. Calling functions on this class causes errors, which is fair enough as it's likely backed by uninitialised memory.
How can I initialise that memory> I've tried assigning (the assignment operator segfaults) and calling various functions such as clear. I'm guessing there's a C++ mechanism for this.
Furthermore, how can the destructor be called when the string is no longer needed?
Assuming that you have a type something like this:
class MyType
{
std::string foo;
std::string bar;
};
And assuming that the void * points to an uninitialized allocation of at least sizeof(MyType) bytes, then you can construct it (and all contained objects) using placement new syntax:
void init_callback(void * ptr) {
new (ptr) MyType();
}
Similarly, you can destruct your type (which will destruct all contained objects) by calling the destructor directly.
void destroy_callback(void * ptr) {
MyType * mine = reinterpret_cast<MyType *>(ptr);
mine->~MyType();
}
Generally you don't call destructors directly, but you have to because you can't safely delete the pointer. The rule "every new should have one delete" has an analog in this situation: "every placement-new should have one explicit call to the destructor."
You can use placement-new to create an object in the provided memory:
std::string * s = new(memory) std::string;
and call the destructor to destroy it before reusing or releasing the memory:
s->std::string::~string();
If you find that a bit of a mouthful, then using std::string; will reduce it to s->~string();
Related
Suppose this is a struct/class in c++
struct MyClass{
list<int> ls;
};
Now maybe due to some reason, it is not possible to initialize pointer of 'MyClass', and the memory is being allocated manually
MyClass *pointer = calloc(1, sizeof(MyClass));
pointer->ls.push_back(123); // <----- this line causes core dump
Although it works fine with pure C++ method like this:-
MyClass *pointer = new MyClass;
pointer->ls.push_back(123);// All good, no problem
So is there any function available in std::list to resolve this issue?
I tried doing the same with std::vector, by there was no problem in that when I used calloc()
struct MyClass{
vector<int> ls;
};
MyClass *pointer = calloc(1, sizeof(MyClass));//using calloc
pointer->ls.push_back(123); // All Good
But on doing this using malloc:-
struct MyClass{
vector<int> ls;
};
MyClass *pointer = malloc(1, sizeof(MyClass));//using malloc
pointer->ls.push_back(123); // Core dump :-(
C++ differentiates between memory and objects in that memory. You are allocating memory with malloc or calloc, but you are not creating any object in the memory you allocated.
You can manually create an object in allocated storage using the placement-new expression:
new(pointer) MyClass /*initializer*/;
This creates a new MyClass object at the storage location that pointer points to. /*initializer*/ is the optional initializer for the object and has the same meaning as in a variable declaration
MyClass my_class /*initializer*/;
You may need to #include<new> to use the placement-new form I used above and you need to make sure that the allocated memory block is large enough and sufficiently aligned for the MyClass object type.
Using a pointer as if it points to an object even though none was created at the storage location causes undefined behavior, which you are observing. Note that this is true for any (even fundamental) types technically. Probably that will change in the future to allow at least trivial types (or some similar category) to be created implicitly when used, but for non-trivial class types such as the standard containers, this certainly will not change.
Also note that malloc and calloc return void*, which in C++ cannot be implicitly cast to a different pointer type. You need to cast it explicitly:
MyClass *pointer = static_cast<MyClass*>(malloc(sizeof(MyClass)));
or rather than doing that, save the pointer as void* without any cast to hint at you that it is not actually pointing to an object, but just memory.
You can still pass that void* pointer to the placement-new and the placement-new will actually return you a pointer of the correct type pointing to the new object (there are some specific cases where you are actually required to use this pointer):
void *mem_ptr = malloc(sizeof(MyClass));
auto obj_ptr = new(mem_ptr) MyClass /*initializer*/;
You should also avoid using malloc and calloc and the like. C++ has its own memory allocation function, called (confusingly) operator new. It is used like malloc (initializing the memory to zero like calloc does is not useful, because the initializer in the placement-new can and/or will do that):
void* pointer = operator new(sizeof(MyClass));
and its free analogue is:
operator delete(pointer);
It still only allocates memory and does not create object as the placement new does.
The non-placement new expression new MyClass; allocates memory (by call to operator new) and creates an object as if by the placement-new form mentioned above.
You do not need to bother with all of this though, because you can just use a smart pointer and initialize it later, if you need that:
std::unique_ptr<MyClass> ptr; // No memory allocated or object created
ptr = std::make_unique<MyClass>(/*constructor arguments*/); // Allocates memory and creates object
// Object is automatically destroyed and memory freed once no `std::unique_ptr` references the object anymore.
You should not use raw pointers returned from new, malloc or the like as owning pointers in the first place. std::unique_ptr has the correct ownership semantics by default and requires no further actions by you.
Hello So I'm experimenting with creating objects and arrays with preallocated memory. For instance I have this following code:
int * prealloc = (int*)malloc(sizeof(Test));
Test *arr = new(prealloc) Test();
Where test is defined as follows:
class Test {
public:
Test() {
printf("In Constructor\n");
}
~Test() {
printf("In Destructor\n");
}
int val;
};
In this scenario if I call delete it will actually release the memory which is bad, b/c maybe I'm using some type of memory manager so this will sure cause some problems. I searched in the internet and the only solution that I found was to call the destructor explicitly and then call free:
arr->~Test();
free(arr);
Is there another way to do this? is there perhaps a way to call delete and tell it to just call the destructor and not to release the memory?
My second problem was when working with arrays, like the previous example you can pass to new the pre-allocated memory:
int * prealloc2 = (int*)malloc(sizeof(Test) * 10);
Test *arr2 = new(prealloc2) Test[10];
If I call delete[] it will not only call the destructor for each element in the array but it will also release the memory which is something I don't want. The only way I have found that it should be done is to go through the array and call the destructor explicitly, and then call free. Like with the regular none array operators is there a way to tell the operator to just call the destructors without releasing the memory?
One thing I did notice was that the new operator for an array will actually use the first 4 bytes to store the size of the array (I only tested this in visual studio with a 32 bit build) That would help me know how many elements the array has but there is still one problem. What if the array is a pointer array? for example:
Test **arr2 = new Test*[10];
Could someone help me out with these questions please.
It's normal and expected to directly invoke the destructor to destroy objects you've created with placement new. As far as any other way to do things, about the only obvious alternative is to use an Allocator object (which, at least 99% of the time, will just be a wrapper around placement new and directly invoking the destructor).
Generally speaking, you do not want to use new[] at all. You typically want to allocate your raw memory with operator new (or possibly ::operator new) and release it with the matching operator delete or ::operator delete.
You create objects in that memory with placement new and destroy them by directly invoking the destructor.
There is no other way to do it but to explicitly call the destructor as delete will also attempt to free the memory.
Using preallocated memory with placement new should be fairly rare in your code - a typical use case is when you're dealing with direct memory mapped hardware interfaces when you want/need to map an object on top of a fixed memory address - and is something I'd normally consider a code smell.
If you want to tweak the memory management for a specific class, you're much better off either using an STL container with a custom allocator or overload operators new and delete for that specific class.
Yes, this is the only way to do it. There is an asymmetry in being allowed to define new but not delete. [ Well, you can do the latter but it can only get called when new throws an exception (not handled properly below!)
You can use a templated destroy to achieve the same result:
class Test
{
public:
Test() {
printf("In Constructor\n");
}
~Test() {
printf("In Destructor\n");
}
int val;
};
class Allocator
{
public:
static void* allocate(size_t amount) { return std::malloc(amount);}
static void unallocate(void* mem) { std::free(mem);}
static Allocator allocator;
};
Allocator Allocator::allocator;
inline void* operator new(size_t size, const Allocator& allocator)
{
return allocator.allocate(size);
}
template<class T>
void destroy(const Allocator& allocator, T* object)
{
object->~T();
allocator.unallocate(object);
}
int main()
{
Test* t = new (Allocator::allocator) Test();
destroy(Allocator::allocator, t);
return 0;
}
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.
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?
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.
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[]
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.
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().
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).
This is a design question, assuming C++ and a reference counted object hierarchy. A lot of classes in my codebase derive from a common base class (ObjectBase), which implements retain() and release() methods to increase and decrease the reference count of an object instance.
Every instance of an object may be created on the stack or on the heap, using a number of user definable memory allocators. In order for the object instance to commit suicide (delete this) in the release() method if the retainCount reaches 0, the instance must know which allocator it has been constructed with.
At the moment, I am allocating memory for an object instance using an arbitrary allocator, then call placement new to construct the object instance and call a setAllocator() method on the object to set the allocator it has been created with. If the object has been constructed on the stack, the allocator is set to NULL and release() will not call delete. This process is very redundant and potentially error prone (memory leaks, if I forget to call setAllocator, etc...) Ideally I would want to make this a one-step process like this:
Object* o = myPoolAllocator.allocate<Object>(constructor arguments... );
But this makes it very difficult to support and arbitrary number of constructor arguments.
I am just looking for ideas on how to solve this problem. I really like the idea of being able to reference count objects without having to rely on a smart pointer, especially since most classes derive from a common base, anyways.
Thanks for your help.
Florian
Have a look at this article: Overloading New in C++ . You could overload the new operator for ObjectBase so that it takes your allocator as a parameter and does the rest of the job:
void *ObjectBase::operator new(size_t size, Allocator *allocator) {
void *ptr = allocator->allocate(size);
// Hack to pre-initialize member before constructor is called
ObjectBase *obj = static_cast<ObjectBase *>(ptr);
obj->setAllocator(allocator);
return ptr;
}
Normally, the operator is supposed to just return a pointer to the allocated memory, but since you need access to the new object to call your setAllocator method, I've included a hack that should (but may not) work. Note that the actual ObjectBase constructor is called after the above function returns, so you should make sure that your constructor does not re-initialize the allocator member.
And then a similar overload for delete:
void ObjectBase::operator delete(void *ptr) {
ObjectBase *obj = static_cast<ObjectBase *>(ptr);
obj->getAllocator()->free(ptr);
}
You would then create objects by calling new (allocator) SomeClass(...) where SomeClass derives from ObjectBase.
Edit: One potential problem with this is that you cannot allocate objects on the stack any more, because there is no way to initialize the allocator to NULL without affecting the how the overloaded new works.
Update: There is one last (dirty) hack to get it working with both stack and dynamic allocation. You can make new set a global variable (a class static member would work as well) pointing to the current allocator and the constructor could consume this and reset it to NULL. At all other times, this global will already be NULL so an object constructed on the stack will get a NULL allocator.
Allocator *currentAllocator = NULL;
void *ObjectBase::operator new(size_t size, Allocator *allocator) {
currentAllocator = allocator;
return allocator->allocate(size);
}
ObjectBase::ObjectBase() {
setAllocator(currentAllocator);
currentAllocator = NULL;
}