Frais généraux de construction de classe de base vides?

Question

Consultez le code suivant:

#include <iostream> 
#include <type_traits> 

class Base 
{ 
    public: static int f() {return 42;} 
}; 

class Derived : public Base 
{ 
    protected: int x; 
}; 

class NotDerived 
{ 
    protected: int x; 
}; 

int main() 
{ 
    std::cout<<sizeof(Base)<<std::endl; 
    std::cout<<sizeof(Derived)<<std::endl; 
    std::cout<<sizeof(NotDerived)<<std::endl; 
    return 0; 
} 

Avec g ++ 4.7 -O3, il imprime:

1 
4 
4 

et si je comprends bien que, cela signifie que l'optimisation vide de classe de base est activée.

Mais ma question concerne les frais généraux d'exécution: la création est-il en tête (et destructing) un objet Derived par rapport à un objet NotDerived en raison du fait que Derived devrait construire/détruire l'objet Base correspondant?

Answer 1

Alors que la norme ne fait aucune garantie à ce que je considérerais un compilateur qui a fait quelque chose de différent dans ces cas légèrement défectueux.

Il n'y a littéralement rien à faire pour initialiser la base: aucune mémoire ne doit être initialisée, aucun mécanisme d'appel virtuel ne doit être mis en place. Aucun code ne devrait être généré pour cela. Cependant, vous devriez toujours vérifier un assemblage dans un paramètre non trivial si cela est vraiment important pour vous.

Answer 2

La réponse à cette question dépendra de l'implémentation, puisque la norme ne spécifie que la sémantique.

Cependant, avec tout compilateur moderne et les optimisations activées, je m'attendrais à ne voir aucune différence.

Il n'y a pas de mémoire supplémentaire à allouer, il n'y a pas de code supplémentaire à exécuter, il n'y a pas de pointeurs vtable à modifier pendant la construction car la base supplémentaire n'est pas virtuelle. Vos constructeurs Derrived et NotDerrived peuvent très bien être identiques pour l'instruction.

Une fois l'optimisation désactivée, vous pouvez appeler une fonction Base::Base() vide sur certaines plates-formes, mais vous ne devriez pas vous soucier des performances des builds non optimisés.

---

J'ai mis en place une petite démo sur gcc.godbolt.org: http://tinyurl.com/cg8ogym

En bref

extern void marker______________________________________(); 
    // ... 
    marker______________________________________(); 
    new NotDerived; 
    marker______________________________________(); 
    new Derived; 
    marker______________________________________(); 

Compile à

call marker______________________________________()@PLT 
movl $4, %edi 
call operator new(unsigned long)@PLT 
call marker______________________________________()@PLT 
movl $4, %edi 
call operator new(unsigned long)@PLT 
call marker______________________________________()@PLT 

Si vous passez au-dessus clanger, il va même optimiser l'allocation de mémoire

Answer 3

#include <type_traits> 
#include <unistd.h> 

class SlowBase 
{ 
    SlowBase() { ::sleep(5); } 

    public: static int f() {return 42;} 
}; 
static_assert(std::is_empty<SlowBase>::value , "SlowBase is empty"); 

La classe Base prend cinq secondes pour construire !!

#include <type_traits> 

class FatBase 
{ 
    FatBase() = default; 
    int data[1024*1024];  
    public: static int f() {return 42;} 
}; 
static_assert(!std::is_empty<FatBase>::value , "FatBase is not empty"); 

Mais celui-ci ne prend pas de temps! Mon argument est que la surcharge de construction n'est pas liée à la taille d'une classe, elle est liée à ce que le constructeur fait.SlowBase est une classe vide mais est très lente à construire. FatBase est un mégaoctet de taille, mais ne met même pas à zéro les éléments du tableau, donc rien à faire. Par exemple, dans votre exemple Base, il y a un constructeur par défaut trivial implicitement déclaré, donc il n'a rien à faire.