In Defense of Laziness

Saving Resources

Think of yourself as a resource-starved CPU. If you were writing code for that CPU, you'd make sure that you didn't waste cycles or memory [5]. You've seen many of the basic techniques:

char buffer[BUF_SIZE];
void expensive_function()
{
// code using buffer
}

void cheaper_version()
{
static char *buffer = new char[BUF_SIZE];
// code using buffer
}

The second version of this function is cheaper if it's never called: It doesn't tie up memory for a buffer that's never used. [6]

double really_slow_thing(double);
double cached_version(double arg)
{
static double cached_argument;
static double cached_result;
static bool cache_valid = false;
if (!cache_valid || cached_argument != arg)
  {
  cache_valid = true;
  cached_argument = arg;
  cached_result = really_slow_thing(arg);
  }
return cached_result;
}

If you end up calling really_slow_thing with the same value several times in succession and it doesn't have any side effects, caching the result avoids having to recompute the same value, freeing the CPU for other things, at the cost of additional code and data.

double r0 = really_slow_thing(0.0);
double r1 = really_slow_thing(1.0);
double r2 = really_slow_thing(2.0);
double precomputed_version(double arg)
{
return arg == 0.0 ? r0
  : arg == 1.0 ? r1
  : arg == 2.0 ? r2
  : really_slow_thing(arg);
}

When you know in advance that you're going to call really_slow_thing several times with values from some well-defined set, you can speed things up by precomputing the result for each of those values [7]. However, this increases the application's startup time, which could be a problem [8].

Of course, the danger in being lazy is that you might not get the priorities right, and you might not have as much time as you'd like for something that slipped off of your schedule. If you're a resource-starved CPU, this is a disaster. If you're a programmer (or a writer), and you're lucky, you'll have a forgiving boss (or editor) who will let you slide, just this once.

Notes

1. [1] That's The C++ Standard Library Extensions, coming soon to a bookseller near you.
2. [2] Okay, I admit it: I, too, debated that sort of thing in my earlier years. And that's important. We need to learn how to write good code, so that the simple loops just roll out of the fingers without much intervention from the brain. Don't get stuck there, though. There really are more important things.
3. [3] For beginners, this is hopeless. Beginners should not write templates.
4. [4] Two types do not justify a template, either. Designing for multiple types is far more complex than designing for one or two well-understood types. For example, the Standard library's basic_string template can be instantiated as basic_string<char> and basic_string<wchar_t>. There's an extension mechanism in the char_traits template, which suggests that you can create basic_string instances for other types, but in practice it doesn't work. The change from the original string and wstring classes to the basic_string template was a mistake.
5. [5] Of course, you should do that anyway, to some extent. But in embedded systems, problems of resource scarcity are more severe than for desktop systems, so resource management is a more prominent part of application design.
6. [6] On the other hand, if it is used, the initial allocation takes time and uses more memory. Writing and reading data may be slower, too, because the compiler doesn't know the address of the memory at compile time. Sometimes it doesn't pay to be lazy.
7. [7] This is also the reason that people discuss how to write for loops over vectors: Figuring out the best way beforehand means you don't have to spend time figuring it out while your project's deadline is looming.
8. [8] Of course, you could lazily evaluate the precomputed values, by initializing r0, r1, and r2 to some known bad value, and computing the actual value when it's first needed. That requires an additional test, unless you're into signaling NaNs.