[Filesystem] Relational operators

I have used the filesystem library for some time now and I am really happy with it. In the CVS I noticed that it recently added relational operators and an "equivalent" function. To my surprice the relational operators are implemented in a non-portable way. It only does a lexicographical compare! In the rationale it says: "Programmers wishing to determine if two paths are "the same" must decide if that means "the same representation" or "resolve to the same actual file or directory", and choose the appropriate function accordingly." In windows the path "file.cpp" is the same as "FILE.CPP" but not in posix. So if I write portable code I need to do add a function like bool eq_path(const path& path1, const path& path2) { #if BOOST_POSIX return path1.string() == path2.string(); #else return boost::algorithm::iequals(path1.string(), path2.string()); #endif } In most of my cases the equivalent function is not an alternative since it requires that both paths can be evaluted by the filesystem, i.e. paths must exist and the parent of relative paths must be known. --------------------------------------- Another minor question: Why does the "leaf()" member function return a string and not a path?

At 06:01 AM 3/21/2004, Martin wrote:
I have used the filesystem library for some time now and I am really happy with it.
Glad to hear that!
In the CVS I noticed that it recently added relational operators and an "equivalent" function.
To my surprice the relational operators are implemented in a non-portable
way.
It only does a lexicographical compare! In the rationale it says:
"Programmers wishing to determine if two paths are "the same" must decide if that means "the same representation" or "resolve to the same actual file or directory", and choose the appropriate function accordingly."
In windows the path "file.cpp" is the same as "FILE.CPP" but not in
Umm... The implementation should be portable. posix. No, that isn't correct. Those paths are always different on all operating systems, because only the textual representation is considered. Likewise "foo/bar" and "foo/baz/../bar" are different paths, even though they may resolve to the same file. Whether "file.cpp" is equivalent to "FILE.CPP" on Windows depends on whether or not the FILE_FLAG_POSIX_SEMANTICS flag was set when the files were created, the specific file system, etc.
So if I write portable code I need to do add a function like
bool eq_path(const path& path1, const path& path2) { #if BOOST_POSIX return path1.string() == path2.string(); #else return boost::algorithm::iequals(path1.string(), path2.string()); #endif }
In most of my cases the equivalent function is not an alternative since it requires that both paths can be evaluted by the filesystem, i.e. paths must exist and the parent of relative paths must be known.
Due to the possibility of links, rules that change according to what kind of actual file system is mounted, etc, it isn't possible on modern operating systems to tell if two paths which are textually different resolve to the same file without actually accessing the file system. Your code above is fragile; it may work most of the time but then fail unexpectedly.
---------------------------------------
Another minor question: Why does the "leaf()" member function return a string and not a path?
Because only one element is ever returned. Path elements are represented as strings. --Beman
participants (2)
-
Beman Dawes
-
Martin