Delphi中Peter Below的代码是否存在内存泄漏问题？

更新于

2026-10-05 02:24:04

1阅读来源：SEO问题

内容介绍
文章标签
相关推荐

本文共计499个文字，预计阅读时间需要2分钟。

我知道我不应该直接跳过Peter Peter，但在尝试调试一些旧的D5代码时，我发现了一个关于Text File Size的代码片段。看起来应该将Sysutils.FindClose称为函数的最后一行。如果结果为零，那可能意味着没有建立FindFirst。

我知道我不应该问Peter Peter,但我在尝试调试一些旧的D5代码时发现了这个代码片段 Text File Size.

在我看来,应该将Sysutils.FindClose称为函数的最后一行.如果结果为零,那是不是建立了FindFirst并挂起？

更多问题：它表明这是针对文本文件的,但是这不能用于任何文件类型吗？一个更好的Delphi.FileSize(fname：string); ？

function TextfileSize(const name: string): LongInt; var SRec: TSearchRec; begin if FindFirst(name, faAnyfile, SRec) = 0 then begin Result := SRec.Size; Sysutils.FindClose(SRec); end else Result := 0; end;

It seems to me that the Sysutils.FindClose should be called as the last line of the function. If the Result is zero, doesn’t that leave the FindFirst established and hanging?

不.如果FindFirst失败,您不需要调用FindClose.对于现代版本的Delphi,无论FindFirst的结果如何,都可以安全地调用它.对于旧版本的Delphi,需要问题中的条件代码.无论如何,这里没有泄漏.

不幸的是,文档没有说清楚.确保这一点的唯一方法是阅读源代码.

It states this is for Text files, but couldn’t this be used for any file type?

对于所有类型的文件,此函数的运行方式完全相同.

A better Delphi.FileSize(fname : string); ?

我不知道你指的是哪个函数,但你问题中的函数有两个缺点.首先,它返回一个32位有符号整数,因此为大于2GB的文件提供错误输出.其次,它从文件系统元数据中读取文件大小,这可能并不总是与真实文件大小相匹配.后一个问题可能不是你应该关注的问题.使用存储在文件系统元数据中的文件大小通常是合理的.

标签：Delphi –这个 Peter Below