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

Subject: Re: [boost] [filesystem] windows/posix inconsistencies.
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-02-02 13:01:00

On Thu, Feb 2, 2012 at 3:14 PM, Beman Dawes <bdawes_at_[hidden]> 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