Comment lire:

cet article est plutôt long. Si vous voulez en savoir plus sur les agrégats et les PODs (données anciennes), prenez le temps de le lire. Si vous ne vous intéressez qu'aux agrégats, ne lisez que la première partie. Si vous êtes intéressé seulement par les gousses, alors vous devez d'abord lire la définition, les implications, et les exemples d'agrégats et puis vous mai sauter aux gousses, mais je recommande toujours la lecture de la première partie dans son intégralité. Notion des agrégats est essentiel pour la définition des Gousses. Si vous trouvez des erreurs (même mineures, y compris la grammaire, la stylistique, le formatage, la syntaxe, etc.), merci de laisser un commentaire, je vais modifier.

Ce sont des agrégats et pourquoi ils sont spéciaux

définition formelle de la norme C++ ( C++03 8.5.1 §1 ) :

un agrégat est un réseau ou une classe (article 9) sans l'utilisateur déclaré constructeurs (12.1), aucun élément de données non statique privé ou protégé (clause 11)), pas de classes de base (clause 10), et pas de fonctions virtuelles (10.3).

donc, OK, analysons cette définition. Tout d'abord, un tableau est un agrégat. Une classe peut aussi être un agrégat si... attendez! rien n'est dit sur les structures ou les syndicats, ne peuvent-ils pas être des agrégats? Oui, ils le peuvent. En C++, le terme class se réfère à toutes les classes, structures et syndicats. Ainsi, une classe (ou struct, ou union) est un agrégat si et seulement s'il répond aux critères des définitions ci-dessus. Que faire de ces critères impliquent?

• cela ne signifie pas qu'une classe agrégée ne peut pas avoir de constructeurs, en fait elle peut avoir un constructeur par défaut et/ou un constructeur de copie tant qu'ils sont implicitement déclarés par le compilateur, et non explicitement par l'utilisateur

• Non privé ou protégé non-données membres statiques . Vous pouvez avoir autant de fonctions membres privées et protégées (mais pas de constructeurs) ainsi que beaucoup de fonctions membres privées ou protégées static données membres et fonctions membres comme vous le souhaitez et ne violent pas les règles pour les classes agrégées

• une classe agrégée peut avoir un opérateur de copie-assignation déclaré/défini par l'utilisateur et / ou destructeur

• un tableau est un agrégat même s'il s'agit d'un tableau de type de classe non agrégé.

voyons maintenant quelques exemples:

class NotAggregate1
{
  virtual void f() {} //remember? no virtual functions
};

class NotAggregate2
{
  int x; //x is private by default and non-static 
};

class NotAggregate3
{
public:
  NotAggregate3(int) {} //oops, user-defined constructor
};

class Aggregate1
{
public:
  NotAggregate1 member1;   //ok, public member
  Aggregate1& operator=(Aggregate1 const & rhs) {/* */} //ok, copy-assignment  
private:
  void f() {} // ok, just a private function
};

vous comprenez. Voyons maintenant comment les agrégats sont spéciaux. Contrairement aux classes non agrégées, elles peuvent être initialisées avec des accolades {} . Cette syntaxe d'initialisation est communément connu pour les tableaux, et nous viens d'apprendre que ce sont des agrégats. Donc, nous allons commencer avec eux.

Type array_name[n] = {a1, a2, …, am};

si (m = = n)

l'élément i ^th du tableau est initialisé avec un _i

autres si(m < n)

le premier m les éléments du tableau sont initialisés avec un ₁ , un ₂ , ..., un _m et l'autre "151990920 des éléments" sont, si possible, valeur initialisée (voir ci-dessous pour l'explication du terme)

else if(m > n)

le compilateur émettra une erreur

else (c'est le cas quand n n'est pas spécifié du tout comme int a[] = {1, 2, 3}; )

la taille du tableau (n) est supposée être égale à m, donc int a[] = {1, 2, 3}; est équivalent à int a[3] = {1, 2, 3};

Lorsqu'un objet de type scalaire ( bool , int , char , double , pointeurs, etc.) est valeur initialisée cela signifie qu'il est initialisé avec 0 pour ce type ( false pour bool , 0.0 pour double , etc.). Lorsqu'un objet de type classe avec un constructeur par défaut déclaré par l'utilisateur est valeur-initialisé, son constructeur par défaut est appelé. Si le constructeur par défaut est implicitement défini, alors tous les membres non statiques sont initialisés de façon récursive. Cette définition est imprécise et un peu inexact, mais il devrait vous donner l'idée de base. Une référence ne peut pas être initialisée par une valeur. La valeur d'initialisation pour un non-classe d'agrégation peut échouer si, par exemple, la classe a n'y a pas de constructeur par défaut.

