Linux size_t 和 off_t 的用法区别是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10634629/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What are the usage differences between size_t and off_t?
提问by Lee Netherton
Other than the size of the values that each type can hold, what are the main differences in usagebetween size_tand off_t? Is it just a convention that size_ttypes are used for absolute sizes and off_ttypes are used for offsets? Or does it go deeper than that?
除了每种类型可以容纳的值的大小之外，和之间的主要用法区别是什么？类型用于绝对大小而类型用于偏移是否只是一种约定？或者它比那更深？size_toff_tsize_toff_t
I am writing a wrapper class to enable the writing of large files using mmapand I want to know what the best types are to use for their arguments. Given that I want to write to files > 4GB, I'm tempted to use size_t for everything, but is that the best practice? (or should I be using some off64_ttypes for certain functions?)
我正在编写一个包装类来启用大文件的编写，mmap我想知道最好的类型是用于它们的参数。鉴于我想写入大于 4GB 的文件，我很想将 size_t 用于所有内容，但这是最佳实践吗？（或者我应该off64_t为某些功能使用某些类型吗？）
For example, should my writeAtfunction be declared as:
例如，我的writeAt函数是否应该声明为：
MMapWriter::writeAt(off64_t offset, const void* src, size_t size)
or
或者
MMapWriter::writeAt(size_t offset, const void* src, size_t size)
采纳答案by Steve Jessop
size_tis for objects, off_tis for files.
size_t用于对象，off_t用于文件。
mmapmerges the two concepts, pretty much by definition. Personally I think I'd use size_t, since no matter what else it is, a mapped file is also an array in (virtual) memory.
mmap几乎根据定义合并了这两个概念。我个人认为我会使用size_t，因为无论它是什么，映射文件也是（虚拟）内存中的数组。
size_tis standard C++, off_tis Posix, and off64_tis a GNU extension that goes with the functions fopen64, ftello64, etc. I thinkit should always be the same type as off_ton 64 bit GNU systems, but don't bet your company on that without checking.
size_t是标准的 C++，off_t是 Posix，off64_t是一个 GNU 扩展，与函数fopen64、ftello64等一起使用。我认为它应该始终与off_t64 位 GNU 系统上的类型相同，但不要在没有检查的情况下把你的公司押在这一点上。
Should it be relevant, off_tis signed whereas size_tis unsigned. But the signed counterpart to size_tis ptrdiff_t, so when you need a signed type it doesn't automatically mean you should use off_tor off64_t.
如果相关，off_t则已签名而未size_t签名。但是签名对应的size_t是ptrdiff_t，因此当您需要签名类型时，它并不自动意味着您应该使用off_t或off64_t。
回答by James Kanze
size_tis part of the C++ (and C) standards, and refers to the type of a sizeofexpression. off_tis defined by the Posix standard, and refers to the size of a file.
size_t是 C++（和 C）标准的一部分，指的是sizeof表达式的类型。 off_t由 Posix 标准定义，指文件的大小。
回答by ericcurtin
Good rule of thumb for this scenario. Use whatever function signature that results in you using the least amount of explicit casting, be it c style or c++ style. If you have to cast, c++ style is safer as it is more limited in the types of cast it can do.
这种情况的良好经验法则。使用任何导致您使用最少显式转换的函数签名，无论是 c 风格还是 c++ 风格。如果必须进行转换，c++ 风格更安全，因为它可以执行的转换类型受到更多限制。
The benefit of this is if you port to a platform where the types don't match up (whether it be a signed, size or endianness issue etc.), you should catch most of the bugs at compile time, rather than at runtime. Casting is the sledgehammer approach for squeezing a triangular shaped object into a round hole (more or less your telling the compiler to keep quiet, I know what I'm doing).
这样做的好处是，如果您移植到类型不匹配的平台（无论是有符号、大小还是字节序问题等），您应该在编译时捕获大部分错误，而不是在运行时。铸造是将三角形物体挤压成圆孔的大锤方法（或多或少是你告诉编译器保持安静，我知道我在做什么）。
Trying to find casting issues at runtime can be a pain as it can be hard to reproduce. It's better to find issues at compile-time rather than runtime. The compiler is your friend.
尝试在运行时查找转换问题可能会很痛苦，因为它很难重现。最好在编译时而不是运行时发现问题。编译器是你的朋友。
