[filesystem] : basic_path : Feature request

Whilst using filesystem::path (v1.37) , I found I wanted the following functionality: Typedefs added for reference and const_reference and a push_back function, as follows typedef string_type& reference; typedef const string_type& const_reference; inline void push_back(const_reference path) { *this /= path; } This would allow use of std::back_inserter with stl algorithms such as Boost::filesystem::path src("dir1/./dir2"); Boost::filesystem::path target; Std::remove_copy(src.begin(), src.end(), std::back_inserter(target), "."); I would also like to see pop_back() but this may not be as simple to implement, I'll have to check the code Rob PS - My first post so I hope I'm on the right list, right message format, etc.

On Fri, Feb 6, 2009 at 9:56 AM, Rob <robrimmer@atrico.net> wrote:
Whilst using filesystem::path (v1.37) , I found I wanted the following functionality:
Typedefs added for reference and const_reference and a push_back function, as follows
typedef string_type& reference;
typedef const string_type& const_reference;
inline void push_back(const_reference path) { *this /= path; }
This would allow use of std::back_inserter with stl algorithms such as
Boost::filesystem::path src("dir1/./dir2");
Boost::filesystem::path target;
Std::remove_copy(src.begin(), src.end(), std::back_inserter(target), ".");
These seem like reasonable requests, although I'd have to check the std::back_inserter to be 100% sure. I'll probably target them for Boost.Filesystem Version 3. 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 would also like to see pop_back() but this may not be as simple to implement, I'll have to check the code.
A use case would make this more compelling.
PS - My first post so I hope I'm on the right list, right message format, etc.
Looks good! Thanks, --Beman

Beman Dawes wrote:
On Fri, Feb 6, 2009 at 9:56 AM, Rob <robrimmer@atrico.net> wrote:
I would also like to see pop_back() but this may not be as simple to implement, I'll have to check the code.
A use case would make this more compelling.
It would be pretty trivial to implement, anyway. It's just "*this = parent_path();" Sebastian

Sebastian Redl wrote:
Beman Dawes wrote:
On Fri, Feb 6, 2009 at 9:56 AM, Rob <robrimmer@atrico.net> wrote:
I would also like to see pop_back() but this may not be as simple to implement, I'll have to check the code.
A use case would make this more compelling.
It would be pretty trivial to implement, anyway. It's just "*this = parent_path();"
What about making it more efficient and nothrow? ;-)
Sebastian
My 2 cents, Ion

Sebastian Redl wrote:
It would be pretty trivial to implement, anyway. It's just "*this = parent_path();"
What about making it more efficient and nothrow? ;-) OK, then move the main logic of parent_path() there and implement
Ion Gaztañaga wrote: parent_path() as path t(*this); t.pop_back(); return t; Sebastian
participants (4)
-
Beman Dawes
-
Ion Gaztañaga
-
Rob
-
Sebastian Redl