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?

questionAnswers(6)

yourAnswerToTheQuestion