Memory allocation question using malloc

[Elysia]

So I was wondering, if one were to use malloc or some malloc-styled allocation (i.e. not using) new, and then using placement new on that memory, would calling delete on that memory then be defined according to the standard?

This may seem silly. Why would anyone want to do this? But sometimes there are libraries written in C that you just have to use.

Example:

auto* p = malloc(sizeof(std::vector<int>));
auto* v = new (v) std::vector<int>();
// Use v
delete v;
v = p = nullptr;

[jimblumberg]

But sometimes there are libraries written in C that you just have to use.

So why would you need to use malloc() in a C++ program just to use some C library?


Jim

[Elysia]

The point is that the library written in C uses some kind of malloc-style allocation.

auto * p = allocate_me_some_memory(numa_core, sizeof(std::vector<int>));
auto * myvec = new (p) std::vector<int>();
// Use myvec
delete myvec;
myvec = p = nullptr;

[jimblumberg]

If the library is using malloc() you should be using free().

Jim

[Elysia]

That won't call destructors (BAD, BAD BAD!!!), so I was curious if it's undefined or not.

[grumpy]

The point is that the library written in C uses some kind of malloc-style allocation.

auto * p = allocate_me_some_memory(numa_core, sizeof(std::vector<int>));
auto * myvec = new (p) std::vector<int>();
// Use myvec
delete myvec;
myvec = p = nullptr;

The behaviour of your example is undefined, since you need to use the corresponding placement delete.

If you have modified/overloaded a variant of operator new() to use malloc(), the default expectation would be to use free() in the corresponding operator delete(). And code which uses operator new (in an expression) needs to use the corresponding operator delete.

If you are using malloc() to allocate memory that is then passed to placement new, the expectation is that you would use free() after using the corresponding placement delete.

[jimblumberg]

So what? That C library doesn't call constructors or even know anything about C++ classes, so there are no classes to worry about, hence no destructors need to be called.

Jim

[Elysia]

Now thinking about it, it was probably a silly question. You're right. We need to explicitly call the destructor and then free.

[Elysia]

So what? That C library doesn't call constructors or even know anything about C++ classes, so there are no classes to worry about, hence no destructors need to be called.

Jim

Come on. We can't allocate standard library containers with malloc. So we need to use placement new. And because of that we need to call destructors.

[phantomotap]

O_o

Yes. That would be undefined behavior.

One solution, my preferred, is using an adapter to disguise allocation/deallocation details and custom deleter with a smart pointer.

template<typename F> kill(F & f){f->~F();}
// ...
{
auto sWhatever = allocate_and_construct_me_some_object<std::vector<int>>(adapter, &kill, /* constructor arguments */);
sWhatever->push_back(0);
// sWhatever is destroyed so ~std::vector<int>() and `free' are called 
}

Soma

[phantomotap]

The behaviour of your example is undefined, since you need to use the corresponding placement delete.

O_o

You can't call the corresponding placement `delete' manually; those functions are only called automatically when an exception is thrown from the associated `new'.

Soma

[phantomotap]

O_o

I realize the code was just an example, but I wanted to make one more point.

The code `allocate_me_some_memory(numa_core, sizeof(std::vector<int>));' allocates memory for a container, apparently, on some NUMA architecture. That is fine, but the memory allocated by the container will live wherever the standard allocator places that memory. If you want the memory allocated by the container to live on the same place as the container, you'll have to deal with a custom allocator.

Soma

[Elysia]

Good point. I hadn't thought about that. Guess it's time to look into custom allocators, then.