Hi Marcin, in the code shown by the OP the object is accessed over the interface. Not declaring the member functions as virtual would not work. Either it would call the member functions of the interface (if it is non-abstract and those are defined) or it would fail to compile with an abstract interface. There is some other change needed between test and production. One possible solution I have mentioned, was to change the type of the interface from a separate class to the actual class instead in production (e.g. with using to create an alias name). Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 27.11.2023 14:19 Betreff:Re: [std-proposals] Optimize away VTBL when using single inheritance An:std-proposals_at_[hidden]; CC:Marcin Jaczewski <marcinjaczewski86_at_[hidden]>; niedz., 26 lis 2023 o 14:55 Bjorn Reese via Std-Proposals <std-proposals_at_[hidden]> napisał(a): > > On 11/26/23 00:40, Thiago Macieira via Std-Proposals wrote: > > > You've only vaguely described a possible solution. We're asking you to explain > > the problem that you think this solution solves. > > The OP is doing dependency injection as taught in software testing > courses. > > Suppose you have to test class A in isolation, but it uses class B, > which in turn may use other classes. If you replace class B with an > interface of B, then you can supply a test mock-up of B instead of the > real B in your tests. > > The problem is that the interface only exists to support testing, but > you are still paying for the virtual tables in production code. > Devirtualization may remove this cost but there is no guarantee. > I suppose that the OP is asking for such a guarantee, similar to > the guarantees given for copy elision. > As test binaries do not need to link to execute binary then why not make `#define TEST_VIRTUAL vitrual` and make an empty macro for production? This will make class non-trivial (beter avoid SFINAE on it) and require passing objects as pointers or references to avoid slicing. But other parts of the code could stay the same. > The above-mentioned dependency injection is essentially the Strategy > design pattern. There are alternatives that avoids virtual tables to > begin with, such as the Mediator design pattern, or Alexandrescu's > policy-based design. > > -- > Std-Proposals mailing list > Std-Proposals_at_[hidden] > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals