Beman Dawes wrote:
Equality --------
The path relational operators will be defined purely in terms of string comparison between the textual representation of the two paths. There are two ways to do this: (1) string comparison using std::string relational operators or (2) string comparison using std::lexicographical_compare.
I'm not not entirely sure that I understand you correctly but I think
At 11:47 AM 2/1/2004, Peter Dimov wrote: that
you mean
p.string() < q.string()
vs
lexicographical_compare( p.begin(), p.end(), q.begin(), q.end() )
(equivalent to p.m_name < q.m_name).
Yes, exactly.
There are two reasons to prefer lexicographical_compare. First, container requirements.
Ha! Interesting point! I hadn't though of that. Peter is point out that a good way to conceptualize class path is as a container-like sequence of elements. Now if it actually were specified as a sequence, it should meet the requirements of 23.1 table 65, and that means lexicographical_compare. Since class path isn't actually specified as a container, that isn't a totally killer argument to me, but it does at least tilt the scale more towards lexicographical_compare.
Second, consider the case where p is { "first/", "second" } and q is { "first", "/second" }.
That's seriously perverse and devious. I'm very impressed! The case would arise if the native format allowed slashes in names, and used, say ':' as a name separator. p.native_file_string() would return "first/:second" and q.native_file_string() would return "first:/second". But both p.string() and q.string() would return "first//second". In other words, there are some native paths that path::string() doesn't yield an unambiguous result, as noted in the docs. path::, and that's a problem if used as a key in a unique associative container. That problem as Peter points out would be cleared by using lexicographical_compare. An alternative solution is to escape the '/' in path string(), something we might want to consider anyhow. I've been avoiding that mostly from laziness. The reason I'd like to avoid lexicographical_compare is that iteration over the elements in a path is serious inefficient, at least in the current Boost implementation. That's OK, because it is really only provided as a safety-value, and is rarely used. But if it becomes the basis for lexicographical_compare, performance might become more of an issue. I'll give it some more thought. One thing to remember is that this is only the default comparison for containers. Whatever we go with is overridable by the user. Anyhow, interesting issues. Thanks! --Beman