Re: [Boost-users] [filesystem] Bugs in path::append ?

From: Sachin Garg (schngrg_at_[hidden])
Date: 2008-08-21 11:37:46

On Thu, Aug 21, 2008 at 6:00 PM, Scott McMurray <me22.ca+boost_at_[hidden]> wrote:
> On Thu, Aug 21, 2008 at 02:06, Sachin Garg <schngrg_at_[hidden]> wrote:
>>
>> While i++ works, i+7 doesn't works as basic_path::iterator does not
>> implements advance(). Is there some specific reason for not having it?
>
> I suspect it's simply that it wasn't included in the TR proposal,
> wanting to leave open different options for implementations.
>
> I have a feature request for an "uncomplete" function in; Would you be
> happy with something like this instead?
>
>    complete( uncomplete(i, input_base_path), output_path);
>
> Where input_base_path would be the first 7 components of your
> input_path.

Yes, the 'uncomplete' you suggest would be a much cleaner way. IMHO
advance() would be needed just to complete the iterator
implementation.

> (I'm guessing that the 7 comes from some other path,
> rather than being hard-coded somehow.)

Yes, 7 was just suggested as an example here. It comes from counting
the number of elements in input_base_path.

> Hoping to find a new use case,

The use case here is creating complete output paths for "copy-pasting
a sub-tree from input_base_path to output_base_path" (ofcourse with
some transformations along the way).

For now, I am using

  fs::wpath output_path=output_base_path;
  int k=0; for(fs::wpath::iterator
i=input_path.begin();i!=input_path.end();i++,k++) if(k>=7)
output_path/=(*i);

Again, 7 is the number of elements in input_base_path. advance() would
make it atleast slightly cleaner (remove k, and the if on k),
uncomplete would be ideal.

Sachin Garg