为什么boost :: filesystem :: path :: string()在Windows上按值返回,而在POSIX上按引用返回? [英] Why does boost::filesystem::path::string() return by value on Windows and by reference on POSIX?
问题描述
从boost/filesystem/path.hpp:
From boost/filesystem/path.hpp:
# ifdef BOOST_WINDOWS_API
const std::string string() const
{
[...]
}
# else // BOOST_POSIX_API
// string_type is std::string, so there is no conversion
const std::string& string() const { return m_pathname; }
[...]
# endif
对于wstring(),则完全相反-在Windows上按引用返回,在POSIX上按值返回.有一个有趣的原因吗?
For wstring() it is exactly the other way around - returning by reference on Windows and by value on POSIX. Is there an interesting reason for that?
推荐答案
在Windows上,path
存储wstring
,因为在Windows中处理Unicode编码路径的唯一方法是使用UTF-16.在其他平台上,文件系统通过UTF-8(或足够接近)处理Unicode,因此在那些平台上,path
存储string
.
On Windows, path
stores a wstring
, since the only way to handle Unicode-encoded paths in Windows is with UTF-16. On other platforms, the filesystems handle Unicode via UTF-8 (or close enough), so on those platforms, path
stores a string
.
因此,在非Windows平台上,path::string
将返回对实际内部数据结构的const引用.在Windows上,它必须生成std::string
,因此它将通过副本返回.
So on non-Windows platforms, path::string
will return a const-reference to the actual internal data structure. On Windows, it has to generate a std::string
, so it returns it by copy.
Note that the File System TS bound for C++17 does not do this. There, path::string
will always return a copy. If you want the natively stored string type, you must use path::native
, whose type will be platform-dependent.
这篇关于为什么boost :: filesystem :: path :: string()在Windows上按值返回,而在POSIX上按引用返回?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!