As I discussed this article with my colleague, I thought that perhaps this is a delineation between developers. Some make tools and others use tools. Maybe tool users don't absolutely need to use inheritance directly, although I'd be hard pressed to suggest that they shouldn't use it in a well-thought out way.

For example, consider the popularity of the Arduino. One of the things that makes it easier (according to its fans) is that it has a main function already written that must look something like this:

void main()
  {
  setup();
  while (1) loop();
  }

Not exactly rocket science, but people apparently like it. (In all fairness, you can override main and that's not the only ease-of-use feature it provides.) With inheritance, however, I can go much further. For a particular piece of hardware, I could define a class like this:

class BaseApp
  {
  public:
  void setup(void);  // by default set up timer interrupt
  void loop(void);
  void tick1s(void);  // 1 second tick
  void tick100ms(void); // 100 ms tick
  };

The tool builder provides the code to set up the timer interrupts and wire them to the "tick" functions. Now a non-tool maker can just derive a new class:

class MyApp : public BaseApp
  {
  public:
	void tick1s(void); 
  };

That makes it easy if the toolmaker anticipated your needs. How can this be an arbitrarily bad thing? I could go on (and I will in another blog) about whether you should even use C++ in an embedded system, and if so, what parts you should probably avoid. But note the word "probably". My opinions and solutions might work for you. But your case may very well be special; only you can decide.

As Cicero said, "Nobody can give you wiser advice than yourself."