以下情况会导致记忆力出现问题吗?
假设我在 DLL 实现中具有以下内容(例如,它将有一个 cpp 文件):
class Base
{
protected:
Something *some;
public:
virtual void init()
{
some = new Something();
}
virtual ~Base()
{
delete some;
}
};
然后在我的 exe 中执行:
class Derived : public Base
{
public:
virtual void init()
{
some = new SomethingElse();
}
};
int main()
{
Base *blah = new Derived;
delete blah;
}
如果 DLL 使用与 exe 不同的运行时运行,这会导致问题吗?
如果是这样,是否有非 boost、非 c++ 0x 解决方案
谢谢
Say I have the following in a DLL implementation (eg, it would have a cpp file):
class Base
{
protected:
Something *some;
public:
virtual void init()
{
some = new Something();
}
virtual ~Base()
{
delete some;
}
};
Then in my exe I make:
class Derived : public Base
{
public:
virtual void init()
{
some = new SomethingElse();
}
};
int main()
{
Base *blah = new Derived;
delete blah;
}
Would this ever cause problems if the DLL is ran with a different runtime than the exe?
if so, is there a non boost, non c++ 0x solution
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我认为你需要像这样编写
~Derive()
解释:
为什么你需要这样写,即使
~Base()
执行同样的事情(看起来它做了同样的事情)是因为~Derived()
确保您从相同的对象中删除对象 它们是在堆/内存池/等上创建的。请参阅以下主题:
如何在 DLL 中使用类?
带有返回 char* 函数的内存管理
编辑:
更好的是要再添加一个虚拟函数,例如
deinit()
(与virtual void init()
相对应的部分),请在重新定义init 时重新定义它()
,并在 deinit() 中进行取消分配。I think you need to write
~Derive()
like thisExplanation :
Why you need to write this even though the
~Base()
does the same thing (it looks it does the same thing) is because~Derived()
ensures that you delete your object from the same heap/memory-pool/etc they were created on.See these topics:
How to use a class in DLL?
Memory Management with returning char* function
EDIT:
Better would be to add one more virtual function, say
deinit()
, (a counter-part of yourvirtual void init()
) , redefine this too when you redefineinit()
, and do the de-allocation there indeinit()
.Derived
分配了some
,因此它保留了释放它的责任。覆盖析构函数...如果您始终遵循该原则,那么您的内存处理会简单得多。
Derived
allocatedsome
, thus it maintains the responsibility to deallocate it. Overwrite the destructor...If you always follow that principle, then your memory handling is much simpler.
不会有任何问题,但显然
Derived
中包含的代码永远不会传递到其他可执行文件。如果
Something
派生自SomethingElse
并且具有虚拟析构函数,Base
的析构函数将正确删除some
。There won't be any problems, though obviously the code contained in
Derived
won't ever make it across to the other executable.The destructor for
Base
will correctly deletesome
providedSomething
derives fromSomethingElse
and has a virtual destructor.我认为你应该在它的构造函数中初始化一些东西。
否则析构函数将随机删除一块内存。
I think you should initialize something in its constructor.
Otherwise the destructor will delete a random piece of memory.
由于
protected
变量,它的代码很丑陋。我建议我们重新塑造它。首先,我们要确保所有所有权逻辑都是隔离的,以便更容易证明其正确性。
但这只是第一步,因为您不应该尝试直接操作资源,否则只会泄漏它们。所以现在,我们采用闪亮的界面并重塑实现:
不是更好吗?
It's ugly code because of the
protected
variable.I propose we reshape it up. First, let's make sure that all the ownership logic is insulated, so that it is easier to prove right.
It's only a first step though, because you should not try to manipulate resources directly, you're only going to leak them. So now, we take our shiny interface and reshape the implementation:
Isn't it much better ?