On Tue, Jan 31, 2012 at 7:59 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> 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