Hi list, what's the status of range_ex? I read that it was accepted into boost half a year ago. So, will it make it into 1.41? This week I downloaded it from the boost vault, as the version from the svn sandbox seemed to be outdated. I like it very much so far. Just two remarks/questions: - in my measurements using the piped adapters (filtered / transformed) was on average 4% slower than hand coded loops. Do I have to live with that, or are there any tricks / hints? - I can't use lambdas for the adapters. - transformed expects a result_type that also lambda::res<> doesn't seem to provide. - filtered tries to copy the functor, which in turn lambda doesn't seem to like. Rgds Richard
Richard Ulrich wrote:
- I can't use lambdas for the adapters. - transformed expects a result_type that also lambda::res<> doesn't seem to provide. - filtered tries to copy the functor, which in turn lambda doesn't seem to like.
Try phoenix lambda, they support result_of protocol. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
what's the status of range_ex? I read that it was accepted into boost half a year ago. So, will it make it into 1.41?
I have been extremely busy with other tasks and unable to dedicate as much time as I would have liked to Boost.RangeEx. As you are probably aware Andrei Alexandrescu has done a great deal of work on new Range Concepts. I have been working on performance evaluation of the new Range Concepts and in addition I have been examining extensions that allow better SSE optimisations and integration with hierarchical enumeration. This has required reimplementing the STL algorithms and so on. Additionally I have needed to provide mechanisms for adapting an iterator_range to the new Range concepts and vice-versa. This has taken a considerable amount of time. I have not prepared the current incarnation of RangeEx for the trunk since I expect to make significant breaking changes to the RangeEx interface (but not the Boost.Range interface).
This week I downloaded it from the boost vault, as the version from the svn sandbox seemed to be outdated.
The Boost.Vault is definitely the place to get the latest Boost.RangeEx
I like it very much so far.
Just two remarks/questions:
- in my measurements using the piped adapters (filtered / transformed) was on average 4% slower than hand coded loops. Do I have to live with that, or are there any tricks / hints?
Would you be able to provide details about the compiler and compiler flags? IIRC this is far worse than the relative performance figures I got on MSVC 9 in Release with the checked iterators turned off. I don't believe you should have to live with any performance degradation for filtered or transformed ranges relative to hand-code filtered/transformed ranges.
- I can't use lambdas for the adapters. - transformed expects a result_type that also lambda::res<> doesn't seem to provide.
I think that phoenix lambda expressions work. To the best of my knowledge there isn't a manner in which I can improve RangeEx to cope with this. Good ideas are invited.
- filtered tries to copy the functor, which in turn lambda doesn't seem to like.
filtered does take the functor by value for the same reasons that the STL algorithms do. boost::ref or boost::cref might help. If they do not then please let me know and I shall attempt to improve the integration with boost::ref. I hope this helps, and I apologise for the delay in getting this ready for release. Best Wishes, Neil Groves
participants (3)
-
joel -
Neil Groves -
Richard Ulrich