[boost] [filesystem] windows/posix inconsistencies.

Subject: [boost] [filesystem] windows/posix inconsistencies.
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2012-01-31 07:59:02

Hi Beman,

I noticed the following in v3 whie hunting down a bug in my unit test:

#   ifdef BOOST_WINDOWS_API
     const std::string string() const { return string(codecvt()); }
     const std::string string(const codecvt_type& cvt) const;

     //  string_type is std::wstring, so there is no conversion
     const std::wstring&  wstring() const { return m_pathname; }
     const std::wstring&  wstring(const codecvt_type&) const { return 
m_pathname; }

#   else   // BOOST_POSIX_API
     //  string_type is std::string, so there is no conversion
     const std::string&  string() const { return m_pathname; }
     const std::string&  string(const codecvt_type&) const;

     const std::wstring  wstring() const { return wstring(codecvt()); }
     const std::wstring  wstring(const codecvt_type& cvt) const

#   endif

I can understand, that it is more efficient to return a reference when
a referenec can be formed. However, consider

const std::string& ext = iter->path().extension().string();

This is fine on windows, as a temporary is returned, and its lifetime is 
extended; on linux, extension() returns a temp path object, from where 
we get a reference. I'm not a 100% sure, but I think the C++ standard 
does not guarantee that this path object be kept alive.

The net efffect is a crash on linux.

I'm not sure its a great idea to have different reference-ness on the 
return types here. It could lead to other subtle differences.

kind regards

-Thorsten