Adam D. Ruppe's "D Cookbook" now available!

[Nick Sabalausky via Digitalmars-d-announce]

On 5/29/2014 8:45 AM, Adam D. Ruppe wrote:
>
> One of the sections there talks about emulating random access on a
> structure that doesn't really support it (a linked list) and focuses on
> the hidden performance. That's the range-writer side of the same
> range-consumer rule: don't try to get fancy and support something the
> underlying data doesn't natively do because then you'll introduce bugs
> and slowdowns that might be hard to find.

FWIW, and in the spirit of "maybe others could benefit too" (not sure 
whether your book touches on this or not):

I *used to be* strongly opposed to what you suggest there, deliberately 
not emulating accesses the data doesn't support. Even had a big long 
debate over it with Andrei. My reasoning was that you should be able to 
swap different data structures in and out to find the best performance, 
because *even if* you're relying on an operation the underlying data 
doesn't support, it could still be such a *small* and infrequent 
reliance that the localized performance hit is overshadowed by improved 
performance in the rest of your code.

Seemed a perfectly sound argument to be, but then I realized: It's 
trivial to write an adapter to emulate features on ranges or containers 
that don't support them. Not only is this more re-usable (ex: only need 
to write a particular method of "emulate random access" once), but far 
more importantly, this makes the feature-emulation EXPLICIT instead of 
hidden.

The upshot of that is, if a range or container doesn't support some 
feature, you can *still* trivially have an emulated drop-in-replacement, 
and it's equally easy (or even easier still) but BETTER because it's 
explicit, not hidden.