🔒 Locked

Problems overriding operator new

Started by OrangyTang Aug 31, 2006 at 3:40 PM 1 replies 850+ views

Original Post

Aug 31, 2006 at 3:40 PM

I don't often monkey about with custom new/new[]/delete/delete[] implementations, so they're not an area I'm particularly comfortable with. Hopefully the knowledgable people here will be able to shed some light on this. I'm trying to trap and handle memory allocation for a whole complete system, but having trouble making sure that *all* allocations get handled by my own custom stuff. (for the sake of clarity I've omitted which delete operators I'm overriding, as it should be obvious). Problem 1: I have a Foo class, so in the class itself I provide a custom Foo::operator new and Foo::operator new[]. Unfortunately the following doesn't get caught: Foo* pFoos = new Foo*[numFoos]; I can only assume that since I'm allocating an array of Foo* rather than just Foo the compiler somehow decides that neither of the custom new operators is appropriate and I fall though to the global new. How can I catch this allocation (other than replacing the global new)? Problem 2: I need to do this for a whole range of classes, and adding custom new/delete operators to each class is not great. A macro or two would simplify things but it's still not ideal really. So I thought I'd override the new/new[] for the entire namespace that all of the classes are in. I was somewhat surprised to find my compiler replying with "Can't override operator new for namespace" (or something similar, I havn't got my compiler on me). This puzzles me - to me it's a logical use of namespaces to scope a custom operator and should work nicely for my problem. Yet apparently it's not allowed. A quick google doesn't offer any enlightment, other than people reporting it (falsely) as a compiler bug. I assume theres some kind of reason, so why isn't this allowed? Currently the only alternative implementation I can think of is to have a base class SomeObjectWhosAllocationIsHandledManually, define my custom allocation operators in there, and have every class inherit from it. However as a solution this feels a bit hacky and non-intuitive. Cheers

Enigma

Aug 31, 2006 at 4:28 PM

Quote:
Original post by OrangyTang
I don't often monkey about with custom new/new[]/delete/delete[] implementations, so they're not an area I'm particularly comfortable with. Hopefully the knowledgable people here will be able to shed some light on this. I'm trying to trap and handle memory allocation for a whole complete system, but having trouble making sure that *all* allocations get handled by my own custom stuff. (for the sake of clarity I've omitted which delete operators I'm overriding, as it should be obvious).

Problem 1:
I have a Foo class, so in the class itself I provide a custom Foo::operator new and Foo::operator new[]. Unfortunately the following doesn't get caught:

Foo* pFoos = new Foo*[numFoos];

I can only assume that since I'm allocating an array of Foo* rather than just Foo the compiler somehow decides that neither of the custom new operators is appropriate and I fall though to the global new. How can I catch this allocation (other than replacing the global new)?

You can't. You have to replace global new[].

Quote:
Problem 2:
I need to do this for a whole range of classes, and adding custom new/delete operators to each class is not great. A macro or two would simplify things but it's still not ideal really. So I thought I'd override the new/new[] for the entire namespace that all of the classes are in. I was somewhat surprised to find my compiler replying with "Can't override operator new for namespace" (or something similar, I havn't got my compiler on me).

This puzzles me - to me it's a logical use of namespaces to scope a custom operator and should work nicely for my problem. Yet apparently it's not allowed. A quick google doesn't offer any enlightment, other than people reporting it (falsely) as a compiler bug. I assume theres some kind of reason, so why isn't this allowed?

I don't know the official reason, but it's logical to me that you can't override new in a namespace. What would happen if you allocated an object in a function in one namespace with it's own new and delete and deleted it in another namespace with a differing implementation of delete?

Quote:
Currently the only alternative implementation I can think of is to have a base class SomeObjectWhosAllocationIsHandledManually, define my custom allocation operators in there, and have every class inherit from it. However as a solution this feels a bit hacky and non-intuitive.

Is there a reason you don't want to replace the global allocation functions? If so then take solace, your proposed solution is so "hacky and non-intuitive" that Scott Meyers presents almost exactly that solution to a similar problem in Item 7 of Effective C++.

Σnigma

OrangyTang

Aug 31, 2006 at 6:01 PM

Quote:
Original post by Enigma
I don't know the official reason, but it's logical to me that you can't override new in a namespace. What would happen if you allocated an object in a function in one namespace with it's own new and delete and deleted it in another namespace with a differing implementation of delete?

Yes, I can see several potential problems, but nothing totally catastrophic (especially given the number of special cases and undefined behaviours C++ already has). The most simple form might just act as if the custom new/delete operators were done per-class (instead of me having to do the base class trick).

The reason I don't want to override global new/delete is that they're already overridden for a different purpose, possibly by something external and out of my control.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.