Bidirectional range dilemma

Phil Lavoie maidenphil at hotmail.com
Sun Jan 13 08:23:24 PST 2013


> This is a problem because 90% of the time you'll only iterate 
> forward, and of the remaining 10%, 9% is just iterating 
> backwards, and maybe 1% of the time you want to iterate from 
> both the front and back in the same iteration. This means that 
> 99% of the time, having two buffers is just wasted memory. Of 
> course, I'm plucking these numbers from the air, but you get 
> the idea.

You might just suggest these numbers like that, but in my 
experience they seem accurate.

> To make matters worse, thanks to the lack of logical const 
> there's no way the buffers can be lazily allocated on first use.
>
> The only (ugly) solution I can come up with is to create three 
> different ranges, e.g.
>
> ForwardPermutations
> ReversePermutations
> BidirectionalPermutations

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.

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.


More information about the Digitalmars-d mailing list