Tue, 30 Oct 2012 15:09:13 GMT

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.

status changed; resolution set

Beman Dawes — Tue, 30 Dec 2014 20:43:46 GMT

status new → closed
resolution → wontfix

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

Boost C++ Libraries: Ticket #7021: filesystem::path::has_filename() is wrong

status changed; resolution set