filesystem::path::has_filename() is wrong

[cleanrock@…]

in filesystem/v3/path.hpp :

bool has_filename() const { return !m_pathname.empty(); }

should be (according to docs):

bool has_filename() const { return !filename().empty(); }

[Craig Dickson <cdickson@…>]

Theoretically, yes, it makes sense that has_filename() would return true if filename() returns a non-empty string. However, in practice, I think the way it's written will produce the same result. According to the path decomposition table in the filesystem docs, the only time filename() returns an empty string is when m_pathname is empty. That being the case, has_filename() should return true if m_pathname is not empty, and testing m_pathname.empty() is faster than testing filename().empty() in most cases.

On the other hand, I have a fundamental disagreement with the way path decomposes a path that ends with a slash, which is relevant here because a path ending with a slash should have no filename (path currently infers an invisible "." at the end). I'll file that concern as a separate bug, though, because it's tangential to this one.

[Beman Dawes]

Craig Dickson's comment is correct. !m_pathname.empty() is equivalent to !filename().empty().

It is editorially better to document a result in terms of a public function than by referring to a private member, while an implementation is free to use the private member. It might be a bit cleaner if the implementation exactly follows the formulation in the spec, but that relies on the compiler to actually inline the function call or is less efficient.

Thanks for your interest in boost.filesystem,

--Beman