Boost logo

Boost :

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
>you mean
> p.string() < q.string()
> 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

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!


Boost list run by bdawes at, gregod at, cpdaniel at, john at