Path as an object in std.path
Lars T. Kyllingstad
public at kyllingen.net
Thu Jun 6 10:25:56 PDT 2013
On Thursday, 6 June 2013 at 17:13:10 UTC, Steven Schveighoffer
wrote:
> On Thu, 06 Jun 2013 12:14:30 -0400, Dylan Knutson
> <tcdknutson at gmail.com> wrote:
>
>> It doesn't do any allocations that the user won't have to do
>> anyways. Paths have to be normalized before comparison; not
>> doing so isn't correct behavior. Eg, the strings `foo../bar`
>> != `bar`, yet they're equivalent paths. Path encapsulates the
>> behavior. So it's the difference between
>>
>> buildNormalizedPath(s1) == buildNormalizedPath(s2);
>>
>> and
>>
>> p1 == p2;
>
> This can be done without allocations.
I know. There are a few additions that I've been planning to
make for std.path for the longest time, I just haven't found the
time to do so yet. Specifically, I want to add a couple of
functions that deal with ranges of path segments rather than full
path strings.
The first one is a lazy "path normaliser":
assert (equal(pathNormalizer(["foo", "bar", "..", "baz"]),
["foo", "bar", "baz"]));
With this, non-allocating path comparison is easy. The verbose
version of p1 == p2, which could be wrapped for convenience, is
then:
equal(pathNormalizer(pathSplitter(p1)),
pathNormalizer(pathSplitter(p2)))
You can also use filenameCmp() as a predicate to equal() to make
the comparison case-insensitive on OSes where this is expected.
Very general and composable, and easily wrappable.
The second thing I'd like to add is an overload of buildPath()
that takes a range of path segments. (Then
buildNormalizedPath(p) can also be implemented as
buildPath(pathNormalizer(p)).)
Maybe now is a good time to get this done. :)
More information about the Digitalmars-d
mailing list