On Sun, Feb 28, 2010 at 8:18 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> 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