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