在DLL中分配内存并将其指向客户端应用程序的指针是不好的做法吗？

Question

I'm using an exe which dynamically loads a DLL. A function in the DLL allocates memory on the heap and passes a pointer to that memory to the exe.

A senior says that it is bad practice to do so. He says that if I ever have to share memory between the exe and the DLL, the exe has to allocate memory and pass a pointer to that to the DLL, and not vice versa. Is this true? Why?

EDIT: In my case, I planned to allocate and deallocate memory inside the DLL itself.

Answer 1

One of the basic idea behind the design patterns is ownership. The idea is - one who creates a resource (and thereby holds it in the pointer) should be responsible for deleting the resource . This will ensure the sanctity of the design and in longer life of the projects, its developer can see lesser bugs.

So now it in your case, the DLL can be attached by any executable and he can try to delete the resource, which may cause future problem. So I think it has been suggested for vice-versa and I would say it as a sound advice.

Answer 2

Here are some reasons for having the caller supply a pointer:

1. Symmetric ownership semantics. This is already explained by several other answers.
2. Avoids mismatching the allocator and deallocator. As mentioned in Aesthete's answer , if the DLL allocates a pointer and returns it, the caller must call the corresponding deallocator to free it. This is not necessarily trivial: the DLL might be statically linked against one version of, say, malloc / free while the .exe is linked against a different version of malloc / free . (For example, the DLL could be using release versions while the .exe is using specialized debug versions.)
3. Flexibility. If the DLL is meant for general use, having the caller allocate the memory gives the caller more options. Suppose the caller doesn't want to use malloc and instead wants memory to be allocated from some specific memory pool. Maybe it's a case where the caller could provide a pointer to memory allocated on the stack. If the DLL allocated the memory itself, the caller does not have any of these options.

(The second and third points also mostly can be addressed by having the .exe supply an allocator/deallocator for the DLL code to use.)

Answer 3

I have seen this issue before, and it is caused by the DLL and exe linking differently to the CRT (static, dynamic MT etc).

I you're going to pass a pointer to memory between DLL and executable, they should both provide some sort of Free() functionality to free memory from their respective heaps.

Answer 4

Generally, the heap (The One Heap) belongs to the process, and it does not matter where you allocate from, so this will work just fine, except when it doesn't .

Therefore, the claim that it is "bad practice" is valid. There are few things that are worse than something that works fine, except when it doesn't.

The worst part about it is that when everything blows up, it's not immediately obvious what's wrong, and you can easily run into an issue without knowing. It may be something as easy as linking the a particular version of the CRT into your DLL. Or someone in your team might have created a separate heap for some reason. Or, some other reason that isn't immediately obvious which caused another heap being created.

What makes the free-from-wrong-heap situation so vicious is that you don't generally know what will happen, or when (or if someone will notice).

You may get a NULL return value from a heap function or an exception. Your application might be prepared for either of them or it might not be (be honest, you always check return values, don't you?). It might crash immediately upon freeing, or you might just silently leak memory and run out of address space (or memory) minutes or hours later, and nobody will know why. Or, something else.
Thus, what you see may not at all be in (apparent) correlation to what caused the problem.

Answer 5

I only want to point out that passing an allocator to the DLL to allocate memory is perfectly safe and is the standard model used by the C++ std library itself. In this case, the allocation is done by the DLL via a method passed from the caller, avoiding to pass pointers , and avoiding the issue of linking to different implementations of malloc() .

Answer 6

the exe and the dll may have different heaps. when either try to free memory allocated by the other the free fails and there is a leak.

only if both, the exe and the dll use CRT dynamically with the same version of the CRT they use the same heap.

so it is a very good advice to do allocation and free in the same binary.

Answer 7

I'd argue that it is generally bad practice to hand around raw pointers. In case of a dll, it should return a smart-pointer that has a custom deleter that appropriately handles the cleanup (options are std::unique_ptr , std::shared_ptr or boost::shared_ptr in order of preference).

In fact, it is probably safer to use std::weak_ptr or boost::weak_ptr - these require you to check each time you want to access the resource, because the dll might have been unloaded in the meantime.

Answer 8

正如@kumar_m_kiran所指出的，这与所有权问题有关，但是我想指出的是，@ aleguna也是正确的，因此，恕我直言，正确的规则是“在DLL或EXE中分配和释放相同的内存，但不能同时在两者中分配和释放相同的内存” 。

Answer 9

It's not necessarily bad practice but it's dangerous practice (and probably bad). You need to carefully think about who is responsible for freeing the memory. The exe will probably not be able to (or should not be able to) free the DLL's memory directly itself so presumably will be passing this pointer back to the DLL at some later date. So now we're passing a pointer back and forth between an EXE and a DLL which isn't nice.

Answer 10

I'd say no, it's not "bad practice". From my experience, you just need to be careful that you release that pointer in the right memory space. I've built a graphics engine that allocated assets in multiple DLLs (each DLL represented a mini game); using a shared_ptr (at the time it was Boost, however, I'm sure the C++11 (or newer) std::shared_ptr supports the same semantics). I would supply a function that would delete the memory in the right space. The main concern, at this point, is that you ensure you free your shared_ptrs before you free the DLL. I can't recall now, but we might have used a list of shared_ptrs owned by the DLL/DLL wrapper, and all other uses of the pointer were through a weak_ptr TO that shared_ptr.