tags:

views:

1045

answers:

5

i'm making a little memory leak finder in my program, but my way of overloading new and delete (and also new[] and delete[]) doesn't seem to do anything..

void* operator new (unsigned int size, const char* filename, int line)
{
    void* ptr = new void[size];
    memleakfinder.AddTrack(ptr,size,filename,line);
    return ptr;
}

that way i overloaded it.. i guess it's something with the operator returning void* but i wouldn't know what to do about it.

+2  A: 

Are you invoking the overloaded operator correctly, i.e., passing it the additional parameters?

zvrba
+7  A: 
void* ptr = new void[size];

Can't do that. Fix it.

Never ever try to overload new/delete globally. Either have them in a base class and derive all your objects from this class or use a namespace or a template allocator parameter. Why, you may ask. Because in case your program is more than a single file and using STL or other libraries you are going to screw up.

Here's a distilled version of new operator from VS2005 new.cpp:

void * operator new(size_t size) _THROW1(_STD bad_alloc)
{       // try to allocate size bytes
   void *p;
   while ((p = malloc(size)) == 0)
    if (_callnewh(size) == 0)
     {       // report no memory
        static const std::bad_alloc nomem;
        _RAISE(nomem);
     }

     return (p);
}
dirkgently
Actually, I had a good reason to do that once. We had a compiler "issue" where it was using heaps in an unsafe way across DLL boundries. The fix was to create a custom version of "new" that used a specific named heap.
T.E.D.
Why did you not file a bug and instead chose to play with fire?
dirkgently
We did. The response we got back was something along the lines of "DLLs don't work very well cross-process in our system". We eventually quit using them, but in the short term this fixed the problem.
T.E.D.
LOL. Anyway, there are better alternatives to globally overloading new/delete as I have mentioned already.
dirkgently
There will be no problems with libraries and everything else if you will not try to deallocate memory that wasn't allocated by you (and vice versa). And STL can use custom memory allocators. We use custom new/delete operators in debug builds for long time and have no problems.
n0rd
Yes, very true. But this is difficult to manage. We too use custom allocators (and have been using for a while now). I mentioned STL custom above I believe.
dirkgently
+1  A: 

The problem relies with the two arguments that you have added to the overloaded new operator. Try making filename and line global in some way (or member variables if you're overloading new and delete for a single class). That should work better.

Benoît
+2  A: 

I think the problem here is that your new's parameter profile doesn't match that of the standard operator new, so that one isn't getting hidden (and is thus still being used).

Your parameter profiles for new and delete need to look like this:

void* operator new(size_t);
void operator delete(void*, size_t);
T.E.D.
+1  A: 

Maybe you can do what you want with a little bit of preprocessor magic:

#include <iostream>

using namespace std;

void* operator new (unsigned int size, const char* filename, int line) {
    void* ptr = new char[size];
    cout << "size = " << size << " filename = " << filename << " line = " << line << endl;
    return ptr;
}

#define new new(__FILE__, __LINE__)

int main() {
    int* x = new int;
}
kyku