德尔福 - 结构 字符串未被释放 [FastMM 管理器]
如果我声明
PSomeStruct = ^TSomeStruct;
TSomeStruct = record
s1 : string;
end;
并运行以下代码：
var
p: PSomeStruct;
begin
new(p);
p^.s1:= 'something bla bla bla';
dispose(p);
FastMM 4 内存管理器报告存在内存泄漏（类型：字符串，数据转储：“something bla bla bla”）。 但是，如果我在调用 dispose 之前将 s1 字符串设置为空，那就没问题了。
我发现的第二种方法是从记录类型更改为类，然后我创建实例而不是 new ，而不是 dispose 我正在调用 实例.Free()。 它无需手动清洁琴弦即可工作。
有没有办法让 Delphi 在我调用 dispose 时自动清理我的字符串？
If I declare
PSomeStruct = ^TSomeStruct;
TSomeStruct = record
s1 : string;
end;
and I run the following code:
var
p: PSomeStruct;
begin
new(p);
p^.s1:= 'something bla bla bla';
dispose(p);
the FastMM 4 memory manager reports that there was a memory leak (type: string, data dump: "something bla bla bla"). However, if I do set the s1 string to empty before calling dispose it's OK.
The second way I found is to change from record type to class, then instead of new I'm creating the instance, and instead of dispose I'm calling instance.Free(). It works without manually cleaning the strings.
Is there a way to make Delphi automatically clean my strings when I call dispose?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
FastMM 是您的 .dpr 中使用的第一个单位吗？ 否则，它可能会过早完成，报告错误的内存泄漏。
这个简化的代码示例是否也会产生与使用 JvSimpleXML 时相同的内存泄漏？ 如果不是，则可能发生的事情比您怀疑的还要多。
我认为：当FastMM报告内存泄漏时，就存在内存泄漏。
Is FastMM the first unit used in your .dpr? Otherwise it could be finalized too early, reporting false memoryleaks.
And does this simplified codesample also generate the same memoryleak as when you use your JvSimpleXML? When it's not, there is probably more going on then you suspect.
In my opinion: when FastMM reports a memory leak, there is a memoryleak.
你已经在做正确的事情了。 如果 FastMM 说该字符串已泄漏，则 FastMM 是错误的，或者它报告的字符串与您认为的字符串不同。
Dispose过程从记录中释放字符串。在这种特殊情况下，无论如何都不应该为该字符串分配任何内存。 它是一个字符串文字，所以我希望编译器分配该文字； 它的引用计数应该是
-1并且 FastMM 永远不应该看到它。You are already doing the correct thing. If FastMM says that string has leaked, then FastMM is wrong, or it's reporting a different string from the one you think it is. The
Disposeprocedure releases strings from records.In this particular case, there shouldn't have been any memory allocated for that string anyway. It's a string literal, so I'd expect the compiler to assign that literal; its reference count should be
-1and FastMM never should have seen it.