Exemples d'initialisation de tableau:

class A
{
public:
  A(int) {} //no default constructor
};
class B
{
public:
  B() {} //default constructor available
};
int main()
{
  A a1[3] = {A(2), A(1), A(14)}; //OK n == m
  A a2[3] = {A(2)}; //ERROR A has no default constructor. Unable to value-initialize a2[1] and a2[2]
  B b1[3] = {B()}; //OK b1[1] and b1[2] are value initialized, in this case with the default-ctor
  int Array1[1000] = {0}; //All elements are initialized with 0;
  int Array2[1000] = {1}; //Attention: only the first element is 1, the rest are 0;
  bool Array3[1000] = {}; //the braces can be empty too. All elements initialized with false
  int Array4[1000]; //no initializer. This is different from an empty {} initializer in that
  //the elements in this case are not value-initialized, but have indeterminate values 
  //(unless, of course, Array4 is a global array)
  int array[2] = {1, 2, 3, 4}; //ERROR, too many initializers
}

voyons maintenant comment les classes agrégées peuvent être initialisées avec des bagues. Peu de la même manière. Au lieu des éléments du tableau, nous initialiserons les membres de données non statiques dans l'ordre de leur apparition dans la définition de classe (ils sont tous publics par définition). Si il y a moins d'initialiseurs que de membres, le reste est initialisé par la valeur. S'il est impossible d'évaluer-initialiser un des membres qui n'a pas été explicitement initialisé, nous obtenons une erreur de compilation. Si il y a plus d'initialiseurs que nécessaire, on obtient une erreur de compilation.

struct X
{
  int i1;
  int i2;
};
struct Y
{
  char c;
  X x;
  int i[2];
  float f; 
protected:
  static double d;
private:
  void g(){}      
}; 

Y y = {'a', {10, 20}, {20, 30}};

dans l'exemple ci-dessus, y.c est initialisé par 'a' , y.x.i1 avec 10 , y.x.i2 avec 20 , y.i[0] avec 20 , y.i[1] avec 30 et y.f est une valeur initialisée, c'est-à-dire initialisée avec 0.0 . L'élément statique protégé d n'est pas initialisé du tout, car il est static .

les unions agrégées sont différentes en ce que vous pouvez initialiser seulement leur premier membre avec accolades. Je pense que si vous êtes assez avancée en C++ d'envisager d'utiliser des syndicats (leur utilisation peut être très dangereux et doit être pensé soigneusement), vous pourriez chercher les règles pour les syndicats dans la norme vous-même :).

maintenant que nous savons ce qui est spécial au sujet des agrégats, essayons de comprendre les restrictions sur les classes; c'est-à-dire, pourquoi ils sont là. Il faut comprendre que l'initialisation memberwise avec des accolades implique que la classe n'est rien de plus que la somme de ses membres. Si un utilisateur défini par le constructeur est présent, cela signifie que l'utilisateur doit faire un travail supplémentaire pour initialiser les membres par conséquent, l'initialisation de brace serait incorrecte. Si des fonctions virtuelles sont présentes, cela signifie que les objets de cette classe ont (sur la plupart des implémentations) un pointeur vers le soi-disant vtable de la classe, qui est défini dans le constructeur, donc brace-initialisation serait insuffisante. Vous pourriez comprendre le reste de la restriction d'une manière semblable à un exercice :).

assez parlé des agrégats. Maintenant nous pouvons définir un ensemble plus strict de types, à savoir, les gousses

Quels sont les Gousses et pourquoi ils sont spéciaux

définition formelle de la norme C++ ( C++03 9 §4 ) :

une pod-struct est une classe agrégée qui n'a pas de membres de données non statiques type non-POD-struct, non-POD-union (or tableau de ces types) ou de référence, et n'a pas d'assignation de copie définie par l'utilisateur opérateur et non défini par l'utilisateur destructeur. De même, une POD-union est une union agrégée qui n'a pas de données non statiques membres du type non-POD-struct, non-POD-union (ou tableau de ces types) ou de référence, et n'a pas d'assignation de copie définie par l'utilisateur opérateur et non défini par l'utilisateur destructeur. Une classe de gousse est une classe c'est soit un pod-struct ou un POD-union.

Wow, celui-ci est plus dur à analyser, n'est-ce pas? :) Laissons les syndicats de côté (pour les mêmes raisons que ci-dessus) et reformulons un peu plus clairement chemin:

