Hello all.

I am busy working on makeing a vertual file system, And I've run into a problem that I may have been cruising around because all my DLL libraries are using the same platform toolset( And that means the same heap right? ).

That problem is: Who is responsible for deallocating the memory: Caller or Callee ?

So if I create a structure like so:

struct Blob
{
          unsigned char* pData;// std::vector< unsigned char > Data
          size_t Length;
};

(Would the vector dealoccate itself from the right heap?)

As far as I know if the structure was allocated on heap A and the caller is using Heap B and deallocates it there will be a crash or segfault or something, Right?

So the bottom line is: How do I make sure that the memory is deallocated from the right heap.

Am I correct in my understanding of dynamic memory here?

Many thanks

Ryan.

Am I correct in my understanding of dynamic memory here?

No.
There is only 1 heap.
The reason some libraries can’t deallocate allocations made by other libraries is because each library puts meta-data before an allocation to tell it how much has been allocated and etc. The format of this data may vary from library-to-library, and since it is necessary to deallocate it will cause a problem if an incompatible library tries to deallocate memory allocated by another library.

Who is responsible for deallocating the memory: Caller or Callee ?

The caller. It is your responsibility to make sure that the function you call to deallocate is designed to pair with the function you called to allocate.

If you use new, use delete to free.
If you use malloc(), use free() to free.
If you use a custom allocator, use the same custom deallocator.

It is that simple.


L. Spiro

On Windows, HeapAlloc() and HeapFree() can be used instead of the runtime specific memory management functions (new/delete, malloc/free) to ensure that dynamically allocated memory is always freed from the correct heap. Using runtime specific versions, smart pointers and whatnot internally within a module/DLL is fine but if you pass these memory blobs out of the DLL to be freed elsewhere, you should consider HeapAlloc/HeapFree as a safe, although a bit cumbersome, option.

Can you give an example of how they are used, I google'd but could not find an example.

Perhaps I am just a bit daft right now

Or is it just a simple matter of using those to create the buffer needed for the file ?

Am I correct in my understanding of dynamic memory here?

No.
There is only 1 heap.
The reason some libraries can’t deallocate allocations made by other libraries is because each library puts meta-data before an allocation to tell it how much has been allocated and etc. The format of this data may vary from library-to-library, and since it is necessary to deallocate it will cause a problem if an incompatible library tries to deallocate memory allocated by another library.

So each platform toolset option(v120_xp, v120, Etc - Visual Studio) would use its own format for the meta-data ?

Who is responsible for deallocating the memory: Caller or Callee ?

The caller. It is your responsibility to make sure that the function you call to deallocate is designed to pair with the function you called to allocate.

If you use new, free with delete.
If you use malloc(), free with free().
If you use a custom allocator, use the same custom deallocator.

It is that simple.


L. Spiro

So if a provide a method/function for allocation, it would be placed on whatever heap the DLL is using ?

If so: It would be a simple matter of two options:

1. Have the caller call the method with a certain parameter set to a predefined value->return the needed size of buffer->call again with user allocated buffer.
2. Have a structure that allocates/deallocates the buffer.

You can make the operations on your data structure use the right heap heap by giving your class constructors and a destructor and all vector operations wrapped in member functions and implement those in the DLL (in a .cpp file compiled into the DLL) instead of a header (you could also write a custom allocator that's implemented in the DLL instead of wrapping all the vector operations). e.g.

// foo.h
class foo {
  using container = std::vector<int>;
  container data;

public:
  foo();
  foo(foo const&);
  foo& operator=(foo const&);
  ~foo();


  using iterator = container::iterator;
  using const_iterator = container::iterator;
  using size_type = container::size_type;

  void push_back(int);
  iterator erase(iterator);
  iterator begin();
  const_iterator begin() const;
  iterator end();
  const_iterator end() const;
  size_type size() const;
  bool empty() const;
  // etc.
};

// foo.cpp
#include "foo.h"

foo::foo() = default;
foo::foo(foo const&) = default;
foo& foo::operator=(foo const&) = default;
foo::~foo() = default;

void foo::push_back(int value) { data.push_back(value); }
foo::iterator foo::erase(iterator loc) { return data.erase(loc); }
// etc.

Because all the allocations related to foo's data member happen inside foo.cpp.

If your vector is of a custom type and not just int or unsigned char or whatever, you could also just use an extern template for the vector.

// foo.h
struct foo_data {
  int data;
};

using foo_vector = std::vector<foo_data>;
extern template class __declspec(export) foo_vector;

struct foo { ...

// foo.cpp
#include "foo.h"
foo_vector; // instantiate the code for vector<foo_data> in this .cpp file

I haven't ever actually the tried the latter, but it's documented by Microsoft more completely at http://support.microsoft.com/kb/168958.

In general, though, you should try to just stick to simple C wrapper APIs for DLL boundaries. You'll save yourself a huge ton of pain.

Thanks alot guys, This has pretty much cleared everything up.

Now, I need to review some content loading code because I have kinda made a mine field...

:)