algorithm-wrappers for boost::range?

Hi, Would it be a good idea to make a support header in boost::range which does that? It would seem so, but then someone else would have done it already, or? ;) /Marcus

Marcus Lindblom wrote:
Hi,
Would it be a good idea to make a support header in boost::range which does that?
It would seem so, but then someone else would have done it already, or? ;)
Eric Niebler wrote range_ex, and I then continued this work, the idea being that algorithm wrappers should be one of the components. I have not had time to finish it yet, and I'm trying to decrease my stress level for the moment. The task is no so easy as it sounds, but let me know if you would like to finish it. -Thorsten

Thorsten Ottosen wrote:
Marcus Lindblom wrote:
Hi,
Would it be a good idea to make a support header in boost::range which does that?
It would seem so, but then someone else would have done it already, or? ;)
Eric Niebler wrote range_ex, and I then continued this work, the idea being that algorithm wrappers should be one of the components.
I have not had time to finish it yet, and I'm trying to decrease my stress level for the moment. The task is no so easy as it sounds, but let me know if you would like to finish it.
It depends on how difficult it is. I assumed it was pretty easy, if range is doing it's job. What are the problems? /Marcus

Marcus Lindblom wrote:
Thorsten Ottosen wrote:
Marcus Lindblom wrote:
Hi,
Would it be a good idea to make a support header in boost::range which does that?
It would seem so, but then someone else would have done it already, or? ;)
Eric Niebler wrote range_ex, and I then continued this work, the idea being that algorithm wrappers should be one of the components.
I have not had time to finish it yet, and I'm trying to decrease my stress level for the moment. The task is no so easy as it sounds, but let me know if you would like to finish it.
It depends on how difficult it is. I assumed it was pretty easy, if range is doing it's job. What are the problems?
It mostly has to do 1. with the design of range algorithms and their return value 2. with how the range adapters are implemented, for example, I was wrting my own filter_range class instead of using two filter_iterators to save space. (The range adapters add super-slick syntax like BOOST_FOREACH( int i, container | boost::reversed | boost::filtered( a_pred ) ) foo( i ); ) 3. I wanted to have some neat syntax for zip_ranges That said, the task is not tremendously hard :-) I will rate it easy-to-medium. If you have some time to through at it, it could be a good way to get your first boost submission. So let me know if you're up for the task, and then we can further discuss what needs to be done. cheers Thorsten

Thorsten Ottosen wrote:
Marcus Lindblom wrote:
Thorsten Ottosen wrote:
Marcus Lindblom wrote:
Hi,
Would it be a good idea to make a support header in boost::range which does that?
It would seem so, but then someone else would have done it already, or? ;)
Eric Niebler wrote range_ex, and I then continued this work, the idea being that algorithm wrappers should be one of the components.
I have not had time to finish it yet, and I'm trying to decrease my stress level for the moment. The task is no so easy as it sounds, but let me know if you would like to finish it.
It depends on how difficult it is. I assumed it was pretty easy, if range is doing it's job. What are the problems?
It mostly has to do
1. with the design of range algorithms and their return value
2. with how the range adapters are implemented, for example, I was wrting my own filter_range class instead of using two filter_iterators to save space. (The range adapters add super-slick syntax like
BOOST_FOREACH( int i, container | boost::reversed | boost::filtered( a_pred ) ) foo( i ); )
3. I wanted to have some neat syntax for zip_ranges
That said, the task is not tremendously hard :-) I will rate it easy-to-medium. If you have some time to through at it, it could be a good way to get your first boost submission.
So let me know if you're up for the task, and then we can further discuss what needs to be done.
Sure. I need to poke around it and get some input from you to get the current status, but why not. /Marcus
participants (2)
-
Marcus Lindblom
-
Thorsten Ottosen