Caching in computing ranges
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sat Oct 9 15:40:47 PDT 2010
On 10/9/10 14:38 CDT, Tomek Sowiński wrote:
> I've been having fun with ranges lately. While nesting computing ranges I noticed only the
> outermost range's cache is necessary; there's no way of accessing front() of ranges deeper
> in the expression twice because they are sealed by the outermost range. Example:
>
> map!"a._0 + a._1"( // caches, front() may be called twice
> zip( // oh, trumpet: front() is called only to compute outer map's cache
> map!"a*a"([2, 4, 5, 6]), // oh, trumpet
> take(sequence!"a._0 + n * a._1"(1, 2), 4) // oh, trumpet
> )
> );
>
> Eliminating superfluous caches, among other benefits, allows inlining the (usually cheap)
> front()s. One way to do it is to parametrize computing ranges with an enum Cached.(yes|no).
> What you think?
I think it's a good idea. In fact let's eliminate caching altogether; it
does not happen for the random access operator anyway and I think it's
fair to simply evaluate the function whenever an element is accessed.
Whaddaya think?
Andrei
More information about the Digitalmars-d
mailing list