Re: [Boost-users] range_ex

Subject: Re: [Boost-users] range_ex
From: Neil Groves (neil_at_[hidden])
Date: 2009-10-28 15:48:53

>
> 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