s métodos virtuais privados não utilizados permitem expansão futura sem quebrar a compatibilidade AB
Estou desenvolvendo uma biblioteca compartilhada. Digamos que tenho a seguinte definição de classe:
class MyClass {
public:
//public interface
private:
virtual void foo1(int);
virtual void foo2(int, bool);
virtual void foo3(double);
virtual void reserved1();
virtual void reserved2();
virtual void reserved3();
class Impl;
Impl* impl_;
};
Oreserved#
s métodos @ virtuais não são substituídos no código do cliente e não são chamados de qualquer lugar. Eles servem como espaços reservados para expansão futura. Digamos que eu substitua um dos métodos reservados por uma função virtual com assinatura e implementação diferentes:
class MyClass {
public:
//public interface
private:
virtual void foo1(int);
virtual void foo2(int, bool);
virtual void foo3(double);
virtual void foo4(int, int);
virtual void reserved2();
virtual void reserved3();
class Impl;
Impl* impl_;
};
Parece que ele consegue compatibilidade binária total dessa maneira, uma vez que o layout da vtable não muda. O problema é que o código antigo ainda solicitaria ao vinculador dinâmico que resolvessereserved1()
e se a definição não estiver na biblioteca, o código falhará no momento do link ou no tempo de execução se alguém chamarfoo4
. Presumo que esse problema não possa ser resolvido de forma portável, por causa do ODR. Talvez haja uma maneira de enganar o compilador para gerar o símbolo dereserved1
que atuaria como um alias parafoo4
?