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