4

有没有办法绕过覆盖operator new？

像这样的东西：

void* ::operator new( std::size_t size ) {
    void *p = ( ::operator new( size ) );  // But original, _not_ infinite recursion
    // do stuff with p
    return p; 
}

背景： 我有一些遗留代码，我们最近切换到使用 Visual Studio 2012 编译。现在，当内存块不足时malloc，我们会随机崩溃。_heap_alloc（是的，代码到处都是小内存泄漏和其他不良行为。但不幸的是，彻底清理是不现实的，大约是 500 000 SLOC。）

我目前的理论是，原因是几乎所有源文件都包含一个带有以下覆盖的标头operator new：

void* ::operator new( std::size_t size ) {
    void* p = malloc( size );
    if( p == NULL )
        throw;
    // set memory to zero
    memset( p, 0, size );
    return p;
};

void* ::operator new[]( size_t count ) throw(std::bad_alloc) {
    // try to allocate count bytes for an array
    return (operator new(count));
}

没有覆盖delete.

从本质上讲，这意味着应用程序将分配使用malloc与释放使用delete而不是混合使用free。

首先尝试 Q&D 修复：引入delete使用free. 但这只是部分帮助，因为有时包含订单和链接库仍然会搞砸。

第二次尝试 Q&D 修复：删除覆盖。但不幸的是，将内存初始化为 0 是必要的。使用的旧编译器的遗产，它总是这样做，而假设 C++ 的编码器将总是这样做。

我知道 new() 会解决这个问题，但不幸的是，我不知道有什么好的方法可以在不手动浏览所有源代码并更新它的情况下使用它。它也无助于实现不佳的类，这些类假设所有成员都被无效化，而不在构造函数中这样做。

因此，我对 Q&D 修复的第三个想法：在覆盖中使用正常的 new，正如这个问题所问的那样。

4

1 回答 1

2

有没有办法绕过 operator new 的覆盖？

我不知道，但你为什么不简单地在你的自定义函数中重新实现它，就像 MS 在他们的基于 _heap_alloc 的实现中所做的那样，只是将你的自定义添加到它？

无论如何，只有一次生死攸关的分配尝试不是 MS 所做的：

http://msdn.microsoft.com/en-us/library/vstudio/we2zys4d.aspx

默认行为是执行循环。在循环内，函数首先尝试分配请求的存储空间

无论如何-我支持nm发表的评论

你需要修复真正的内存错误

那是不言自明的；对于那些任何调试目的 - 请看看 std::set_new_handler。

顺便说一句 - 我觉得你的代码有些烦人的地方

  • 运营商的明确资格
  • 不抛出 std::bad_alloc 而是在 catch-block 之外重新抛出

快乐黑客！

问候，S。

PS：@all：由于我在这里的经验有限，我不能“投票”这个问题，但我建议这样做。这是一个非常有趣的话题，而且表述得很好。

于 2013-05-14T11:27:30.250 回答