2

I've overridden new so that I can track memory allocations. Additional parameters such as __FILE__, __LINE__, module name etc are added in the #define.

However I want to add the address of the calling object to the parameters so that I can backtrack up allocations when hunting down problems. The easiest way is to add 'this' to those additional parameters (which means the address of the caller is passed into my custom alloc stuff).

Unfortunately there's plenty of singletons in our code, which means a bunch of static member functions calling new. The compiler throws up the error C2671: '...' : static member functions do not have 'this' pointers

Is there a workaround where I can get the address of the object without using this, which would also realize it's in a static method and pass null say?

Or maybe is there a way that my #define new would recognize it's in a static method and switch to a different definition?

It's important that I don't affect the existing project code though - I don't want to force developers to use a custom method like staticnew just because it's in a static method - they should carry on using new like normal and this memory tracking stuff is all going on in the background...

Dummy00001
  • 16,630
  • 5
  • 41
  • 63
Mush
  • 133
  • 1
  • 6
  • 7
    Okay, this is not going to help but... "Unfortunately there's plenty of singletons in our code" is probably the root of all evil. – Raveline Sep 20 '10 at 12:38
  • OMG re-`#define`-ing the `new`. Why reinventing memory debuggers?? `I don't affect the existing project code` - LOL, that's precisely what proprocessor macro accomplish - in a stealth fashion. – Dummy00001 Sep 20 '10 at 12:46
  • [A *dup* of one of this](http://stackoverflow.com/search?q=track+memory+c%2B%2B). For example ["track C++ memory allocations"](http://stackoverflow.com/questions/910172/track-c-memory-allocations). Unless poster desires to reinvent a wheel. – Dummy00001 Sep 20 '10 at 12:51
  • Instead of using #define to replace new, is it possible to use LD_PRELOAD to do this? I've only ever used it in this context for C code. – Bill Lynch Sep 20 '10 at 12:53
  • yeah I know what you're all saying, but it's what I've got to work with :-) There's a lot of custom heap allocation stuff going on already (we do video games), so yes we're reinventing the wheel, and yes it's not ideal, and no, I can't really use stuff like valrgind (since they redefine new themselves, which cuts out all our custom stuff) – Mush Sep 20 '10 at 13:05

2 Answers2

5

You definitely cannot determine if a #define macro is inside a static method or not. You even shouldn't be using #define new as it violates the standard (even though all compilers support it). Your macro will also cause trouble to those who want to overload operator new for their class.

Generally, I would suggest not using this kind of memory debugging. There are many mature memory debuggers that do a better work when debugging memory errors. The most famous one is Valgrind.

To give a simple answer to your question - there is no clean solution in the way you are approaching the problem.

Karel Petranek
  • 15,005
  • 4
  • 44
  • 68
  • I think you're right. I'm just going to have to take a different approach, somehow... – Mush Sep 20 '10 at 14:30
0

Well, once you're going down the "hack" path, you could throw portability out the window and get close to the compiler.

You could put some inline assembler in your macro that called a function with a pointer to the string generated by __FUNCDNAME__, and if it looks like a member function get the this pointer in the assembler, and if not just use null.

janm
  • 17,976
  • 1
  • 43
  • 61