The library forces new / delete global overloads on me!

Question

I support a plugin (implemented as a dll) for a large closed source application. This has worked great for many years. However, with the latest update to it, the SDK provider overloads global operators with new ones and deletes. This causes a lot of problems for me. What happens is that my plugin highlights a line. I pass this line to a statically linked library that modifies it (changes the length by redistributing it). My application crashes.

Of course, the reason is that the string lives on the distributed user heap of the provider. The statically linked library knows nothing about this heap and tries to use the default new / delete operators in this memory. Boom.

Now the question is: how can I keep my code clean and avoid using provider operators? A preprocessor macro does not exist. I can’t avoid including the offensive title, as it contains 2,000 lines more code that I need for the plugin. I cannot transfer the provided allocator to another library, because it does not provide any mechanisms for this. I already listened to this provider. I don't know what else could I try?

Addendum: After some heated debate, I managed to convince the seller to remove overloads from the next version of the SDK again. I solved my immediate problem by simply cracking the current SDK and removing the overloads manually. Thanks for all the suggestions in this thread. They served as arguments and further "proof" of why overloads were bad ideas in the first place.

Answer 1

If you compile (by including a header) the overridden new / deleted statements, then all calls to your code in new / delete will use them. It is not possible to redefine it (link errors) or partially redefine it, etc.

Bad form override global operators new / delete. It is a bad idea. If you do not understand why this is a bad idea, you cannot do it. If you understand why this is a bad idea, you have the right to do it, but usually you will not.

Defining a global new / delete is exponentially more evil in the component that you expect from directly incorporating people into your project. It is your job as a customer to help the seller do this, understand the gravity of the situation, or stop being a customer.

You can define a custom type of dispenser (see the link for a good tutorial on how to do this, you need an interface, etc.). and use this exclusively with your STL types (this is a template argument).

For shared_ptr, you need to do something completely different: it takes a deleter object as a parameter for the constructor, if you do not want the default "delete p" behavior. This is not a custom dispenser; it's just a regular unary functor.

Answer 2

Is it possible to do this:

namespace evil{ #include "evil_header.h" } 

Then what evil_header declares global new / delete becomes evil :: new / evil :: delete. I doubt it will play well if there are definitions without titles of things declared in evil_header, though.

Answer 3

You can use another new one in your namespace:

 namespace MyNS { // Declare your new/delete operators here // and also declare a class implementing the same interface as std::allocator // using your newly created memory management functions. // Don't forget to put all your classes in the namespace. // (if you don't have one already) } 

Then you can use all STL classes by providing them with a dispenser type as a template argument.

Answer 4

One option is to create your own overloaded new operator, which can be implemented in terms of malloc.

This can be determined as follows:

 enum MyNew {EMyNew};

 void * operator new (size_t size, MyNew);

This can be called by you as MyClass* myClass = new (EMyNew)MyClass;

Since this is implemented in terms of malloc, it should behave as expected. The only drawback is that you have to replace all instances of where you used the new ones.