Thread: Failure to overload operator delete

I seem to be missing something. I'm failing to overload the delete operator for a class.

Code:

template<typename T> class DeleteChecker
{
public:
	DeleteChecker();
	~DeleteChecker();
	DeleteChecker(T* p);
	DeleteChecker(DeleteChecker& rRhs);
	DeleteChecker& operator = (DeleteChecker& rRhs);
	DeleteChecker& operator = (T* rRhs);
	T& operator * ();
	T* operator -> ();
	//void* operator new(size_t size);
	static void operator delete(void* /*pToDelete*/);
	operator bool() const;
	bool operator ! () const;
	const T& operator [] (uint32_t Dimension) const;
	T& operator [] (uint32_t Dimension);

private:
	void Init();
	struct DeleteData
	{
		T* p;
		uint32_t refCount;
		//uint32_t Dimensions;
		//bool 
	};

	DeleteData* m_pData;
};

Code:

int main()
{
	struct Test
	{
		int x, y, z;
	};
	DeleteChecker<Test> p = new Test;
	p->x = 0;
	delete p;
}

Error 1 error C2440: 'delete' : cannot convert from 'DeleteChecker<T>' to 'void *' g:\w00t\visual studio 2008\projects\temp\temp.cpp 175

Someone please try to jog my memory :/

I don't believe it should be static..

--
Mats

Nor do I, but it made little difference, since the compiler treated it as static anyway.
Removing "void*" causes another error instead.

Code:

void operator delete(void* /*pToDelete*/);

Error 1 error C2440: 'delete' : cannot convert from 'DeleteChecker<T>' to 'void *' g:\w00t\visual studio 2008\projects\temp\temp.cpp 175

Code:

void operator delete(); //(void* /*pToDelete*/);

Error 1 error C2802: static member 'operator delete' has no formal parameters g:\w00t\visual studio 2008\projects\temp\temp.cpp 33

Hang on, you are not deleting a pointer - you are deleting a proxy object. That won't work, you'll have to do something else (meaning, replace "delete" with some member function of your class).

--
Mats

Yeah, I am. I was trying to emulate the effect of delete in the object instead.
The aim was to emulate a pointer via a class with added debugging facilities.
Perhaps I should name it debug_ptr.

I can see what your idea is. I think you would have to make a pointer of the class itself to make this work. You may be able to hide this by using either macros or clever template programming (I can think of how you MAY be able to do it with macros, not at all convinced templates are able to do this).

--
Mats

Oh I see now what you mean.
I made a nasty hack to get around it:

Code:

operator debug_ptr* () { return this; }

Sssh. Don't tell anyone. It's the least I wanted to do and I'm sure it will cause multitude of problems, but let's test it first

1) new and delete are implicitly static, whether you add the keyword or not.

2) new and delete are you used when you allocate/delete an object of that class type. Obviously, for delete, that means using delete with a pointer to that type.

You cannot overload delete in a way that allows you to pass a plain object to it. You'll have to create a member function for that and call it the normal way. You cannot emulate pointer syntax here. Since it was expected that smart pointers (which is what the whole pointer syntax stuff was itnroduced for) would automatically delete objects, this was not seen as necessary.

Edit: Seems you actually found a trick to do this. Just be aware that this means you can't actually allocate a DeleteChecker on the heap.

Originally Posted by Elysia

Oh I see now what you mean.
I made a nasty hack to get around it:

Code:

operator debug_ptr* () { return this; }

Sssh. Don't tell anyone. It's the least I wanted to do and I'm sure it will cause multitude of problems, but let's test it first

I won't tell anyone, but I can tell you that I think it MAY work. That's how iterators and other proxy objcets works, isn't it?

--
Mats

Originally Posted by CornedBee

Edit: Seems you actually found a trick to do this. Just be aware that this means you can't actually allocate a DeleteChecker on the heap.

I know it will create all sorts of problem, but it wasn't meant to put on the heap anyway. I may as well disable the new operator to prevent disaster.
We'll see how this turns out

UPDATE:
It seems everything does not work as it should.
In fact... oh dear... it calls the destructor for debug_ptr FIRST and THEN operator delete!
Oh no. This is not how it was supposed to work.

Originally Posted by Elysia

I know it will create all sorts of problem, but it wasn't meant to put on the heap anyway. I may as well disable the new operator to prevent disaster.
We'll see how this turns out

UPDATE:
It seems everything does not work as it should.
In fact... oh dear... it calls the destructor for debug_ptr FIRST and THEN operator delete!
Oh no. This is not how it was supposed to work.

Well, that's what I'd expect, since you can't actually delete something FIRST, then destroy it, can you? So your destructor would have to do the "accounting" (and actual deleting of the object itself?), then let the delete operator just do what it needs to do [de-allocate, mainly].

--
Mats

But this is a problem. How does the destructor know if it goes out of scope or delete is called on it?
This kind of defies the need for the wrapper in the first place. Hmmm.

Originally Posted by Elysia

But this is a problem. How does the destructor know if it goes out of scope or delete is called on it?
This kind of defies the need for the wrapper in the first place. Hmmm.

So, have a flag somewhere to see if it was created by new or not? You could have a hidden space before the actual object, perhaps?

--
Mats

The biggest problem is that it checks for memory leaks, in the destructor.
The code is something like:

Code:

if (get_refCount() == 0)
{
	if (get_p() == NULL)
	{
		delete [] get_p();
		delete this; //m_pData;
		throw std::runtime_error("Memory leak detected!");
	}
	//delete m_pData;
	delete this;
}
else if (get_refCount() == 1 && m_pData->get_p())
{
	//delete m_pData;
	delete [] get_p();
	delete this;
	throw std::runtime_error("Memory leak detected!");
}

[Work in progress, and not the original code that was in the destructor. As you can see, it also has some bugs, too, which I haven't worked on correcting yet.]
The problem would be that the reference count == 1 and it would error.
The idea is that is the reference count == 1 and the object goes out of scope, that would mean a memory leak since it's the hold pointer holding the data.

I'm thinking of encapsulating the pointer in another class, so that it isn't affected by the destructor.

I personally woudl override the global new/delete operators, and just allocate an extra block of memory to hold some admin data to detect the memory leaks (such as a linked list of the line/file/func and size of the allocation). When the application finishes, you can check the linked list to see if it's got anything left that shouldn't be there, and list that to a file or some such.

--
Mats