Há uma diferença considerável quando você tem modelos e começa a tomar as classes base como parâmetro (s) do modelo:
struct None {};
template<typename... Interfaces>
struct B : public Interfaces
{
void hello() { ... }
};
struct A {
virtual void hello() = 0;
};
template<typename... Interfaces>
void t_hello(const B<Interfaces...>& b) // different code generated for each set of interfaces (a vtable-based clever compiler might reduce this to 2); both t_hello and b.hello() might be inlined properly
{
b.hello(); // indirect, non-virtual call
}
void hello(const A& a)
{
a.hello(); // Indirect virtual call, inlining is impossible in general
}
int main()
{
B<None> b; // Ok, no vtable generated, empty base class optimization works, sizeof(b) == 1 usually
B<None>* pb = &b;
B<None>& rb = b;
b.hello(); // direct call
pb->hello(); // pb-relative non-virtual call (1 redirection)
rb->hello(); // non-virtual call (1 redirection unless optimized out)
t_hello(b); // works as expected, one redirection
// hello(b); // compile-time error
B<A> ba; // Ok, vtable generated, sizeof(b) >= sizeof(void*)
B<None>* pba = &ba;
B<None>& rba = ba;
ba.hello(); // still can be a direct call, exact type of ba is deducible
pba->hello(); // pba-relative virtual call (usually 3 redirections)
rba->hello(); // rba-relative virtual call (usually 3 redirections unless optimized out to 2)
//t_hello(b); // compile-time error (unless you add support for const A& in t_hello as well)
hello(ba);
}
A parte divertida disso é que agora você pode definir funções de interface e não interface posteriormente para definir classes. Isso é útil para interfaces de trabalho entre bibliotecas (não confie nisso como um processo de design padrão de uma única biblioteca). Não custa nada permitir isso para todas as suas aulas - você pode atétypedef
usar B se quiser.
Observe que, se você fizer isso, também poderá declarar copiar / mover construtores como modelos: permitir construir a partir de interfaces diferentes permite 'transmitir' entre diferentes B<>
tipos .
É questionável se você deve adicionar suporte para o const A&
in t_hello()
. O motivo usual para essa reescrita é deixar a especialização baseada em herança para a baseada em modelo, principalmente por razões de desempenho. Se você continuar suportando a interface antiga, dificilmente poderá detectar (ou impedir) o uso antigo.