On Mon, Dec 10, 2012 at 1:57 PM, Robert Jones <robertgbjones@gmail.com>wrote:
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