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.
