[yzmtf2008]

What if I want both? What if in ClassATest, I need ClassBImpl? Do I go around creating more compile cases?

Because that’s what we need, more magic in the build system.

[mehrdadn]

Not sure I see what you're thinking of... could you give me a code example?

[pdpi]

The implementation of TestWidget only defines some stuff of its own but otherwise shares a bunch of code with Widget is a possible scenario here.

[mehrdadn]

You can still derive classes when you need to, right?

[pdpi]

What class are you deriving from though? Can’t be Widget, because in the scenario you described Widget and TestWidget are mutually exclusive (TestWidget just replaces Widget altogether). The alternative is extracting the shared behaviour to a BaseWidget that both classes extend, but that’s just ugly as sin.

[mehrdadn]

idk, would something like this work maybe?

  // widget.h
  class Widget { void throb1(); virtual void throb2(); };
  // widget.cc
  void Widget::throb1() { ... }
  void Widget::throb2() { ... }
  // widget.test.cc
  void Widget::throb1() { ... }
  void Widget::throb2() { ... }
  class TestWidget : public Widget { int x; void throb2(); };
  void TestWidget::throb2() { ... Widget::throb2(); ... }

If not, could you present code to illustrate the problem? I won't try to address more issues without actual code.

[Liquid_Fire]

But now you've made throb2 virtual again, which is the problem this proposal was trying to avoid in the first place.