From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-02-01 11:12:07
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.
Given two paths, "foo.bar" and "foo/bar", (1) will order them:
While (2) will order them:
The primary use case I know of for operator<() is default ordering for
paths used as keys in associative containers. I can't see that either
approach is superior for this use, so unless someone comes up with a
compelling argument, (1) will be used.
Two paths will be considered equivalent if they resolve to the same
physical directory or file.
Question 1: What is a use case that requires this function? Verifying that
source and target files are different before some modifying operation is
the only one I've come up with. I guess that is sufficient to justify
adding the function.
Question 2: What if neither exist? Only one exists? My initial thought is
that these are likely to be errors, so treat them as such. It could be
argued that if either or both don't exist, they can't be equivalent, so
Question 3: The implementation on Windows (see below) leaves a small hole
in that duplicated media (such as two CD's) mounted on devices with the
same device id on two different networked machines would be reported as
equivalent. POSIX requires that such networked devices have different
device id's, avoiding the problem. Is the fact that Windows and POSIX
implementations would perform slightly differently on this corner case a
showstopper? I think not.
Windows logic for path equivalent: same device id AND same media volume
serial number AND same physical location on disk AND same creation time.
This works even in degenerate cases like camera formatted FAT flash memory
cards or floppy disks with volume serial numbers incorrectly initialized to
POSIX logic: same device id AND same physical location on disk AND same
modification time. The modification time is in theory redundant, but is an
added protection in case the device id on networked devices failed to meet
the POSIX specs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk