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