[range] for_each and std::map of std::list
Hi, Consider a map defined as... std::map< int, std::list< std::string > > my_map; I'm wondering if/how it's possible to use Boost.Range to call a function on each std::string in each of the lists contained in the map. I have an implementation below which works using a C++0x lambda function but am curious if this can be done purely using Boost.Range? boost::for_each( boost::adaptors::values( my_map), []( const std::list< std::string >& my_list ) { boost::for_each( my_list, some_func ); } ); ideas anyone?
On Wed, Apr 6, 2011 at 3:03 PM, Mark Snelling
Hi,
Consider a map defined as...
std::map< int, std::list< std::string > > my_map;
I'm wondering if/how it's possible to use Boost.Range to call a function on each std::string in each of the lists contained in the map. I have an implementation below which works using a C++0x lambda function but am curious if this can be done purely using Boost.Range?
boost::for_each( boost::adaptors::values( my_map), []( const std::list< std::string >& my_list ) { boost::for_each( my_list, some_func ); } );
ideas anyone?
In the absence of C++0x lambdas I think you'd need something like Boost.Lambda, but I guess that's probably not interoperable with the new range stuff for nested std algorithm invocations. - Rob.
Den 06-04-2011 16:03, Mark Snelling skrev:
Hi,
Consider a map defined as...
std::map< int, std::list< std::string > > my_map;
I'm wondering if/how it's possible to use Boost.Range to call a function on each std::string in each of the lists contained in the map. I have an implementation below which works using a C++0x lambda function but am curious if this can be done purely using Boost.Range?
boost::for_each( boost::adaptors::values( my_map), []( const std::list< std::string >& my_list ) { boost::for_each( my_list, some_func ); } );
ideas anyone?
What we need is a generic range adaptor that can make a container of containers look like a "flat" sequence. I suggest the syntax rngOfContainers | boost::adaptors::flattened and the underlying iterator should be up to bidirectional (if the underlying two container types support it). Anyone interested in implementing this? -Thorsten
What we need is a generic range adaptor that can make a container of containers look like a "flat" sequence.
I suggest the syntax
rngOfContainers | boost::adaptors::flattened
and the underlying iterator should be up to bidirectional (if the underlying two container types support it).
Anyone interested in implementing this?
I've been interested in implementing something similar for a while. I was thinking slightly more generally that any n-dimensional structure can often be linearised or projected into a linear sequence. Hence this would enable not just the above example to work, but many standard algorithms could work with tree structures, hyper-cube trees, directed acyclic graphs etc. I've implemented a number of these already, but wanted to gain experience with them in my own projects before committing them to the trunk.
-Thorsten
Regards, Neil Groves
Den 06-04-2011 22:55, Neil Groves skrev:
I've been interested in implementing something similar for a while. I was thinking slightly more generally that any n-dimensional structure can often be linearised or projected into a linear sequence. Hence this would enable not just the above example to work, but many standard algorithms could work with tree structures, hyper-cube trees, directed acyclic graphs etc. I've implemented a number of these already, but wanted to gain experience with them in my own projects before committing them to the trunk.
Cool. I have a little problem seeing how it works with acyclic graphs. For example, there are many ways to do this. Which one do we pick? I think the container of containers case meets 90% or more of all use cases. A container of containers of containers can be done manually by applying it twice. Even trees, surely they provide some kind of iteration already? (Like std::map/std::set). So what is special here? -Thorsten
On 06/04/2011 23:14, Thorsten Ottosen wrote:
Den 06-04-2011 22:55, Neil Groves skrev:
I've been interested in implementing something similar for a while. I was thinking slightly more generally that any n-dimensional structure can often be linearised or projected into a linear sequence. Hence this would enable not just the above example to work, but many standard algorithms could work with tree structures, hyper-cube trees, directed acyclic graphs etc. I've implemented a number of these already, but wanted to gain experience with them in my own projects before committing them to the trunk.
Cool. I have a little problem seeing how it works with acyclic graphs. For example, there are many ways to do this. Which one do we pick?
True, there are many ways to linearize a n-dimensional structure. Consider a matrix, do you start with rows or with columns?
I think the container of containers case meets 90% or more of all use cases. A container of containers of containers can be done manually by applying it twice.
For ranges of ranges (of ranges...), unless they're random access, I don't think anything but linearizing in the "natural" order of iteration makes sense.
On 06/04/2011 19:55, Thorsten Ottosen wrote:
What we need is a generic range adaptor that can make a container of containers look like a "flat" sequence.
I suggest the syntax
rngOfContainers | boost::adaptors::flattened
and the underlying iterator should be up to bidirectional (if the underlying two container types support it).
Anyone interested in implementing this?
I have an implementation of this somewhere. One annoying thing is that you cannot detect that a type is a range reliably.
Den 07-04-2011 11:37, Mathias Gaunard skrev:
On 06/04/2011 19:55, Thorsten Ottosen wrote:
I suggest the syntax
rngOfContainers | boost::adaptors::flattened
and the underlying iterator should be up to bidirectional (if the underlying two container types support it).
Anyone interested in implementing this?
I have an implementation of this somewhere.
One annoying thing is that you cannot detect that a type is a range reliably.
Well, that is only a problem if you want to avoid manually applying the adaptor twice (or more), right? If so, I think that is a limitation we can live with. A simple solution covers most cases IMO. -Thorsten
On 07/04/2011 12:56, Thorsten Ottosen wrote:
Well, that is only a problem if you want to avoid manually applying the adaptor twice (or more), right?
If so, I think that is a limitation we can live with. A simple solution covers most cases IMO.
Oh, the adaptor I wrote flattens recursively. I guess just flattening the top level could be fairly easy.
participants (5)
-
Mark Snelling -
Mathias Gaunard -
Neil Groves -
Robert Jones -
Thorsten Ottosen