3

I am dealing with some legacy C/C++ code where memory is allocated using malloc as well as using new. I want to create a generalized wrapper function to deallocate the memory using either free or delete [] , depending on how it is allocated.

Is there a way to determine how memory is allocated ? Here is a pseudo code. 

double *x;
double *y;
x = (double *) malloc(size);
y = new double [size]

doSomething();
deallocateMemory(x, y);

I want deallocateMemory to determine whether to call free or delete [] . Any help would be appreciated.

Stefan Falk
  • 23,898
  • 50
  • 191
  • 378
cppb
  • 2,319
  • 8
  • 32
  • 37
  • 4
    As far as I know, you cannot do this. – Baum mit Augen May 12 '14 at 16:53
  • 1
    http://stackoverflow.com/questions/9702292/overriding-malloc-to-log-allocation-size – 001 May 12 '14 at 16:56
  • 2
    You should encode this in the type system using `std::unique_ptr` with an appropriate deleter. – Mankarse May 12 '14 at 16:56
  • often new is a direct forward to malloc and delete to free. As a result, all memory is allocated with malloc which is no problem at all. I can't see your intention of what you are doing. Can you explain a bit? Or do you try to manually call destructors while freeing memory? Thats a bad idea! – Klaus May 12 '14 at 17:05
  • If you can't change the actual `malloc()` implementation as suggested in @DevSolar's answer, what I can think of is wrapping up all that legacy API's with a c++ interfacing API that keeps track of what's going on, and what came from where. I'm posting this as a comment, because an appropriate answer would become pretty broad without knowing more details about the legacy API. – πάντα ῥεῖ May 12 '14 at 18:00

3 Answers3

6

Wrap the raw pointers in appropriate smart pointers (e.g. std::unique_ptr, std::shared_ptr) as soon as you take ownership.

Also, order a nine-tail cat and flog the persons responsible for the mess.

enter image description here

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
6

You can implement malloc() yourself instead of using the implementation provided by the standard library. You can also overload the operators new and delete. Nothing keeps you from adding your own bookkeeping to either of these implementations, so yes, this is perfectly possible.

Is it recommended? No it isn't.

This smacks of an attempt at implementing garbage collection. If this is true, you are looking at C++ from the wrong way. C++ does have its cleanup facility, which is its destructors. There are ready-made implementations of pointer containers, which in their destructors clean up the allocated memory. Others have mentioned them, and I don't copy-paste from other people's answers.

DevSolar
  • 67,862
  • 21
  • 134
  • 209
  • When the problem is spaghetti, solutions should preferably be *very* simple -- and implementing book-keeping allocation is about the most complex one can do. In another similar question's answer it was attempted, and very very incorrect. Chances are, if the OP tries this, it will only exacerbate the problems, and waste a lot of time. – Cheers and hth. - Alf May 12 '14 at 17:10
  • @DevSolar: actually I am trying to clear up the mess due to operloaded operators which is resulting in many problems! So, as you correctly said, I won't go that path. The legacy code has several convoluted malloc / new allocations whose origins are difficult/time consuming to trace given the size of the code.. so I was checking if there is any way to query how the memory is allocated. – cppb May 12 '14 at 17:11
2

You want to write

a generalized wrapper function to deallocate the memory

then you need to write

a generalized wrapper function to allocate the memory

and, it is not recommended at all. Try to make your goal clean. If you have to deal with malloc/free pointer in some part of your code and you can not modify malloc parts, then try not to mix that part with your new/delete part.

Otherwise, you have no standard way to determine what allocation method is used for a pointer.

masoud
  • 55,379
  • 16
  • 141
  • 208
  • When the problem is spaghetti, solutions should preferably be very simple -- and implementing book-keeping allocation is about the most complex one can do. In another similar question's answer it was attempted, and very very incorrect. Chances are, if the OP tries this, it will only exacerbate the problems, and waste a lot of time – Cheers and hth. - Alf May 12 '14 at 17:12