[filesystem] Bugs in path::append ?
I have following 3 lines of code, is this usage correct? fs::wpath input_path=somepath; fs::wpath output_path=anotherpath; output_path.append(input_path.begin()+7,input_path.end()); The 3rd line gives following error (using Visual Studio 9.0 and boost 1.35.0) C:\Program Files\boost\boost_1_35_0\boost/filesystem/path.hpp(1058) : error C2664: 'boost::filesystem::detail::is_separator' : cannot convert parameter 1 from 'const std::basic_string<_Elem,_Traits,_Ax>' to 'wchar_t' Looking at the code, it does looks like a problem with path.hpp as is_separator expects a wchar_t parameter but append gives it a wstring (unless there some conversion that should have happened but isn't happening. I temporarily changed *first at line 1058 to first->at(0) and this fixed the error.). And there are other errors too like path.hpp(1068) : error C2677: binary '&&' : no global operator found which takes type 'const std::basic_string<_Elem,_Traits,_Ax>' (or there is no acceptable conversion) This too seems valid as path.hpp:1068 'seems' to assume that *first would be same as first->empty() Is this a known issue fixed in 1.36.0? Seems like some presumed conversions are not happening in path.hpp. Or am I making some super dumb mistake in my usage of append()? Sachin Garg
On Thu, Aug 21, 2008 at 2:27 AM, Sachin Garg
I have following 3 lines of code, is this usage correct?
fs::wpath input_path=somepath; fs::wpath output_path=anotherpath; output_path.append(input_path.begin()+7,input_path.end());
My bad, I finally figured out that above usage is not the intended use of append. Can this be registered as a feature request, I think it will be very convenient to have this. Also, I am now trying this to achieve the same effect: for(fs::wpath::iterator i=input_path.begin()+7;i!=input_path.end();i++) output_path/=(*i); 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? Sachin Garg
On Thu, Aug 21, 2008 at 02:06, Sachin Garg
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. (I'm guessing that the 7 comes from some other path, rather than being hard-coded somehow.) Hoping to find a new use case, ~ Scott
On Thu, Aug 21, 2008 at 6:00 PM, Scott McMurray
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
participants (2)
-
Sachin Garg
-
Scott McMurray