Next in Review Queue: The New std.path

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Mon Jul 18 06:16:35 PDT 2011


On Sun, 17 Jul 2011 12:30:39 +0200, torhu wrote:

> On 15.07.2011 02:20, dsimcha wrote:
>> Lars Kyllingstad's new and improved std.path module for Phobos is the
>> next item up in the review queue.  I've volunteered to be the review
>> manager.  Barring any objections, the review starts now and ends at the
>> ends two weeks from now on July 28.  This will be followed by a week of
>> voting, ending August 4th.
>>
>> Code:
>> https://github.com/kyllingstad/phobos/blob/std-path/std/path.d
>>
>> Docs:
>> http://www.kyllingen.net/code/new-std-path/phobos-prerelease/
std_path.html
>>
>>
> Looks nice and clean, both docs and code!  I like modules that are not
> overengineered :)

Thanks!

 
> I noticed a couple of things that I don't think have been mentioned
> already:
> 
> The docs for defaultExtension say that there's one case where doesn't
> allocate.  But the code says that it always does (.idup isn't
> conditional, it's just .dup with a different return type).

There is no reason for idup to duplicate an array which is already 
immutable.  If it does, I'd say it is a compiler bug.
 

> joinPath also uses .idup, thus always allocates.  Maybe there could be a
> documented allocation policy for the module as a whole?  Copy-on-write
> used to be the general rule for Phobos, don't know if that's true
> anymore.  For most of the functions in this module, even a single heap
> allocation could be more expensive than the rest of what they do.

True.  I've tried keeping allocations to a minimum.  If you see other 
places where an allocation could be avoided (besides the idups), please 
let me know.

I'm not sure what you mean by copy-on-write in this case.  The functions 
in this module never modify the input arrays.


> I've read the discussions about the function names, but I still dare to
> make a suggestion of my own.  I feel like joinPath is a bit iffy,
> shouldn't it be plural somehow?  What it does is to create a path by
> putting pieces together, some paths in their own right, some not.  My
> suggestion is to simply call it buildPath.

Good point.  joinPaths would be another option.

-Lars


More information about the Digitalmars-d mailing list