Alternative à c++ statique méthodes virtuelles

Vous pouvez faire Base être un modèle de classe qui prend ses pointeurs de fonction à partir de son argument de modèle:

extern "C" {
struct CStruct
{
  void (*funA)(int, char const*);
  int (*funB)(void);
};
}

template <typename T>
class Base
{
public:
  CStruct myStruct;
  void FillPointers() {
    myStruct.funA = &T::myFunA;
    myStruct.funB = &T::myFunB;
  }
  Base() {
    FillPointers();
  }
};

Ensuite, de définir les classes dérivées à descendre à partir d'une instanciation de Base à l'aide de chaque classe dérivée comme l'argument de modèle:

class Derived1: public Base<Derived1>
{
public:
  static void myFunA(int, char const*) { }
  static int myFunB() { return 0; }
};

class Derived2: public Base<Derived2>
{
public:
  static void myFunA(int, char const*) { }
  static int myFunB() { return 1; }
};

int main() {
  Derived1 d1;
  d1.myStruct.funA(0, 0);
  d1.myStruct.funB();
  Derived2 d2;
  d2.myStruct.funA(0, 0);
  d2.myStruct.funB();
}

Cette technique est connue sous le curieusement récurrents pattern template. Si vous négligez de mettre en œuvre l'une des fonctions dans une classe dérivée, ou si vous modifiez la signature de la fonction, vous obtiendrez une erreur de compilation, ce qui est exactement ce que vous vous attendez à obtenir si vous avez négligé de mettre en œuvre l'une des fonctions virtuelles pures à partir de votre plan d'origine.

La conséquence de cette technique, cependant, est que Derived1 et Derived2 n'ont pas une classe de base commune. Les deux instanciations de Base<> ne sont pas liés en aucune façon, autant que le système de type est concerné. Si vous avez besoin d'elles à être liée, alors vous pouvez introduire une autre classe afin de servir de base pour le modèle, puis mettre les choses en commun il y a:

class RealBase
{
public:
  CStruct myStruct;
};

template <typename T>
class Base: public RealBase
{
  //...
};

int main()
  RealBase* b;
  Derived1 d1;
  b = &d1;
  b->myStruct.funA(0, 0);
  b->myStruct.funB();
  Derived2 d2;
  b = &d2;
  b->myStruct.funA(0, 0);
  b->myStruct.funB();
}

Attention: fonctions membres Statiques ne sont pas nécessairement compatibles avec des pointeurs de fonction. Dans mon expérience, si le compilateur accepte la cession déclarations ci-dessus, alors vous pouvez au moins être sûr qu'ils sont compatibles pour que le compilateur. Ce code n'est pas portable, mais si cela fonctionne sur toutes les plates-formes vous avez besoin de soutien, alors vous pourriez envisager il "assez portable."

Je peut encore voir une utilisation statique des méthodes virtuelles, voici un exemple:

class File
{
    static virtual std::string extension()  {return "";}
}

class ExecutableFile : public File
{
    //static because every executable has same extension
    static virtual std::string extension()  {return ".exe";}
}


std::string extension = "";

//needing static
extension = ExecutableFile::extension();

//not needing static nor virtual
ExecutableFile exeFile;
extension = exeFile.extension();

//needing virtual
File* pFile = &exeFile;
extension = pFile->extension();

Vous pouviez juste passer les fonctions directement dans le constructeur de classe de base:

class Base
{
    Base()(int (*myFunA)(...), int (*myFunB)(...)) 
    { myStruct.funA = funA; myStruct.funB = myFunB; ...}
private:
    CStruct myStruct;
};

class Derived1 : public Base
{
    Derived1() : Base (myFunA, myFunB) {}
    static myFunA(...) {...};
    static myFunB(...) {...};
};

class Derived2 : public Base
{
    Derived2() : Base (myFunA, myFunB) {}
    static myFunA(...) {...};
    static myFunB(...) {...};
};

