[Range] Sliced... less than it could be.
I was disappointed to discover that I can't write range | filtered( some_predicate ) | sliced( n, m ) | ..... because sliced requires a random access range, and filtered produces a forward range! Piffle. It seems such a useful and obvious use-case. Is this restriction really necessary? Thx, Rob.
Hi, Robert
2012/12/10 Robert Jones
I was disappointed to discover that I can't write
range | filtered( some_predicate ) | sliced( n, m ) | .....
because sliced requires a random access range, and filtered produces a forward range!
Piffle.
It seems such a useful and obvious use-case. Is this restriction really necessary?
Thx, Rob.
I think this spec is unnecessity restriction. My OvenToBoost's "taken" and "dropped" adaptors requirement is SinglePassRange. http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex... http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex... I can write follow: range | filtered(some_predicate) | dropped(n) | taken(m) This extension is now proposing to Boost.Range. I think "sliced" adaptor should be same requirements.
======================== Akira Takahashi site: https://sites.google.com/site/faithandbrave/about/en
Hi Akira
An impressive body of work, which I've had reason to encounter in the past.
However I'm
a little confused: your proposal seems to date from 2005-2007, well before
Neil's Range 2.0
library, and yet seems in some ways to encompass and extend Neil's work.
Why was your
proposed work never taken up?
Thx, Rob.
On Mon, Dec 10, 2012 at 10:04 AM, Akira Takahashi
Hi, Robert
2012/12/10 Robert Jones
I was disappointed to discover that I can't write
range | filtered( some_predicate ) | sliced( n, m ) | .....
because sliced requires a random access range, and filtered produces a forward range!
Piffle.
It seems such a useful and obvious use-case. Is this restriction really necessary?
Thx, Rob.
I think this spec is unnecessity restriction. My OvenToBoost's "taken" and "dropped" adaptors requirement is SinglePassRange.
http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex...
http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex...
I can write follow: range | filtered(some_predicate) | dropped(n) | taken(m)
This extension is now proposing to Boost.Range. I think "sliced" adaptor should be same requirements.
======================== Akira Takahashi site: https://sites.google.com/site/faithandbrave/about/en
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- ACCU - Professionalism in programming - http://www.accu.org
2012/12/10 Robert Jones
Hi Akira
An impressive body of work, which I've had reason to encounter in the past. However I'm a little confused: your proposal seems to date from 2005-2007, well before Neil's Range 2.0 library, and yet seems in some ways to encompass and extend Neil's work. Why was your proposed work never taken up?
Thx, Rob.
My OvenToBoost project is porting from Oven Range Library to Boost.Range. This project stated from 2011. Original Oven Library written by Sogame Shunsuke (2005-2007). http://p-stade.sourceforge.net/oven/doc/html/index.html Sorry to confuse you.
Ah yes, my bad, thanks for clarifying.
However, the question still stands, although you may not be the man to
answer it, but now
it refers to he Oven library rather than to yours.
It seems the Oven library predates, but also pre-empts the Range 2.0
library, and yet was
never properly made part of Boost. How come?
Thx, Rob.
ps. When are your porting efforts likely to bear fruit?
On Mon, Dec 10, 2012 at 10:43 AM, Akira Takahashi
2012/12/10 Robert Jones
Hi Akira
An impressive body of work, which I've had reason to encounter in the past. However I'm a little confused: your proposal seems to date from 2005-2007, well before Neil's Range 2.0 library, and yet seems in some ways to encompass and extend Neil's work. Why was your proposed work never taken up?
Thx, Rob.
My OvenToBoost project is porting from Oven Range Library to Boost.Range. This project stated from 2011. Original Oven Library written by Sogame Shunsuke (2005-2007). http://p-stade.sourceforge.net/oven/doc/html/index.html
Sorry to confuse you.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- ACCU - Professionalism in programming - http://www.accu.org
2012/12/10 Robert Jones
Ah yes, my bad, thanks for clarifying.
However, the question still stands, although you may not be the man to answer it, but now it refers to he Oven library rather than to yours.
It seems the Oven library predates, but also pre-empts the Range 2.0 library, and yet was never properly made part of Boost. How come?
I don't know why Oven is not part of Boost. I know small history. Oven have base library "Egg". Egg proposed to Boost but rejected. I was taken over from Shunsuke Sogame (original author). because Oven was no mentenance long time.
ps. When are your porting efforts likely to bear fruit?
I don't know. But I feel Boost.Range community have interesting my project. Now process is waiting review from Neil. Regards, Akira
======================== Akira Takahashi site: https://sites.google.com/site/faithandbrave/about/en
I don't know. But I feel Boost.Range community have interesting my project. Now process is waiting review from Neil.
Yes it's waiting on me for sure. In my defence I'd like to point out that I'm very keen to integrate this work, and I made the process quicker by circumventing the need for a formal mini-review. Even with my lack of time this will end up with the code incorporated sooner than if we followed the formal process. The Oven work and the later work to make it easy to integrate are fantastic and will be brought into Boost.Range early in the new year to the trunk.
Regards, Akira
Thanks for the work and your patience Akira. Regards, Neil Groves
participants (3)
-
Akira Takahashi -
Neil Groves -
Robert Jones