Re: [boost] [filesystem] windows/posix inconsistencies.

Subject: Re: [boost] [filesystem] windows/posix inconsistencies.
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-02-02 09:14:18

On Tue, Jan 31, 2012 at 7:59 AM, Thorsten Ottosen
<thorsten.ottosen_at_[hidden]> wrote:
> 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.

This thread directly or indirectly raises a number of issues:

* Is a return type that differs between platforms too error prone?

It's a tradeoff I agonized over during the design of V3. Returning by
value regardless of platform is a perceived performance penalty and
may be a real performance penalty for some path intensive
applications. Using a non-const reference argument results in verbose
user code and has the same performance issues as return by value.

* Class path has several functions that logically should return
basic_strings but return paths because paths support multiple string
types. Is there a better alternative?

This one deserves some investigation. Returning a path is a cop-out.
Could the functions be templatized on the string return type desired?

* Const return types inhibit move semantics.

That's a known issue, raised by Howard Hinnant and other LWG members.
The plan is to address it as part of applying C++11 to the Filesystem
library.

* "string  string() const &&;" overload?

Will investigate.

* Request for a has_extension() function.

Ugh. Given that class path already has a has_extension() member
function, is something is wrong with the rest of the path interface is
this one is really needed?

Thanks for bringing these to the surface. There won't be any action on
them until after the C++ committee meeting next week.

--Beman