Bidirectional range dilemma

[H. S. Teoh]

On Sun, Jan 13, 2013 at 01:05:25PM +0100, Peter Alexander wrote:
> I'm repeatedly hitting a range API problem in my combinatorics
> library. Many of the ranges require (potentially sizeable) internal
> buffers to maintain their current state (permutations, set
> partitions, power sets etc.) Also, many of these ranges are
> bidirectional. What this means is they have to store *two* buffers,
> one for the front, and one for the back.
[...]
> The only (ugly) solution I can come up with is to create three
> different ranges, e.g.
> 
> ForwardPermutations
> ReversePermutations
> BidirectionalPermutations
> 
> (or equivalently, one range with an iteration policy).
[...]

On Sun, Jan 13, 2013 at 05:23:24PM +0100, Phil Lavoie wrote:
[...]
> That. I am not sure why you find it so ugly however :(. When the
> most capable/general range yields a noticeable cost on
> performance/space consumption (which seems to be the case here), I
> think it better to empower the user with choices rather than try to
> make decisions for him/her.

+1.


> Documentating how bidirectionalPerms modifies perf/space might just
> be what you need to make peace with yourself. In the event a user
> REALLY needs the bidirectional functionality, he/she will most
> likely read that documentation and  comprehend why it wasn't the
> default in the first place and I am sure they will be thankful to
> know why.

Another point I'd like to ask is, are these ranges transient, or do they
allocate per iteration? If they are transient (i.e., .front is
invalidated upon calling popFront()), they need to be clearly marked as
such.  Also, I think the default setting should be non-transient, and
only when the user asks for higher performance, a transient range should
be given.


T

-- 
Guns don't kill people. Bullets do.