On Sat, Feb 7, 2009 at 2:55 AM, Rob <robrimmer@atrico.net> wrote:
These seem like reasonable requests, although I'd have to check the std::back_inserter to be 100% sure.
I have checked this using a wrapper around path as follows
template<class String, class Traits> struct rob_basicpath : boost::filesystem::basic_path<String, Traits> { typedef string_type& reference; typedef const string_type& const_reference;
inline void push_back(const_reference path) { *this /= path; } };
This allowed me to use the following code as expected (which strips . characters from the path)
const boost::filesystem::path path("dir1/./dir2/./dir3"); rob_path rpath; std::remove_copy(path.begin(), path.end(), std::back_inserter(rpath), ".");
Arguably the problem here isn't with basic_path, but with std::back_inserter, which insists on push_back being a member function. You could write your own path_inserter or something.
Note however that path has some but not all of the characteristics of a standard container. I'd want to see persuasive use cases for adding functionality - just making path more like a std container without good reason is likely to lead to interface bloat without offsetting benefits.
I have to second this, all path member functions that take a string apply a transformation to establish the path's invariant, it wouldn't make sense to make it feel more like a container of chars.
2. A variety of tasks I envisage on a path can be neatly and succinctly implemented using std algorithms. <snipped>
The solution is to convert it to string, do what you want with it, then convert it back to a path. Alternatively, you can store paths as strings, and only convert them to filesystem::path when you need to do some kind of path operation on them. Btw, this seems very reasonable approach, given that many paths originate as strings (as user input or read from files, or passed by 3rd party code) and end up as strings (when calling fopen, etc.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode