为什么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屋！