Re: [boost] [RangeEx] Where is the current version?

Subject: Re: [boost] [RangeEx] Where is the current version?
From: Neil Groves (neil_at_[hidden])
Date: 2010-02-28 16:47:44

On Sun, Feb 28, 2010 at 8:18 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> wrote:

> Mathias Gaunard wrote:
>
>  As asked during review, you made boost::adaptors::filtered and friends
>> function objects.
>>
>
> My bad, I was in a hurry and didn't take a proper look.
> I meant that you made filtered(range, predicate) work, on top of range |
> filtered(predicate), as was asked by some people during review if I remember
> well.
>
> But it appears you didn't.
> This version doesn't seem to be any different than the review one.
>
>
The version uploaded in the vault does lack some changes requested during
the review. This specific change is currently in my own version and will be
part of the updated code that I shall commit to the trunk in the near
future. Once I have committed to the trunk I will solicit feedback from
everyone but in particular will seek to ensure that I have met everyones
expectations for the post-review changes.

>
>
>  However, they take their arguments by copy (which can be a serious problem
>> with ranges), and don't provide a result_type or result<> template.
>>
>
>
I'm failing to understand your concern about the parameters that are copied.
The usual idiom of passing ranges by reference is used, and the parameters
can be changed using boost::cref or boost::ref unless I have made an
implementation error. I would consider this a defect and I am therefore keen
to understand better your concern. I suspect that I am missing a valuable
test case, hence your further feedback would be gratefully received.

> If the function object is only used for the operator| syntax, of course,
> this is a lesser concern.
>
>
Ah I must confess that my first implementation of the non '|' syntax just
forwarded to the '|' syntax. I am correcting this before release as it is
rather an unnecessary and convoluted solution. The cost of the adapter
holder used in the '|' operator tends to zero on a decent optimized
compilation for the cases I have analysed. I do not want the '|' syntax to
have inferior performance. If you have data about a performance degradation
then again I would be happy to understand your use case.

Thank you for your patience and interest.

Regards,
Neil Groves