Style Case Studies: Index Tables - Reuse and Preincrement
(Page 5 of 6 )
Guideline: Know about and (re)use the standard library’s facilities wherever appropriate instead of hand-rolling your own.
11. Reuse Part 2: Kill two birds with one stone by making the implementation itself more reusable. Of the original implementation, nothing is directly reusable other than the function itself. The helper sort_idxtbl_pair class is hardwired for its purpose and is not independently reusable.
12. Reuse Part 3: Improve the signature. The original signature
template <class RAIter>
void sort_idxtbl( RAIter first, RAIter last, int* pidxtbl )
takes a bald int* pointer to the output area, which I generally try to avoid in favor of managed storage (say, a vector). But at the end of the day the user ought to be able to call sort_idxtbl and put the output into a plain array or a vector or anything else. Well, the requirement “be able to put the output into any container” simply cries out for an iterator, doesn’t it? (See also Items 5 and 6.)
template< class RAIn, class Out >
void sort_idxtbl( RAIn first, RAIn last, Out result )
Guideline: Widen the reusability of your generic components by not hardcoding types that don’t need to be hardcoded.
13. Reuse Part 4, or Prefer comparing iterators using !=: When comparing iterators, always use != (which works for all kinds of iterators) instead of < (which works only for random-access iterators), unless of course you really need to use < and only intend to support random-access iterators. The original program uses < to compare the iterators it’s given to work on, which is fine for random-access iterators, which was the program’s initial intent: to create indexes into vectors and arrays, both of which support random-access iteration. But there’s no reason we might not want to do exactly the same thing for other kinds of containers, like lists and sets, that don’t support random-access iteration, and the only reason the original code won’t work for such containers is that it uses < instead of != to compare iterators.
As Scott Meyers puts it eloquently in Item 32 of [Meyers96], “Program in the future tense.” He elaborates:
Good software adapts well to change. It accommodates new features, it ports to new platforms, it adjusts to new demands, it handles new inputs. Software this flexible, this robust, and this reliable does not come about by accident. It is designed and implemented by programmers who conform to the constraints of today while keeping in mind the probable needs of tomorrow. This kind of software—software that accepts change gracefully—is written by people who program in the future tense.
Guideline: Prefer to compare iterators using !=, not <.
14. Prefer preincrement unless you really need the old value. Here, for the iterators, writing preincrement (++i) should habitually be preferred over writing postincrement (i++); see [Sutter00, Item 39]. True, that might not make a material difference in the original code because vector<T>::iterator might be a cheap-to-copy T* (although it might not be, particularly on checked STL implementations), but if we implement point 13 we may no longer be limited to just vector<T>::iterators, and most other iterators are of class type—perhaps often still not too expensive to copy, but why introduce this possible inefficiency needlessly?
Guideline: Prefer to write preincrement rather than postincrement, unless you really need to use the previous value.
That covers most of the important issues. There are other things we could critique but that I didn’t consider important enough to call attention to here; for example, production code should have comments that document each class’s and function’s purpose and semantics, but that doesn’t apply to code accompanying magazine articles where the explanation is typically written in better English and in greater detail than code comments have any right to expect.
I’m deliberately not critiquing the mainline for style (as opposed to the mechanical errors already noted that would cause the mainline to fail to compile), because, after all, this particular mainline is only meant to be a demonstration harness to help readers of the magazine article see how the index table apparatus is meant to work, and it’s the index table apparatus that’s the intended focus.
 This chapter is from Exceptional C++ Style, by Herb Sutter (ISBN 0201760428, copyright 2005. All rights reserved. It is reprinted with permission from Addison-Wesley Professional). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Summary >>
More Code Examples Articles
More By Addison-Wesley/Prentice Hall PTR
