The 'Oven' port... http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex... makes much of its 'regular' operator, which is used to fix this problem using boost::lambda::_1; for_each_(r | filtered(_1 % 2 == 0), f); // Error! Can't default construct/copy assign for_each_(r | filtered(regular(_1 % 2 == 0)), f); // OK However, AFAICS this is not a problem in current-ishBoost (1.47). Has this ever been a problem? Can anyone comment on its general provenance? Thx, Rob.
2012/12/10 Robert Jones
The 'Oven' port...
http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex...
makes much of its 'regular' operator, which is used to fix this problem
using boost::lambda::_1; for_each_(r | filtered(_1 % 2 == 0), f); // Error! Can't default construct/copy assign for_each_(r | filtered(regular(_1 % 2 == 0)), f); // OK
However, AFAICS this is not a problem in current-ishBoost (1.47). Has this ever been a problem? Can anyone comment on its general provenance?
Thx, Rob.
You can try this code.
for_each_() is possible std::for_each()'s implementation.
#include <iostream>
#include <vector>
#include
======================== Akira Takahashi
Ah, now I'm understanding your point better. You're postulating a version of for_each which requires copy and assign, just for the purpose of exposition. Got it, thx! Boost.Range sliced does its slicing by calculating iterator offsets from the begin and end of its source range, which is why it needs random access iterators. Its iterator type is also hardwired to be the iterator type of its source range. Frankly I do wonder at wisdom of some its design decisions. How is this done by OvenToBoost's dropped and taken adaptors? Can you point me to the source code? Thx, Rob.
2012/12/10 Robert Jones
Ah, now I'm understanding your point better. You're postulating a version of for_each which requires copy and assign, just for the purpose of exposition.
Got it, thx!
Boost.Range sliced does its slicing by calculating iterator offsets from the begin and end of its source range, which is why it needs random access iterators. Its iterator type is also hardwired to be the iterator type of its source range.
Frankly I do wonder at wisdom of some its design decisions.
How is this done by OvenToBoost's dropped and taken adaptors? Can you point me to the source code?
Thx, Rob.
OvenToBoost's repository is here: https://github.com/faithandbrave/OvenToBoost https://github.com/faithandbrave/OvenToBoost/blob/master/boost/range/adaptor... https://github.com/faithandbrave/OvenToBoost/blob/master/boost/range/adaptor... `taken` and `dropped` don't use random access, and use forward access. Thanks, Akira
On Mon, Dec 10, 2012 at 1:57 PM, Robert Jones
Ah, now I'm understanding your point better. You're postulating a version of for_each which requires copy and assign, just for the purpose of exposition.
Got it, thx!
Boost.Range sliced does its slicing by calculating iterator offsets from the begin and end of its source range, which is why it needs random access iterators. Its iterator type is also hardwired to be the iterator type of its source range.
Frankly I do wonder at wisdom of some its design decisions.
Me too! It was certainly a version which worked and at the time I hadn't thought of a solution to this issue that loosened the requirements. I remember thinking that this would be good for now and that if a better solution is found it can be incorporated without breaking backward compatibility. This is where we are now. Clearly not everything is the most complete solution possible. I'd not have released anything otherwise. I'm very keen to incorporate Akira's work. The plan is to merge this directly. I attempted to accelerate the process by eliminating the need for an official mini-review as had been suggested. I anticipate having more time to work on the Trac tickets and then this integration early in the new year. How is this done by OvenToBoost's dropped and taken adaptors? Can you
point me to the source code?
Thx, Rob.
Rob it appears from your comment that you have have a number of design criticisms. Would you please make these in a more concrete fashion either on-list or however you feel most comfortable? I'd rather not lose the feedback, but the feedback (to paraphrase - I think the designs dodgy) has very limited utility. If there are considerations let's make them specific and consider superior alternatives. Regards, Neil Groves
Hi Neil 'Critisms' is putting very strongly, hopefully it's more in the line of user feedback experience. Overall of course the reality that I'm pushing it to breaking point is testament to it usefulness and overall cohesion. So, in this instance it did not seem wise to me that the sliced adaptor makes use of iterator arithmetic, and hence requires random access iterators, or makes use of the source range's end() as it does. Characteristics of a superior solution would be to be as close as possible to perpetuating the range classification of its source range, and to avoid use of the source range's end() until the consumer gets there, hence fully supporting laziness. I think this is largely achieved by the OvenToBoost implementation, which creates a new iterator type using iterator facade or adaptor in the style of transform iterator, and builds a range type on top of that. The implementation then counts increments, which is the lightest possible touch I think. It looks like this approach would support slicing of unterminated ranges, such as read from stdin (I think). Great to see you back on the case btw! - Rob. Rob it appears from your comment that you have have a number of design
criticisms. Would you please make these in a more concrete fashion either on-list or however you feel most comfortable? I'd rather not lose the feedback, but the feedback (to paraphrase - I think the designs dodgy) has very limited utility. If there are considerations let's make them specific and consider superior alternatives.
participants (3)
-
Akira Takahashi -
Neil Groves -
Robert Jones