Thread: private overloading of new & delete

Hi

I have been looking at some custom memory management and I am curious about new/delete overloading. I would like to know if one can limit overloaded new & delete operators to a template specific class (meaning all de-/allocations of all types occurring in the class are using the overloads). And also subject the overloads to the template for that class so different class variants use different overloads, while those overloads do not affect any code outside the given class. To give some more clarity se the example “code” below:

Code:

template <class Allocator>
class Dummy {
private:
	
	// the operators should only be used by the class itself.
	// assume Allocator is a class supplied with the necessary functions

	void *operator new (size_t size) {
		return Allocator::allocSomeMemory(size); // call template specific func.
	}

	void operator delete (void *ptr) {
		Allocator::deallocTheMemory(ptr); // call template specific function
	}

public:

	void foobar() {
		int *x = new int; // calls the overloaded new operator.
		// please note that the allocated object could be of any type,
		// including classes

		delete x; // calls the overloaded delete operator
	}
};

Unfortunately this code won’t compile and even if it would the overloads would only be called when de-/allocating the Dummy class, which is not desirable. Any help or ideas are highly appreciated.

I wasn't aware you could overload the new and delete keywords. You are sure you can do this?

@neandrake
Well if you use Visual C++ you may find this useful, if not then you may find it interesting.
you can also check this

- Micko

neandrake:
Yes it is possible even globally.

Micko:
I have tried googling to find an answer but only stumbled across simple how-to overload new and delete for general purposes, nothing in this field. I also check the article and source it seems to be a typical global memory tracer which can't help me. But thanks anyways

Thantos:
Thanks for the template syntax correction. The reason why it won't compile is because the overloaded new and delete operators need to be public members. But the main problem is that the overloads are only used for Dummy classes, thus if an outside function would dynamically create a Dummy instance the compiler would call the overloads, which is absolutely not my intention, hence the private access restriction. I tested Dummy::new but the compiler complained: “error C2834: 'operator new' must be globally qualified”

Actually, Thantos, your template syntax looks quite invalid to me. That would pass a constant instance of the Allocator class - which is not possible, because only primitives (and not even all of those, at least on some compilers) may be template value arguments.

And no, you couldn't do Dummy<int>, because then the compiler would try to invoke int's static member function "allocSomeMemory", resulting of course in an error.

The original syntax is fine, provided that whatever is passed for Allocator actually has those members.

Aidman: perhaps you'd like to look at how STL allocators work. The bottom line is, no, you can't replace new and delete for arbitraray objects just in your class, but you can call something different.

That might be because it calls the new for the T::Dummy you allocate but never delete. Print out the allocation size and make sure Dummy and int have different sizes.

Seems to be some Koening lookup going on.

You forgot:

Code:

void* operator new(std::size_t t)
        {
                std::cerr<<"Hello I'm new for "<< t << " bytes\n";
                return malloc(t);
        }
        void operator delete(void *ptr)
        {
                std::cerr<<"Laters for "<< ptr <<" address.\n";
                free(ptr);
        }

The write out the address in main.

Hmmm... it really allocates the int with the overloaded one. But why not deallocate?

Code:

A dummy is: 16 bytes large
An int is 4 bytes large
Hello I'm new for 4 bytes
Dummy: 0x5020a0
p = 5
Laters for 0x5020c0.
Meh?

(64-bit machine, so int* is 8 bytes.)

And the solution to the puzzle comes from the C++ standard, §3.7.3.1:

An allocation function shall be a class member function or a global
function; a program is ill-formed if an allocation function is
declared in a namespace scope other than global scope or declared
static in global scope.

GCC is incorrect in even compiling this code, and the behaviour is undefined.

Read also here:
http://groups-beta.google.com/group/...e&rnum=1&hl=en
This also mentions that Comeau C++ refuses to compile the code.

Nice try Thantos, good idea with the namespace even thought it wasn't supposed to work. However an esential part of my problem would still remain had the solution worked. Letting the class user have the option of choosing allocator for the class ex. via templates.