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

On Thu, Aug 21, 2008 at 6:00 PM, Scott McMurray wrote:

On Thu, Aug 21, 2008 at 02:06, Sachin Garg 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