une classe agrégée est appelée une gousse si il n'a pas de copie-assignation définie par l'utilisateur opérateur et destructeur et aucun ses membres non statiques est un non-POD la classe, le tableau de la non-POD, ou un référence.

que signifie cette définition? (Ai-je mentionné POD signifie "Plain Old Data ?)

• toutes les classes POD sont des agrégats, ou, pour le dire autrement, si une classe n'est pas un agrégat, alors ce n'est certainement pas un POD
• les Classes, tout comme les structures ,peuvent être PODs même si le terme standard est POD-struct pour les deux cas
• comme dans le cas des agrégats, peu importe les membres statiques de la classe

exemples:

struct POD
{
  int x;
  char y;
  void f() {} //no harm if there's a function
  static std::vector<char> v; //static members do not matter
};

struct AggregateButNotPOD1
{
  int x;
  ~AggregateButNotPOD1() {} //user-defined destructor
};

struct AggregateButNotPOD2
{
  AggregateButNotPOD1 arrOfNonPod[3]; //array of non-POD class
};

POD-classes, Les pod-unions, les types scalaires et les matrices de tels types sont collectivement appelés POD-types.

Les gousses sont spéciales à bien des égards. Je vais vous donner juste quelques exemples.

• POD-classes sont les plus proches de C des structures. Contrairement à eux, les PODs peuvent avoir des fonctions de membre et des membres statiques arbitraires, mais ni l'un ni l'autre de ces deux ne changent la disposition de la mémoire de l'objet. Donc, si vous voulez écrire une bibliothèque dynamique plus ou moins portable qui peut être utilisé à partir de C et même.Net, vous devriez essayer de faire toutes vos fonctions exportées prendre et retourner Seulement les paramètres de type POD.

• la durée de vie des objets de type non-POD commence lorsque le constructeur a terminé et se termine lorsque le destructeur a terminé. Pour les classes POD, la durée de vie commence lorsque le stockage de l'objet est occupé et se termine lorsque le stockage est libéré ou réutilisé.

• pour les objets de type POD il est garanti par la norme que lorsque vous memcpy le contenu de votre objet dans un tableau de char ou char non signé, et puis memcpy le contenu de nouveau dans votre objet, l'objet tiendra sa valeur originale. Notez qu'il n'y a pas de garantie pour les objets de type non-POD. En outre, vous pouvez copier en toute sécurité des objets POD avec memcpy . L'exemple suivant suppose que T est un type de gousse:

  #define N sizeof(T)
  char buf[N];
  T obj; // obj initialized to its original value
  memcpy(buf, &obj, N); // between these two calls to memcpy,
  // obj might be modified
  memcpy(&obj, buf, N); // at this point, each subobject of obj of scalar type
  // holds its original value
  

• instruction goto. Comme vous le savez peut-être, il est illégal (le compilateur devrait émettre une erreur) de faire un saut via goto d'un point où une variable n'était pas encore en scope à un point où elle est déjà en scope. Cette restriction ne s'applique que si la variable est de type non-POD. Dans l'exemple suivant f() est mal formé, alors que g() est bien formé. Notez que le compilateur de Microsoft est trop libéral avec cette règle-il juste un avertissement dans les deux cas.

  int f()
  {
    struct NonPOD {NonPOD() {}};
    goto label;
    NonPOD x;
  label:
    return 0;
  }
  
  int g()
  {
    struct POD {int i; char c;};
    goto label;
    POD x;
  label:
    return 0;
  }
  

• il est garanti qu'il n'y aura pas de rembourrage au début d'un objet POD. En d'autres termes, si le premier membre D'un POD-class A est de type T, vous pouvez en toute sécurité reinterpret_cast de A* à T* et obtenir le pointeur vers le premier membre et vice versa.

La liste continue encore et encore...

Conclusion

il est important de comprendre ce qu'est exactement une gousse parce que de nombreuses caractéristiques linguistiques, comme vous le voyez, se comportent différemment pour elles.

Quels changements pour le C++11?

agrégats

la définition standard d'un agrégat a légèrement changé, mais elle est toujours à peu près la même:

un agrégat est un tableau ou une classe (Clause 9) sans constructeur fourni par l'utilisateur (12.1), pas de corset ou égal initialiseurs pour les non-membres de données statiques (9.2), no private ou protected éléments de données non statiques (article 11 )), pas de classes de base (Clause 10), et pas de fonctions virtuelles (10.3).

Ok, qu'est-ce qui a changé?

1. auparavant, un agrégat ne pouvait pas avoir de constructeurs déclarés par l'utilisateur , mais maintenant il ne peut pas avoir de constructeurs fournis par l'utilisateur . Est-il une différence? Oui, il y en a, parce que maintenant vous pouvez déclarer les constructeurs et par défaut eux:

   struct Aggregate {
       Aggregate() = default; // asks the compiler to generate the default implementation
   };
   

   il s'agit toujours d'un agrégat parce qu'un constructeur (ou toute fonction membre spéciale) qui est en défaut sur la première déclaration n'est pas fourni par l'utilisateur.

2. maintenant un agrégat ne peut pas avoir de attachez-ou-équivalent-initialiseurs pour les membres de données non statiques. Qu'est-ce que cela signifie? Eh bien, c'est juste parce qu'avec cette nouvelle norme, nous pouvons initialiser les membres directement dans la classe comme ceci:

   struct NotAggregate {
       int x = 5; // valid in C++11
       std::vector<int> s{1,2,3}; // also valid
   };
   

   L'utilisation de cette fonctionnalité rend la classe plus un agrégat parce qu'il est fondamentalement équivalent à fournir votre propre constructeur par défaut.

ainsi, ce qui est un agrégat n'a pas beaucoup changé du tout. C'est toujours la même idée de base, adaptés aux nouvelles fonctionnalités.

et les gousses?

les gousses ont subi beaucoup de changements. Beaucoup de règles précédentes sur Les gousses ont été assouplies dans cette nouvelle norme, et la façon dont la définition est fournie dans la norme a été radicalement changé.

l'idée d'un POD est de capturer essentiellement deux propriétés distinctes:

1. il supporte l'initialisation statique, et
2. compiler un POD en C++ vous donne la même configuration mémoire qu'une structure compilée en C.

pour cette Raison, la définition a été divisé en deux concepts distincts: trivial classes et standard-layout classes, parce que celles-ci sont plus utiles que POD. La norme utilise maintenant rarement le terme POD, préférant les concepts plus spécifiques trivial et standard-layout .

la nouvelle définition dit essentiellement qu'un POD est une classe qui est à la fois trivial et a la norme-layout, et cette propriété doit tenir récursivement pour tous les membres de données non statiques:

une structure de gousse est une classe non syndicale qui est à la fois une classe triviale et une classe de la norme-cadre., et n'a pas de données non-statiques membres de type non-POD struct, non-POD union (ou tableau de tels types). De même, un syndicat de gousse est un syndicat qui est à la fois une classe triviale et une classe de layout standard, et pas de données non statiques membres de type non-POD struct, non-POD union (ou tableau de tels types). Une classe de gousse est un classe qui est soit une structure de gousse ou un syndicat de gousse.

passons en revue chacune de ces deux propriétés en détail séparément.

Trivial classes

Trivial est la première propriété mentionnée ci-dessus: les classes triviales supportent l'initialisation statique. Si une classe est trivialement copiable (un super ensemble de classes triviales), il est correct de copier sa représentation au-dessus de l'endroit avec des choses comme memcpy et s'attendre à ce que le résultat soit le même.

la norme définit une classe triviale comme suit:

une classe trivialement copiable est une classe qui:

- n'a aucun constructeur de copie non trivial (12.8),

- n'a aucun constructeur de déplacement non trivial (12.8),

- n'a pas d'opérateurs non-trivial copy assignment (13.5.3, 12.8),

- n'a pas d'opérateurs non-trivial move assignment (13.5.3, 12.8), et

- possède un destructeur trivial (12.4).

une classe triviale est une classe qui a un constructeur par défaut trivial (12.1) et qui est trivialement copiable.

[ Note: en particulier, une classe trivialement copiable ou triviale n'a pas de fonctions virtuelles ou des classes de base virtuelles. - note finale ]

alors, qu'est-ce que toutes ces choses triviales et non triviales?

un constructeur de copie/déplacement pour la classe X est trivial s'il n'est pas fourni par l'utilisateur et si

- la classe X n'a pas de fonctions virtuelles (10.3) et pas de classes de base virtuelles (10.1), et

- le constructeur sélectionné pour copier / déplacer chaque sous-objet de la classe de base directe est trivial, et

- pour chaque élément de données non statique de X qui est du type de classe (ou de son tableau), le constructeur sélectionné pour copier/déplacer le membre est triviale;

sinon le constructeur copy/move n'est pas trivial.

fondamentalement cela signifie qu'une copie ou un constructeur de déplacement est trivial si elle n'est pas fournie par l'utilisateur, la classe n'a rien de virtuel en elle, et cette propriété est retenue récursivement pour tous les membres de la classe et pour la classe de base.

la définition d'un opérateur d'affectation trivial copy/move est très similaire, remplaçant simplement le mot" constructeur "par"opérateur d'affectation".

trivial destructeur a aussi une définition similaire, avec la contrainte qu'il ne peut pas être virtuel.

et encore une autre règle similaire existe pour les constructeurs par défaut triviaux, avec l'ajout qu'un constructeur par défaut n'est pas-trivial si la classe a des données non statiques membres de corset ou égal initialiseurs , dont nous avons vu ci-dessus.

voici quelques exemples pour éclaircir tout:

// empty classes are trivial
struct Trivial1 {};

// all special members are implicit
struct Trivial2 {
    int x;
};

struct Trivial3 : Trivial2 { // base class is trivial
    Trivial3() = default; // not a user-provided ctor
    int y;
};

struct Trivial4 {
public:
    int a;
private: // no restrictions on access modifiers
    int b;
};

struct Trivial5 {
    Trivial1 a;
    Trivial2 b;
    Trivial3 c;
    Trivial4 d;
};

struct Trivial6 {
    Trivial2 a[23];
};

struct Trivial7 {
    Trivial6 c;
    void f(); // it's okay to have non-virtual functions
};

struct Trivial8 {
     int x;
     static NonTrivial1 y; // no restrictions on static members
};

struct Trivial9 {
     Trivial9() = default; // not user-provided
      // a regular constructor is okay because we still have default ctor
     Trivial9(int x) : x(x) {};
     int x;
};

struct NonTrivial1 : Trivial3 {
    virtual void f(); // virtual members make non-trivial ctors
};

struct NonTrivial2 {
    NonTrivial2() : z(42) {} // user-provided ctor
    int z;
};

struct NonTrivial3 {
    NonTrivial3(); // user-provided ctor
    int w;
};
NonTrivial3::NonTrivial3() = default; // defaulted but not on first declaration
                                      // still counts as user-provided
struct NonTrivial5 {
    virtual ~NonTrivial5(); // virtual destructors are not trivial
};

norme-cadre

norme-cadre est la deuxième propriété. La norme mentionne que celles-ci sont utiles pour communiquer avec d'autres langues, et c'est parce qu'une classe de mise en page standard a la même mise en page mémoire que l'équivalent (2) structure ou union.

il s'agit d'une autre propriété qui doit être détenue récursivement pour les membres et toutes les classes de base. Et comme d'habitude, aucune fonction virtuelle ou classe de base virtuelle n'est autorisée. Cela rendrait la disposition incompatible avec C.

une règle assouplie est que les classes de la norme-cadre doivent avoir tous les éléments de données non statiques avec le même contrôle d'accès. Auparavant ceux-ci devaient être tous public , mais maintenant vous pouvez les faire privés ou protégés, aussi longtemps qu'ils sont tous "1519160920 privées" ou tous protégées.

// empty classes have standard-layout
struct StandardLayout1 {};

struct StandardLayout2 {
    int x;
};

struct StandardLayout3 {
private: // both are private, so it's ok
    int x;
    int y;
};

struct StandardLayout4 : StandardLayout1 {
    int x;
    int y;

    void f(); // perfectly fine to have non-virtual functions
};

struct StandardLayout5 : StandardLayout1 {
    int x;
    StandardLayout1 y; // can have members of base type if they're not the first
};

struct StandardLayout6 : StandardLayout1, StandardLayout5 {
    // can use multiple inheritance as long only
    // one class in the hierarchy has non-static data members
};

struct StandardLayout7 {
    int x;
    int y;
    StandardLayout7(int x, int y) : x(x), y(y) {} // user-provided ctors are ok
};

struct StandardLayout8 {
public:
    StandardLayout8(int x) : x(x) {} // user-provided ctors are ok
// ok to have non-static data members and other members with different access
private:
    int x;
};

struct StandardLayout9 {
    int x;
    static NonStandardLayout1 y; // no restrictions on static members
};

struct NonStandardLayout1 {
    virtual f(); // cannot have virtual functions
};

struct NonStandardLayout2 {
    NonStandardLayout1 X; // has non-standard-layout member
};

struct NonStandardLayout3 : StandardLayout1 {
    StandardLayout1 x; // first member cannot be of the same type as base
};

struct NonStandardLayout4 : StandardLayout3 {
    int z; // more than one class has non-static data members
};

struct NonStandardLayout5 : NonStandardLayout3 {}; // has a non-standard-layout base class

template <typename T>
struct std::is_pod;
template <typename T>
struct std::is_trivial;
template <typename T>
struct std::is_trivially_copyable;
template <typename T>
struct std::is_standard_layout;