如何在 #define 中分配变量名(Boost 相关的 Mem Leak)?

发布于 2024-11-17 20:29:47 字数 1056 浏览 0 评论 0原文

我在我们正在开发的应用程序上运行了内存验证器,我发现我们定义的宏表达式是大约 90% 泄漏的根源。 #定义O_set。

现在,我们的宏定义如下:

#define O_SET_VALUE(ValueType, Value) boost::shared_ptr<ValueType>(new ValueType(Value))
.
.
#define O_set O_SET_VALUE

但是,根据 Boost 网站(位于:http://www.boost.org/doc/libs/1_46_1/libs/smart_ptr/shared_ptr.htm):

一个简单的指南,几乎 消除记忆的可能性 泄漏是:始终使用命名的 smart 保存结果的指针变量 新的。每一次新事物的出现 代码中的关键字应该是 形式:shared_ptr p(new Y);这是, 当然,可以使用另一个 智能指针代替shared_ptr 多于; T 和 Y 相同 类型,或将参数传递给 Y 构造函数也可以。

如果您遵守本指南, 自然而然你就会有 没有显式删除;尝试/捕捉 构造将会很少见。

这让我相信这确实是我们内存泄漏的主要原因。或者我太天真了,或者完全超出了我的能力范围?

问题是,有没有办法使用上面的宏 #defines 来解决上述问题?

更新: 例如,我正在使用它们,如下所示:

return O_set(int, 1); _time_stamp(O_set(TO_DateTime, TO_DateTime())) (_time_stamp 是某个类的成员)

我在 Windows 中工作并使用 MemoryValidator 来跟踪内存泄漏 - 根据它,存在泄漏 -正如我所说,其中大部分(根据堆栈跟踪)的根源都归结为宏#define。

I've ran Memory Validator on an application we're developing, and I've found that a Macro expressions we've defined is at the root of about 90% of the leaks. #define O_set.

Now, our macros are defined as follows:

#define O_SET_VALUE(ValueType, Value) boost::shared_ptr<ValueType>(new ValueType(Value))
.
.
#define O_set O_SET_VALUE

However, according to the Boost web site (at: http://www.boost.org/doc/libs/1_46_1/libs/smart_ptr/shared_ptr.htm):

A simple guideline that nearly
eliminates the possibility of memory
leaks is: always use a named smart
pointer variable to hold the result of
new. Every occurence of the new
keyword in the code should have the
form: shared_ptr p(new Y); It is,
of course, acceptable to use another
smart pointer in place of shared_ptr
above; having T and Y be the same
type, or passing arguments to Y's
constructor is also OK.

If you observe this guideline, it
naturally follows that you will have
no explicit deletes; try/catch
constructs will be rare.

This leads me to believe that this is indeed the major cause of our memory leaks. Or am I being naive or completely out of my depth here?

Question is, is there a way to work around the mentioned issue, with the above macro #defines?

Update:
I'm using them, for example, like this:

return O_set(int, 1);
_time_stamp(O_set(TO_DateTime, TO_DateTime())) (_time_stamp is a member of a certain class)

I'm working in Windows and used MemoryValidator for tracking the Memory Leaks - according to it there are leaks - as I state, the root of most of which (according to the stack traces) come down to that macro #define.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

虚拟世界 2024-11-24 20:29:47

智能指针很棘手。我要做的第一件事是检查代码中是否有任何不在两个宏内的“新”语句。

然后你必须考虑指针是如何使用的;例如,如果通过引用传递智能指针,则引用计数器不会增加。

另一件要检查的事情是“.get()”的所有实例,如果您正在使用遗留代码库或其他不理解使用智能指针要点的开发人员,这将是一个大问题! (这更多的是为了防止随机崩溃而不是内存链接本身,但值得检查)

此外,您可能需要考虑为什么要使用宏来创建所有智能指针。 Boost针对不同的目的提供不同的智能指针。没有一种万能的解决方案。好的旧 std::auto_ptr 对于大多数用途来说都很好,除了存储在标准容器中,但您已经知道了。

最明显和被忽视的方面是,您真的需要“新”东西吗? C++ 不是 Java,如果您可以避免创建动态对象,那么最好这样做。

如果您足够幸运能够使用 *NIX 平台(抱歉,您没有提及),那么请尝试使用 Valgrind 的泄漏检查工具。这非常有用。 Windows 上也有类似的工具,但通常使用您的软件技能是最好的。

祝你好运。

Smart pointers are tricky. The first thing I would do is to check your code for any 'new' statement which isn't inside either macro.

Then you have to think about how the pointers are being used; if you pass a smart pointer by reference, the reference counter isn't increased, for example.

Another thing to check is all instances of '.get()', which is a big problem if you are working with a legacy code base or other developers who don't understand the point of using smart pointers! (this is more to do with preventing random crashes than memory links persé, but worth checking)

Also, you might want to consider why you are using a macro for all smart pointer creation. Boost supply different smart pointers for different purposes. There isn't a one size fits all solution. Good old std::auto_ptr is fine for most uses, except storing in standard containers, but you knew that already.

The most obvious and overlooked aspect is, do you really need to 'new' something. C++ isn't Java, if you can avoid creating dynamic objects you are better off doing so.

If you are lucky enough to be working with a *NIX platform (you don't mention, sorry) then try the leak checking tool with Valgrind. It's very useful. There are similar tools available for windows, but often using you're software skilz is best.

Good luck.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文