int main()
{
    Derived1 d1;
    Derived2 d2;
    //Now I have two objects with different functionality
}

Ces choses serait certainement utile - à savoir, à force de tous les objets dans une hiérarchie de classe pour exposer une méthode de fabrique, au lieu d'un simple constructeur. Les usines sont très utiles pour vous assurer de ne jamais construire des objets non valides, une conception de garantir que vous ne pouvez pas appliquer presque aussi bien avec des constructeurs.

De construire des "virtuel statique" exige la construction de votre propre "statique v-table" à la main dans tous les objets qui en ont besoin. Virtuelle ordinaire des fonctions de membre du travail parce que le compilateur crée un secret tableau de pointeurs de fonction appelée la VTABLE dans toutes les instances de votre classe. Lorsque vous créez un "T" de l'objet, les pointeurs de fonction dans ce tableau sont affectés à l'une des adresses du 1er ancêtre de fournir l'API. Remplacement d'une fonction devient tout simplement le remplacement de l'original pointeur sur l'objet que vous obtenez à partir de "nouveaux" avec le nouveau prévu dans la classe dérivée. Bien sûr, le compilateur d'exécution et de gérer tout cela pour nous.

Mais, de retour dans le très vieux jours avant moderne du c++ (je me suis dit), vous deviez définir cette magie vous-même. Et c'est encore le cas pour la quasi statique. La bonne nouvelle c'est que cela - la vtable de vous construire à la main, pour eux, est en fait plus simple que le "ordinaires", les entrées ne sont pas plus chers en quelque manière que ce soit, y compris l'espace & performance que ceux pour les fonctions de membres. Il suffit de définir la classe de base avec un ensemble EXPLICITE des pointeurs de fonction (la statique de la vtable) pour l'Api vous souhaitez pris en charge:

template<typename T>
class VirtualStaticVtable {
private:
typedef T (*StaticFactory)(KnownInputParameters params);
StaticFactory factoryAPI;  //The 1 and only entry in my static v-table
protected:
VirtualStaticVtable(StaticFactory factoryApi) : factoryAPI(factoryApi) {}
virtual ~VirtualStaticVtable() {}
};

Maintenant, chaque objet qui devrait prendre en charge une statique usine méthode peut être dérivé de cette classe. Ils tranquillement passer dans leur propre usine à leur constructeur, et il ajoute seulement 1 pointeur vers les objets qui en résultent tailles (comme à l'ordinaire VTable entrée).

Strousup et co. peut encore ajouter à cette idiomatiques motif à la base de la langue s'ils le voulaient. Il ne voulait même pas être si difficile que ça. Chaque objet dans une telle "C+++" serait tout simplement avoir 2 vtables au lieu de 1 - 1 pour les fonctions de membre de la prise de "cela" comme un argument et 1 pour le commun des pointeurs de fonction. Jusqu'à ce jour, cependant, nous sommes coincés avec manuel vtables tout comme l'ancien C-les programmeurs étaient dans les jours avant le c++.

Fonctions virtuelles sont essentiellement des pointeurs de fonction sous le capot. Ils suffit de pointer vers des fonctions différentes pour les différentes classes. Pour simuler virtuel-le comportement de la fonction, avoir un pointeur de fonction stockée quelque part, puis de "remplacement" il vient de le réaffecter à certaines fonctions différentes.

Alternativement, vous pouvez tester cela, mais je pense que les interfaces ont assez bonne compatibilité binaire. Vous pourriez sortir avec exposant une interface C++ entièrement composée de fonctions virtuelles pures, tant que tous les paramètres et les types de retour de cohérence de format binaire (par exemple. C types). Ce n'est pas un standard, mais il peut être assez portable.

Si le C SDK veut vous d'effectuer des opérations sans fournir un userdata, puis l'orientation de l'objet est probablement inutile, et vous devez juste écrire quelques fonctions. Autre chose, le temps de trouver un nouveau SDK.