Style Case Studies: Generic Callbacks - Dissecting Generic Callbacks and Improving Style
(Page 2 of 5 )
Dissecting Generic Callbacks
2. The following code presents an interesting and genuinely useful idiom for wrapping callback functions. For a more detailed explanation, see the original article. [Kalev01]
Here again is the code:
template < class T, void (T::*F)() >
class callback
{
public:
callback(T& t) : object(t) {} // assign actual object to T
void execute() { (object.*F)(); } // launch callback function
private:
T& object;
};
Now, really, how many ways are there to go wrong in a simple class with just two one-liner member functions? Well, as it turns out, its extreme simplicity is part of the problem. This class template doesn’t need to be heavyweight, not at all, but it could stand to be a little less lightweight.
Improving Style
Critique this code and identify:
a) Stylistic choices that could be improved to make the design better for more idiomatic C++ usage.
How many did you spot? Here’s what I came up with:
4. The constructor should be explicit. The author probably didn’t mean to provide an implicit conversion from T to callback<T>. Well-behaved classes avoid creating the potential for such problems for their users. So what we really want is more like this:
explicit callback(T& t) : object(t) {} // assign actual object to T
While we’re already looking at this particular line, there’s another stylistic issue that’s not about the design per se but about the description:
Guideline: Prefer making constructors explicit unless you really intend to enable type conversions.
(Nit) The comment is wrong. The word “assign” in the comment is incorrect and so somewhat misleading. More correctly, in the constructor, we’re “binding” a T object to the reference and by extension to the callback object. Also, after many rereadings I’m still not sure what the “to T” part means. So better still would be “bind actual object.”
explicit callback(T& t) : object(t) {} // bind actual object
But then, all that comment is saying is what the code already says, which is faintly ridiculous and a stellar example of a useless comment, so best of all would be:
explicit callback(T& t) : object(t) {}
5. The execute function should be const. The execute function isn’t doing anything to the callback<T> object’s state, after all! This is a “back to basics” issue: Const correctness might be an oldie, but it’s a goodie. The value of const correctness has been known in C and C++ since at least the early 1980s, and that value didn’t just evaporate when we clicked over to the new millennium and started writing lots of templates.
void execute() const { (object.*F)(); } // launch callback function
Guideline: Be const correct.
 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: More Style Improvements >>
More Code Examples Articles
More By Addison-Wesley/Prentice Hall PTR
