On Thu, Feb 2, 2012 at 3:14 PM, Beman Dawes <bdawes@acm.org> wrote:
* 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.
Does it provide a performance advantage for cross-platform code or does it require platform-specific code to take advantage of it?
* 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?
Disadvantage is that template type has to be specified explicitly then.
* Const return types inhibit move semantics.
Why's that?
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?
Isn't the request for has given extension? So has_extension(const T&)? Advantage is probably better performance and simpler code. -- Olaf