Why does boost::filesystem::path::string() return by value on Windows and by reference on POSIX?

问题

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

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?

回答1:

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.

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.

回答2:

For windows API it returns by value because the variable 'm_pathname' needs to be converted into a different format (string) as implemented by 'path_traits'. This introduces a temporary variable which of course cannot be passed by reference, though the extra copy will get elided by either NRVO or by implicit move.

For the posix case, the format of 'm_pathname' is already in native format (string), so no need to convert and hence can be passed as const reference.

来源：https://stackoverflow.com/questions/37529670/why-does-boostfilesystempathstring-return-by-value-on-windows-and-by-ref