一个图书馆迫使我对新/删除的全局过载！ [英] a library forces global overloads of new/delete on me!

问题描述

我正在为一个大型闭源应用程序维护一个插件(作为 dll 实现).这多年来一直运作良好.然而，随着 SDK 的最新更新，供应商超载了全局操作符 new 和 delete.这给我带来了很多麻烦.发生的情况是我的插件分配了一个字符串.我将此字符串传递到静态链接库中，该库对其进行修改(更改其长度从而重新分配它).我的应用程序崩溃了.

I'm maintaining a plugin (implemented as a dll) for a big closed source application. This has been working fine for years. However, with the latest update to it's SDK the vendor overloaded global operators new and delete. This causes lots of trouble for me. What happens is that my plugin allocates a string. I pass this string into a statically linked library which modifies it (changes it's length thus reallocating it). My application crashes.

原因当然是字符串存在于供应商分配的自定义堆上.静态链接库对该堆一无所知，并尝试在该内存上使用默认的 new/delete 运算符.繁荣.

The reason is of course, that the string lives on the vendor allocated custom heap. The statically linked library knows nothing about this heap and tries to use the default new/delete operators on that memory. Boom.

现在的问题是:我怎样才能保持我的代码干净并避免使用供应商的操作符?没有条件预处理器宏.我无法避免包含有问题的标头，因为它包含插件所需的 2000 行代码.我无法将提供的分配器传递到另一个库中，因为它没有为此提供任何机制.我已经就此事向供应商提出了问题.我不知道我还能尝试什么?

Now the question is: how can I keep my code clean and avoid using the vendor's operators? There is no conditional preprocessor macro. I can not avoid including the offending header since it contains 2000 lines more code I need for the plugin. I cannot pass the provided allocator into the other library since it does not provide any mechanisms for that. I have already bugged the vendor about it. I don't know what else I could try?

附录: 经过一番激烈的辩论，我设法说服供应商从 SDK 的下一个版本中再次删除重载.我通过简单地破解当前的 SDK 并手动删除重载解决了我的直接问题.感谢此线程中的所有建议.它们作为论证和进一步证明"为什么重载首先是一个坏主意.

Addendum: After some heated debate I have managed to convince the vendor to remove the overloads again from the next version of the SDK. I have solved my immediate problem by simply hacking 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 the overloads were a bad idea in the first place.

推荐答案

如果您正在编译(通过标头包含)重写的 new/delete 运算符，则代码中对 new/delete 的所有调用都将使用他们.无法重新覆盖它(链接错误)或仅部分覆盖它等.

If you're compiling in (via header inclusion) an overridden new/delete operator(s), then all calls in your code to new/delete will use them. There is no way to re-override it (link errors) or only partially override it, etc.

重写全局新/删除操作符是一种糟糕的形式.这是个坏主意.如果你不明白为什么这是一个坏主意，你就没有资格这样做.如果您确实意识到为什么这是一个坏主意，您就有资格这样做，但您通常会选择不这样做.

It is bad form to override the global new/delete operators, at all. It's a bad idea. If you don't realize why it's a bad idea, you're not qualified to do so. If you do realize why it's a bad idea, you're qualified to do so, but you'll generally choose not to.

在您希望人们直接包含到他们的项目中的组件中，定义全局新建/删除操作的危害成倍增加.作为客户，您的工作是帮助供应商了解情况的严重性，或者不再是他们的客户.

Defining a global new/delete is exponentially more evil in a component you expect people to include directly into their project. It is your job as a customer to help the vendor doing this understand the seriousness of the situation, or stop being their customer.

您可以定义自定义分配器类型(请参阅此 链接以获取有关如何执行此操作、所需接口等的良好教程的链接，并将其专门用于您的 STL 类型(它是一个模板参数).

You can define a custom allocator type (see this link for a good tutorial on how to do so, the interface needed, etc) and use that exclusively with your STL types (it's a template argument).

对于shared_ptr，你需要做一些不同的事情:如果你不想要默认的删除p"行为，它需要一个删除器对象作为构造函数的参数.这不是自定义分配器；它只是一个普通的一元函子.

For shared_ptr, you need to do something a little different: it takes a deleter object as a parameter to the constructor if you don't want the default "delete p" behavior. This isn't a custom allocator; it's just a regular unary functor.

这篇关于一个图书馆迫使我对新/删除的全局过载！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！