Re: [boost] [filesystem] adding path equality and path equivalence

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-02-01 17:50:07

At 11:47 AM 2/1/2004, Peter Dimov wrote:

 >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 
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