Quelles sont les Agrégats et les Gousses et comment/pourquoi sont-ils de spécial?

Ce FAQ est sur les Agrégats et les Gousses et couvre le matériel suivant:

  • Quels sont Agrégats?
  • Quels sont PODs (Plain Old Données)?
  • Comment sont-ils liés?
  • Comment et pourquoi sont-ils de spécial?
  • Quels changements pour le C++11?
InformationsquelleAutor Armen Tsirunyan | 2010-11-14
  1. 540

    Comment lire:

    Cet article est assez long. Si vous voulez savoir à propos de ces deux agrégats et Pod (Plain Old Données) prendre le temps de le lire. Si vous êtes intéressé seulement dans les agrégats, lire seulement la première partie. Si vous êtes intéressé dans les Gousses, puis vous devez d'abord lire la définition, implications et exemples d'agrégats et puis vous peut saut à Gousses, mais je voudrais encore vous recommandons la lecture de la première partie dans son intégralité. La notion d'agrégats est essentiel pour la définition des Gousses. Si vous trouvez des erreurs (même mineur, y compris la grammaire, la stylistique, de la mise en forme, la syntaxe, etc.) merci de laisser un commentaire, je vais modifier.

    Cette réponse s'applique à C++03. Pour d'autres normes C++, voir:

    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 tableau ou une classe (clause 9) sans que l'utilisateur n'-déclaré
    les constructeurs (12.1), aucun privés ou protégés non-membres de données statiques (clause 11),
    pas de classes de base (article 10), et pas de fonctions virtuelles (10.3).

    Donc, OK, nous allons analyser 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, les structures et les syndicats. Ainsi, une classe (ou struct ou union) est un agrégat si et seulement si elle satisfait aux critères de l'définitions ci-dessus. Que faire de ces critères impliquent?

    • Cela ne signifie pas un agrégat de classe ne peut pas avoir de constructeurs, en fait, il peut avoir un constructeur par défaut et/ou d'un constructeur de copie, aussi longtemps qu'ils sont déclarées implicitement par le compilateur, et non explicitement par l'utilisateur

    • Pas privés ou protégés non-membres de données statiques. Vous pouvez avoir autant d'privé et protégé des fonctions membres (mais pas les constructeurs) ainsi que de nombreux privés ou protégés statique membres de données et les fonctions de membres que vous le souhaitez et ne pas enfreindre les règles pour l'ensemble des classes

    • Un total classe peut avoir un utilisateur déclaré/défini par l'utilisateur de copier-opérateur d'affectation et/ou destructeur

    • Un tableau est un ensemble, même si c'est un ensemble de non-agrégation type de classe.

    Maintenant regardons 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 obtenez l'idée. Maintenant, nous allons voir comment les agrégats sont spéciales. Ils, contrairement à la non-agrégation des classes, peut être initialisé avec des accolades {}. Cette syntaxe d'initialisation est communément connu pour les tableaux, et nous avons appris que ce sont des agrégats. Donc, nous allons commencer avec eux.

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

    if(m == n)

    le ième élément du tableau est initialisé avec uni

    else if(m < n)

    le premier m éléments du tableau sont initialisés avec un1,2, ...,m et l'autre n - m éléments sont, si possible, valeur initialisée (voir ci-dessous pour l'explication du terme)

    else if(m > n)

    le compilateur émet une erreur

    d'autre (c'est le cas lorsque n n'est pas spécifié comme int a[] = {1, 2, 3};)

    la taille de la matrice (n) est supposé être égal à m, de sorte 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 utilisateur déclaré dans le constructeur par défaut est la 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 récursivement la valeur d'initialisation. 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 la valeur d'initialisation. 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
}

    Maintenant, nous allons voir comment agréger les classes peuvent être initialisés avec des accolades. Peu de la même manière. Au lieu des éléments du tableau, nous allons initialiser les non-membres de données statiques dans l'ordre de leur apparition dans la définition de la classe (ils sont tout public, par définition). Si il y a moins d'initialiseurs que les membres, le reste est de la valeur d'initialisation. S'il est impossible de valeur d'initialisation de l'un des membres qui n'ont pas été explicitement initialisée, on obtient une erreur de compilation. Si il y a plus d'initialiseurs que nécessaire, on obtient une erreur de compilation ainsi.

    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é avec '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 la valeur d'initialisation, qui est initialisé avec 0.0. Les protégés de membre statique d n'est pas initialisé à tous, parce que c'est static.

    Globale syndicats sont différentes que vous pouvez initialiser seulement leur premier membre avec des 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é avec soin), 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 de agrégats, nous allons essayer de comprendre les restrictions sur les classes; c'est, pourquoi ils sont là. Nous devrions comprendre que memberwise d'initialisation 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 donc accolade de l'initialisation serait incorrect. Si les fonctions virtuelles sont présentes, cela signifie que les objets de cette classe ont (sur la plupart des implémentations) un pointeur vers la soi-disant vtable de la classe, qui est défini dans le constructeur, donc brace-initialisation serait insuffisant. Vous pourriez comprendre le reste de la restriction d'une manière semblable à un exercice :).

    Donc assez sur les agrégats. Nous pouvons maintenant 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):

    Un POD-struct est une classe d'agrégation
    qui n'a pas de non-données membres statiques de
    type de non-POD-struct, non-POD-union (ou
    tableau de ces types) ou de référence, et
    n'a pas défini par l'utilisateur copie de l'assignation
    opérateur et non défini par l'utilisateur
    destructeur. De même, un POD-union
    un total de l'union qui n'a pas de
    non aux données membres statiques de type
    non-POD-struct, non-POD-union (ou
    tableau de ces types) ou de référence, et
    n'a pas défini par l'utilisateur copie de l'assignation
    opérateur et non défini par l'utilisateur
    destructeur. Un module de classe est une classe
    que se soit un POD-struct ou un
    POD-union.

    Wow, celui-ci est plus difficile à analyser, n'est-ce pas? 🙂 Laissons les syndicats out (pour les mêmes raisons que ci-dessus) et de reformuler en un peu plus clair:

    Une classe d'agrégation est appelé un POD si
    il n'a pas défini par l'utilisateur copie de cession
    l'opérateur et le destructeur et aucun de
    ses membres non statiques est un non-POD
    la classe, le tableau de la non-POD, ou un
    de référence.

    Quoi cette définition implique? (Ai-je mentionné POD signifie Plaine Anciennes Données?)

    • Tous les POD classes sont des agrégats, ou, à l'inverse, si une classe n'est pas un agrégat alors c'est sûr pas un POD
    • Classes, tout comme les structures, peuvent être Gousses même si la norme terme est POD-struct pour les deux cas
    • Tout comme dans le cas des agrégats, il n'a pas d'importance ce que les membres statiques de la classe a

    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, POD-les syndicats, les types scalaires, et les tableaux de ces types sont collectivement appelés POD-types.

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

    • POD-classes sont les plus proches de C des structures. Contrairement à eux, les Gousses peuvent avoir des fonctions de membre et de l'arbitraire de membres statiques, mais aucun de ces deux changement de la disposition de la mémoire de l'objet. Donc, si vous voulez écrire plus ou moins portable bibliothèque dynamique qui peut être utilisé à partir de C et même .NET, vous devriez essayer de faire tout votre des fonctions exportées prendre et de ne renvoyer que les paramètres de POD-types.

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

    • Pour les objets de types POD, il est garanti par la norme que lorsque vous memcpy le contenu de votre objet dans un tableau de char ou unsigned char, et puis memcpy le contenu dans votre objet, il tiendra sa valeur d'origine. Notez qu'il n'y a aucune garantie pour les objets de la non-POD types. Aussi, vous pouvez copier POD objets avec memcpy. L'exemple suivant suppose que T est un module de type:

      #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 doit émettre une erreur) de faire un saut par goto à partir d'un point où certaines variables n'était pas encore dans le champ d'application à un point où il est déjà dans le champ d'application. Cette restriction s'applique uniquement si la variable est de la non-type de POD. Dans l'exemple suivant f() est mal formé alors que g() est bien formé. Notez que Microsoft compilateur est trop libérale à cette règle, il a 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 dans le début d'une GOUSSE d'objet. En d'autres termes, si un module de classe du premier membre 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 un POD est parce que de nombreuses fonctionnalités de langage, comme vous le voyez, de se comporter différemment pour eux.

    • Belle réponse. Commentaires: "Si le constructeur par défaut est implicitement défini, alors tous les membres non statiques sont récursivement valeur initialisée." et "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." n'est pas correct: la Valeur d'initialisation d'une classe avec un implicitement-déclarée constructeur par défaut n'est pas necessiate un implicitement par défaut définis par le constructeur. Ainsi, compte tenu de (insérer private: appropriée): struct A { int const a; }; puis A() est bien formé, même si A's de constructeur par défaut définition serait mal formé.
    • Ce n'est pas vraiment de la FAQ, c'est beaucoup trop long. Aussi, veuillez entrer vos acronymes défini dans le premier paragraphe du document, si possible, au lieu de 2/3 de la voie à travers.
    • Armen, la clé de format de code dans des balles est à tiret deux fois - une fois pour être une balle de paragraphe et une fois pour les cours de code. Fixe que pour toi. :)
    • Si vous parvenez à le pack de la même information dans une courte réponse, nous serions tous heureux jusqu'-vote!
    • "Un tableau est un agrégat de même c'est un ensemble de non-agrégation type de classe.", même chose est vraie au sujet des classes avec des non-agrégation (non statique) de données des membres, ala, il suffit les conditions habituelles pour les agrégats. Je ne suis pas sûr, mais je pense faire un distinct sur la réponse globale de l'initialisation serait trop de travail. Cela seul est une matière suffisante pour une seule et unique réponse, il me semble (des trucs comme accolade élision et pourquoi il peut être dangereux peuvent aussi être mentionné).
    • OK, mais je trouve qu'il est difficile de les reformuler. Si vous voulez prendre le temps de corriger la phrase, je lui en serais reconnaissant. Je veux dire que la déclaration de l'/défini la partie
    • Ce peut-être pourrait avoir été divisé en trois ou quatre articles distincts, avec des liens avec chaque autre, où est-il pertinent? Pour le moment c'est un peu un mur de texte.
    • Nous sommes tous encore fortement des expériences avec ce nouveau-né idée, et au moins je suis loin d'être fixé sur un format spécifique. Votre idée me semble bon pour moi, donc en supposant Armen ne me dérangerait pas (Armen?) pourquoi ne pas aller de l'avant et de le faire tout simplement?
    • Si vous voulez diviser l'article en deux, puis-je faire de l'esprit, mais apparemment ce n'est pas grave. En revanche, je suis d'accord que la plus courte est la meilleure, et si j'écris d'autres réponses comme cela, je vais prendre cela en considération
    • aussi ne remarque vous pouvez effectuer plusieurs réponses à la même question. Chaque réponse peut contenir une partie de la solution à la question. La vis qui a accepté de marque de chose, à mon avis 🙂
    • Vous avez demandé à un point des erreurs, voire des fautes de frappe. 🙂 "Je pense que si vous êtes avancées". Excellent article, merci beaucoup!
    • Merci, fixe
    • je ne suis pas un gros coup développeur c/c++ droit maintenant, commence tout juste à apprendre les bonnes choses à l'avance comme une grave programmeur (pour une MNC dans lequel j'ai placé). Devrais-je être inquiet au sujet de ce droit maintenant? tout cela POD et des agrégats de choses? (J'ai pu comprendre des agrégats mais Gousses m'a laissé me gratter la tête pour être honnête).
    • Super article! Mais en ce qui concerne "le module spéciaux sont extrêmement nombreuses façons" est entièrement détaillée de n'importe où? J'ai cherché partout et c'est la liste la plus complète que j'ai trouvé, mais je suis curieux de savoir de quoi d'autre il pourrait y avoir.
    • La réponse est grande. Je suis toujours revoir ce poste pendant un certain temps. Par la manière, à propos des avertissements pour Visual Studio. "goto" pour pod venir avec de l'ignorance à la MSVC compilateur comme Vous l'avez mentionné. Mais pour le commutateur/instruction de cas, il génère une erreur de compilation. Basé sur ce concept, j'ai effectué quelques test-pod-checker: stackoverflow.com/questions/12232766/test-for-pod-ness-in-c-c11/...
    • Post-Nice! J'ai un doute à ce sujet-si ce n'est pas le meilleur endroit pour demander, s'il vous plaît laissez-moi savoir. Sur le POD définition, il est indiqué que "Similarly, a POD-union is an aggregate union that has no .... types) or reference, and has ...". Le reference sur le présent contexte, on entend uniquement les références ou il signifie aussi des pointeurs? I. e., elle est littérale ou même de class: "In C++, the term class refers to all classes, structs, and unions."?
    • Je changerais le dernier exemple dans les "agrégats" de la section, de sorte qu'il y aurait des non-trivial membre dans l'ensemble, de dire std::string
    • Question: Que sur les pointeurs? Est votre struct POD encore un POD si j'ajoute int * pi; ou char * acName; ou même MyCustomClass * pObject;?
    • Oui, c'est encore un POD
    • Très bonne explication, en effet! Je vous recommande de préciser que les agrégats peuvent avoir public, privé et protégé fonctions, statique ou non statique, comme au secteur public, privé et protégé de données statiques. C'est devenu clair pour moi dans le non-POD exemple avec une fonction publique.
    • Dans l'exemple du tableau - B b1[3] = {B()};, comment se fait - B est un agrégat de classe, étant donné qu'il est défini par l'utilisateur, le constructeur?
    • B n'est pas un agrégat de classe, mais un tableau de B est un agrégat. Un tableau de quelque chose est un agrégat
    • Dans le point, qui commence avec "La durée de vie des objets de la non-POD type de classe commence lorsque le constructeur a fini et se termine lorsque le destructeur de a fini." la dernière partie devrait plutôt dire "quand le destructeur commence."

    InformationsquelleAutor
  2. 438

    Quels changements pour le C++11?

    Agrégats

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

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

    Ok, ce qui a changé?

    1. Précédemment, un agrégat peut ne pas avoir de l'utilisateur déclaré les constructeurs, mais maintenant il ne peut pas avoir fourni par l'utilisateur constructeurs. Est-il une différence? Oui, il est, parce que maintenant vous pouvez déclarer les constructeurs et les par défaut eux:

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

      C'est encore un agrégat parce qu'un constructeur (ou tout membre de la fonction) qui est par défaut sur la première déclaration n'est pas fourni par l'utilisateur.

    2. Maintenant un total ne peut pas avoir de corset ou égal initialiseurs pour les non-membres de données statiques. Qu'est-ce que cela signifie? Eh bien, c'est simplement parce que cette nouvelle norme, nous pouvons initialiser directement les membres de 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 que c'est essentiellement équivalente à la fourniture de votre propre constructeur par défaut.

    Donc, ce qui est un agrégat n'a pas changé grand-chose. C'est toujours la même idée de base, adaptés aux nouvelles fonctionnalités.

    Qu'en Dosettes?

    Gousses suis passé par 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 donnée dans la norme a été radicalement modifiée.

    L'idée d'une GOUSSE de capture essentiellement deux propriétés distinctes:

    1. Il prend en charge initialisation statique, et
    2. De la compilation d'un module en C++ vous donne la même disposition de la mémoire comme une struct compilée en c

    De ce fait, la définition a été divisé en deux concepts distincts: trivial classes et standard-layout classes, car elles sont plus utiles que les POD. La norme utilise rarement le terme POD, préférant le plus spécifique trivial et standard-layout concepts.

    La nouvelle définition de dit en gros qu'un POD est une classe qui est à la fois trivial et a standard-layout, et cette propriété doit tenir de manière récursive pour tous les non-membres de données statiques:

    Un module struct est une non-union de la classe qui est à la fois un trivial de classe et un standard-classe de mise en page,
    et n'a pas non données membres statiques de type non-POD struct, non-POD de l'union (ou d'une matrice de ce type).
    De même, un POD de l'union est une union qui est à la fois un trivial de classe et une mise en page standard de la classe, et a
    pas de non-données membres statiques de type non-POD struct, non-POD de l'union (ou d'une matrice de ce type).
    Un module de classe est une classe qui est soit un module struct ou un POD de l'union.

    Reprenons chacun 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: trivial classes de soutien initialisation statique.
    Si une classe est trivialement copiable (un sur-ensemble de trivial classes), il est ok pour copier sa représentation sur la place avec des choses comme memcpy et attendre le résultat sera le même.

    La norme définit un trivial classe comme suit:

    Un trivialement copiable classe est une classe qui:

    — n'a pas de non-trivial copie de constructeurs (12.8),

    — n'a pas non triviale des constructeurs de déplacement (12.8),

    — n'a pas de non-trivial copie des opérateurs d'affectation (13.5.3, 12.8),

    — n'a pas non trivial de déplacer des opérateurs d'affectation (13.5.3, 12.8), et

    — a un trivial destructeur (12.4).

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

    [ Remarque: En particulier, un trivialement copiable ou trivial de classe n'ont pas de fonctions virtuelles
    ou virtuel classes de base.—la note de fin de ]

    Donc, ce sont tous ceux trivial et non-triviales?

    Un copier/déplacer constructeur de la classe X est trivial si il n'est pas fourni par l'utilisateur et si

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

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

    — pour chaque non-membre de données statiques de X qui est de type classe (ou d'une matrice de celui-ci), le constructeur
    sélectionné pour copier/déplacer le membre est triviale;

    sinon le copier/déplacer constructeur est non-trivial.

    Fondamentalement, cela signifie que la copie ou le déplacement constructeur est trivial si il n'est pas fourni par l'utilisateur, la classe n'a rien de virtuel, et cette propriété détient de manière récursive pour tous les membres de la classe et de la classe de base.

    La définition d'un banal copier/déplacer opérateur d'affectation est très similaire, il suffit de remplacer le mot "constructeur" avec "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 trivial constructeurs par défaut, avec l'ajout d'un constructeur par défaut n'est pas négligeable si la classe a non-membres de données statiques avec corset ou égal initialiseurs, qui nous l'avons vu ci-dessus.

    Voici quelques exemples pour effacer 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
};

    Standard-layout

    Standard-layout est la deuxième propriété. La norme mentionne le fait que ceux-ci sont utiles pour communiquer avec les autres langues, c'est parce qu'un standard-classe de mise en page a la même disposition de la mémoire de l'équivalent C struct ou union.

    C'est une autre propriété qui doit tenir de manière récursive pour les membres et de toutes les classes de base. Et comme d'habitude, pas de fonctions virtuelles ou virtuel classes de base sont autorisés. Qui permettrait de faire la mise en page incompatible avec C.

    Une ambiance détendue, la règle ici est que les classes de layout doit disposer de tous les non-membres de données statiques avec le même contrôle d'accès. Auparavant, ils devaient être tous public, mais maintenant vous pouvez les rendre privés ou protégés, aussi longtemps qu'ils sont tous privé ou tous protégé.

    Lors de l'utilisation de l'héritage, un seul classe dans l'ensemble de l'arbre d'héritage peuvent avoir des non-membres de données statiques, et le premier non-membre de données statiques ne peuvent pas être d'une classe de base type (cela pourrait briser aliasing règles), sinon, ce n'est pas un standard-classe de mise en page.

    C'est la façon dont la définition va dans le texte standard:

    Standard-layout classe est une classe qui:

    — n'a pas non données membres statiques de type non-standard-classe de mise en page (ou un tableau de ce type)
    ou de référence,

    — n'a pas de fonctions virtuelles (10.3) et pas de virtuel classes de base (10.1),

    — a le même contrôle d'accès (Clause 11) pour tous les non-membres de données statiques,

    — n'a pas non standard-layout classes de base,

    — soit n'a pas de non-membres de données statiques dans la plupart de la classe dérivée et au plus une classe de base avec
    non-membres de données statiques, ou n'a pas de classes de base avec les données membres statiques, et

    — n'a pas de classes de base du même type que le premier non-membre de données statiques.

    Standard-layout struct est un standard-classe de mise en page définie avec la classe-clé struct ou
    la classe-classe de clé.

    Standard-layout de l'union est un standard-classe de mise en page définie avec la classe-clé de l'union.

    [ Remarque: Standard-layout classes sont utiles pour communiquer avec le code écrit dans d'autres langages de programmation. Leur mise en page est spécifié dans la version 9.2.—la note de fin de ]

    Et nous allons voir quelques exemples.

    //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

    Conclusion

    Avec ces nouvelles règles beaucoup plus de types peut être Gousses maintenant. Et même si un type n'est pas POD, nous pouvons profiter de quelques-uns de la GOUSSE de propriétés séparément (si c'est seulement un de banal ou standard-layout).

    De la bibliothèque standard a les traits de tester ces propriétés dans l'en-tête <type_traits>:

    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;
    • pouvez vous s'il vous plaît élaborer des règles suivantes: a) les classes de layout doit disposer de tous les non-membres de données statiques avec le même contrôle d'accès; b) d'une seule classe dans l'ensemble de l'arbre d'héritage peuvent avoir des non-membres de données statiques, et le premier non-membre de données statiques ne peuvent pas être d'une classe de base type (cela pourrait briser aliasing règles). Surtout quelles sont les raisons? Pour la règle, pouvez-vous fournir un exemple de rupture de l'aliasing?
    • Voir ma réponse. J'ai essayé de répondre au meilleur de mes connaissances.
    • Pourriez voulez mettre à jour ce pour C++14, qui a supprimé le "pas de corset ou égal initialiseurs" pour les agrégats.
    • merci pour le heads-up. Je vais regarder ces changements sous peu et le mettre à jour.
    • Pour l'utilisateur déclaré constructeurs, il est également utile lorsque l'utilisateur déclare un constructeur privé sans fournir de définition.
    • Quelques exemples de POD qui partagent des propriétés de la trivialité et de la mise en page standard aiderait 🙂
    • Veuillez mettre à jour ce génial explication correspondant à la dépréciation de la nacelle en c++20 projet. 48225673
    • Concernant l'aliasing: Il y a un C++ disposition de la règle que si une classe C a un (vide) de la base X, et le premier membre de données de C est de type X, alors que le premier membre ne peut pas être au même décalage que la base de X; il obtient un mannequin rembourrage octet à l'avance, si nécessaire pour l'éviter. Avoir deux instances de X (ou sous-classe) à la même adresse pourrait casser des choses qui ont besoin de distinguer les différentes instances via leurs adresses (vide instance a rien d'autre à distinguer...). En tout cas la nécessité de mettre en que rembourrage octet pauses "mise en page compatible".
    • ...a POD is a class that is both trivial and has standard-layout... Il me semble que si une classe est trivial, toutes les données membres statiques doit être trivial, et si une classe a standard-layout, que tous les non-statique des données, les membres doivent avoir standard-layout. Est-il une raison pour spécifier ...and this property must hold recursively for all non-static data members? Plus précisément, est-il possible pour une classe d'être trivial et standard-layout, mais ne pas être un POD, ou pour une classe de non-trivial ou non standard-layout, mais encore un POD?

    InformationsquelleAutor R. Martinho Fernandes
  3. 99

    Ce qui a changé pour le C++14

    Nous pouvons nous référer à la Projet de C++14 standard de référence.

    Agrégats

    Ce qui est couvert dans la section 8.5.1 Agrégats qui nous donne la définition suivante:

    Un agrégat est un tableau ou une classe (article 9) et n'a pas fourni par l'utilisateur
    les constructeurs (12.1), aucun privés ou protégés non-membres de données statiques
    (Clause 11), pas de classes de base (article 10), et pas de fonctions virtuelles
    (10.3).

    Le seul changement, c'est maintenant l'ajout de dans-membre de la classe des initialiseurs ne pas faire une classe non-agrégées. L'exemple suivant de C++11 agrégation d'initialisation pour les classes avec les membres de l'in-pace initialiseurs:

    struct A
{
int a = 3;
int b = 3;
};

    n'était pas un agrégat en C++11, mais c'est en C++14. Ce changement est couvert dans N3605: Membre des initialiseurs et agrégats, qui est la suivante résumé:

    Bjarne Stroustrup et Richard Smith a soulevé une question au sujet d'agrégation
    initialisation et de membre des initialiseurs de ne pas travailler ensemble. Cette
    le papier se propose de résoudre le problème par l'adoption de Smith libellé proposé
    qui supprime une restriction que les agrégats ne peuvent pas avoir
    membre-initialiseurs.

    POD reste le même

    La définition de POD(plaine anciennes données) struct est couvert dans la section 9 Classes qui dit:

    Un module struct110 est un non-union de la classe qui est à la fois simple et classe
    standard-classe de mise en page, et n'a pas non données membres statiques de type
    non-POD struct, non-POD de l'union (ou d'une matrice de ce type). De même, un
    POD de l'union est une union qui est à la fois un trivial de classe et un
    standard-classe de mise en page, et n'a pas non données membres statiques de type
    non-POD struct, non-POD de l'union (ou d'une matrice de ce type). Un module de classe est
    une classe qui est soit un module struct ou un POD de l'union.

    qui est le même libellé que C++11.

    Standard-Modifications de Mise en page pour le C++14

    Comme indiqué dans les commentaires pod repose sur la définition de standard-layout et qui a changé pour le C++14, mais c'était par défaut des rapports qui ont été appliqués à C++14 après le fait.

    Il y avait trois DRs:

    Donc standard-layout est passé de cette Pré C++14:

    Standard-layout classe est une classe qui:

    • (7.1) n'a pas non données membres statiques de type non-standard-classe de mise en page (ou un tableau de ce type) ou de référence,
    • (7.2) n'a pas de fonctions virtuelles ([classe.virtuel]) et pas de virtuel classes de base ([classe.mi]),
    • (7.3) a le même contrôle d'accès (Clause [classe.accès]) pour tous les non-membres de données statiques,
    • (7.4) n'a pas non standard-layout classes de base,
    • (7.5) soit n'a pas de non-membres de données statiques dans la plupart de la classe dérivée et au plus une classe de base avec les données membres statiques, ou a
      pas de classes de base avec les données membres statiques, et
    • (7.6) n'a pas de classes de base du même type que le premier non-membre de données statiques.109

    À dans C++14:

    Une classe S est un standard-classe de mise en page si c':

    • (3.1) n'a pas non données membres statiques de type non-standard-classe de mise en page (ou un tableau de ce type) ou de référence,
    • (3.2) n'a pas de fonctions virtuelles et pas de virtuel les classes de base,
    • (3.3) a le même contrôle d'accès pour tous les non-membres de données statiques,
    • (3.4) n'a pas non standard-layout classes de base,
    • (3.5) a au plus une classe de base sous-objet de tout type,
    • (3.6) a tous les non-membres de données statiques et peu-champs dans la classe et de ses classes de base d'abord déclaré dans la même classe, et
    • (3.7) n'a pas d'élément de l'ensemble M(S) de types comme une classe de base, où pour tout type X, M(X) est définie comme suit.104
      [ Note: M(X) est l'ensemble des types de tous les non-de la classe de base sous-objets qui peuvent être à un décalage de zéro en X.
      — la note de fin de
      ]

      • (3.7.1) Si X est un non-union type de classe avec pas (peut être héritées) non-membres de données statiques, l'ensemble M(X) est vide.
      • (3.7.2) Si X est un non-union type de classe avec un non-membre de données statiques de type X0 qui est de la taille de zéro ou est la première
        non-membre de données statiques de X (où ledit membre peut être anonyme
        de l'union), l'ensemble M(X) se compose de X0 et les éléments de M(X0).
      • (3.7.3) Si X est un type d'union, l'ensemble M(X) est l'union de tous les M(Ui) et l'ensemble contenant l'ensemble de l'Interface utilisateur, où chaque Ui est le type de la
        ith non-membre de données statiques de X.
      • (3.7.4) Si X est un tableau de type avec le type d'élément Xe, l'ensemble M(X) se compose de Xe et les éléments de M(Xe).
      • (3.7.5) Si X est un non-classe, non-type de tableau, l'ensemble M(X) est vide.
    • Il y a une proposition visant à permettre aux agrégats d'avoir une classe de base tant qu'il est par défaut constructable voir N4404
    • alors que le POD peut rester la même, C++14 StandardLayoutType, qui est une exigence pour le POD, a changé selon cppref: en.cppreference.com/w/cpp/named_req/StandardLayoutType
    • merci, je ne sais pas comment je l'ai raté, je vais essayer de mettre à jour dans les prochains jours.
    • Laissez-moi savoir si vous pouvez venir avec un exemple qui est POD en C++14, mais pas en C++11 🙂 j'ai commencé une liste détaillée des exemples: stackoverflow.com/questions/146452/what-are-pod-types-in-c/...
    • donc ce qui s'est passé ici est de savoir si nous regardons le standard-layout description dans C++11 et C++14 elles correspondent. Ces changements là où elle est appliquée par des rapports de défaut en C++14. Alors, quand j'ai écrit cela à l'origine, c'était bon :-p
    InformationsquelleAutor Shafik Yaghmour
  4. 44

    pouvez vous s'il vous plaît élaborer des règles suivantes:

    Je vais essayer:

    a) standard-layout classes doivent avoir tous les non-membres de données statiques avec le même contrôle d'accès

    C'est simple: tous les non-membres de données statiques doivent tous être public, private, ou protected. Vous ne pouvez pas avoir certains public et certains private.

    Le raisonnement pour eux va pour le raisonnement pour avoir une distinction entre le "modèle standard" et "pas de mise en page standard" à tous. À savoir, donner le compilateur de la liberté de choisir la façon de mettre les choses en mémoire. Ce n'est pas seulement à propos de vtable des pointeurs.

    En arrière quand ils normalisée C++ en 98, ils avaient pour l'essentiel à prédire comment les gens allaient le mettre en œuvre. Alors qu'ils avaient tout à fait un peu de mise en œuvre de l'expérience avec les différentes versions de C++, ils n'étaient pas certaines choses. Ils ont donc décidé de faire preuve de prudence: donner les compilateurs autant de liberté que possible.

    C'est pourquoi la définition de la POD en C++98 est aussi stricte. Il a donné des compilateurs C++ d'une grande latitude aux etats de mise en page pour la plupart des classes. Fondamentalement, POD types étaient destinés à être des cas particuliers, quelque chose que vous spécifiquement écrit pour une raison.

    Quand C++11 est en cours d'élaboration, ils avaient beaucoup plus d'expérience avec les compilateurs. Et ils se sont rendu compte que... compilateur C++ les écrivains sont vraiment paresseux. Ils avaient tous cette liberté, mais ils n'ont pas ne quelque chose avec elle.

    Les règles de mise en page standard, sont plus ou moins la codification de la pratique courante: la plupart des compilateurs n'ont pas à changer grand-chose, sinon rien du tout pour les mettre en œuvre (en dehors peut-être quelques trucs pour le type correspondant traits).

    Maintenant, quand il est venu à public/private, les choses sont différentes. La liberté de réorganiser les membres public vs private en fait peut importe pour le compilateur, en particulier dans le débogage de builds. Et depuis le point de standard de mise en page est qu'il y a la compatibilité avec d'autres langues, vous ne pouvez pas avoir la mise en page différents dans le debug vs libération.

    Ensuite, il ya le fait qu'il n'a pas vraiment de mal à l'utilisateur. Si vous effectuez un encapsulé classe, les chances sont bonnes que toutes vos données membres seront private de toute façon. Vous n'avez généralement pas exposer les données publiques des membres entièrement encapsulé types. Donc, ce ne serait qu'un problème pour les quelques utilisateurs qui ne veulent faire, qui veulent que la division.

    Donc c'est pas une grosse perte.

    b) d'une seule classe dans l'ensemble de l'arbre d'héritage peuvent avoir des non-membres de données statiques,

    La raison pour cela on en revient à la raison normalisé standard de mise en page nouveau: pratique courante.

    Il y a pas pratique courante quand il s'agit d'avoir deux membres d'un arbre d'héritage qui en fait stocker des choses. Certains mettent de la classe de base avant de la dérivée, d'autres le font dans l'autre sens. De quelle manière avez-vous les membres s'ils sont issus de deux classes de base? Et ainsi de suite. Les compilateurs divergent grandement sur ces questions.

    Aussi, grâce à la zéro/un/l'infini de la règle, une fois que vous dites que vous pouvez avoir deux classes avec les membres, vous pouvez dire autant que vous le souhaitez. Cela nécessite l'ajout d'un grand nombre de règles de présentation pour savoir comment gérer cela. Que vous avez à dire comment l'héritage multiple, les œuvres, les classes qui mettent leurs données avant d'autres classes, etc. C'est beaucoup de règles, pour très peu de gain matériel.

    Vous ne pouvez pas faire tout ce qui ne disposent pas de fonctions virtuelles et un constructeur par défaut de mise en page standard.

    et le premier non-membre de données statiques ne peuvent pas être d'une classe de base type (cela pourrait briser aliasing règles).

    Je ne peux pas vraiment parler de celui-ci. Je ne suis pas suffisamment instruits en C++de l'aliasing règles de vraiment les comprendre. Mais il a quelque chose à voir avec le fait que la base de membres partagent la même adresse que la classe de base lui-même. Qui est:

    struct Base {};
struct Derived : Base { Base b; };
Derived d;
static_cast<Base*>(&d) == &d.b;

    Et c'est probablement contre C++aliasing règles. D'une certaine façon.

    Cependant, pensez à ceci: quelle utilité pourrait avoir la capacité de faire cela jamais fait être? Depuis seulement une classe peut avoir des non-membres de données statiques, puis Derived doit être la classe (car il a une Base en tant que membre). Donc Base doit être vide (de données). Et si Base est vide, ainsi que une classe de base... pourquoi un membre de données de tout?

    Depuis Base est vide, il n'a pas d'état. De sorte que toute non-fonctions membres statiques vont faire ce qu'ils en fonction de leurs paramètres, de ne pas leur this pointeur.

    Donc encore une fois: pas de grosse perte.

    • Merci pour l'explication, ça aide beaucoup. Probablement en dépit de static_cast<Base*>(&d) et &d.b sont les mêmes Base* type, ils ont des points à des choses différentes et de briser ainsi le crénelage de la règle. Merci de me corriger.
    • et, pourquoi si une seule classe peut avoir des non-membres de données statiques, puis Derived doit être la classe?
    • Pour Derived's premier membre à sa classe de base, il faut deux choses: une classe de base, et d'un membre. Et depuis une seule classe dans la hiérarchie peut avoir des membres (et des standard-layout), ce qui signifie que sa classe de base ne peut pas avoir des membres.
    • Ouais, vous êtes essentiellement correcte, IME, à propos de l'aliasing à la règle. Deux différentes instances d'un même type sont nécessaires à différentes adresses de la mémoire. (Cela permet à l'identité de l'objet d'un suivi avec des adresses de mémoire.) L'objet de base et le premier membre dérivé sont des instances différentes, donc ils doivent avoir des adresses différentes, dont les forces de rembourrage pour être ajouté, affectant la classe de mise en page. S'ils sont de types différents, il ne serait pas question; les objets avec différents types sont autorisés à avoir la même adresse (une classe et son premier membre de données, par exemple).
    InformationsquelleAutor Nicol Bolas
  5. 36

    Changements en C++17

    Télécharger le C++17 projet final de Norme Internationale ici.

    Agrégats

    C++17 se développe et améliore des agrégats et granulats d'initialisation. La bibliothèque standard comprend également un std::is_aggregate type de trait de classe. Voici la définition officielle de la section 11.6.1.1 et 11.6.1.2 (références internes élidée):

    Un agrégat est un tableau ou une classe avec

    — non fourni par l'utilisateur, explicite ou héritées des constructeurs,

    — pas privés ou protégés non-membres de données statiques,

    — pas de fonctions virtuelles, et

    — pas de virtuel, privé ou protégé des classes de base.

    [ Note: l'Agrégat de l'initialisation de ne pas permettre l'accès privé et protégé de la classe de base des membres ou des constructeurs. —fin de la remarque ]

    Les éléments d'un ensemble sont les suivants:

    — pour un tableau, les éléments du tableau dans l'augmentation de l'indice de l'ordre, ou

    — pour une classe, la classe de base dans l'ordre de déclaration, suivie par les non-membres de données statiques qui ne sont pas membres d'un anonyme de l'union, dans l'ordre de déclaration.

    Ce qui a changé?

    1. Agrégats peuvent maintenant avoir du public, non-virtuelle classes de base. En outre, il n'est pas une exigence de la base de classes d'agrégats. Si elles ne sont pas des agrégats, ils sont la liste d'initialisation.
    struct B1 //not a aggregate
{
int i1;
B1(int a) : i1(a) { }
};
struct B2
{
int i2;
B2() = default;
};
struct M //not an aggregate
{
int m;
M(int a) : m(a) { }
};
struct C : B1, B2
{
int j;
M m;
C() = default;
};
C c { { 1 }, { 2 }, 3, { 4 } };
cout
<< "is C aggregate?: " << (std::is_aggregate<C>::value ? 'Y' : 'N')
<< " i1: " << c.i1 << " i2: " << c.i2
<< " j: " << c.j << " m.m: " << c.m.m << endl;
//stdout: is C aggregate?: Y, i1=1 i2=2 j=3 m.m=4
    1. Explicite par défaut des constructeurs sont interdits
    struct D //not an aggregate
{
int i = 0;
D() = default;
explicit D(D const&) = default;
};
    1. Hériter constructeurs sont interdits
    struct B1
{
int i1;
B1() : i1(0) { }
};
struct C : B1 //not an aggregate
{
using B1::B1;
};


    Trivial Classes

    La définition de trivial classe a été retravaillée en C++17 à l'adresse de plusieurs défauts qui n'ont pas été abordées dans le C++14. Les modifications sont de nature technique. Voici la nouvelle définition au 12.0.6 (références internes élidée):

    Un trivialement copiable classe est une classe:

    — où chaque constructeur de copie, constructeur de déplacement, de copie opérateur d'assignation, et l'opérateur d'assignation de déplacement soit supprimé ou trivial,

    — qui a au moins un non-supprimé constructeur de copie, constructeur de déplacement, de copie opérateur d'affectation, ou de déplacer l'opérateur d'affectation, et

    — qui a un trivial, non supprimés destructeur.

    Un trivial classe est une classe qui est trivialement copiable et a un ou plusieurs constructeurs par défaut, qui sont soit trivial ou supprimés, et au moins un qui n'est pas supprimé. [ Note: En particulier, un trivialement copiable
    ou trivial de classe n'ont pas de fonctions virtuelles ou virtuel classes de base.—la note de fin ]

    Changements:

    1. Sous C++14, pour une classe d'être anodine, la classe ne peut avoir aucune copier/déplacer constructeur/l'affectation des opérateurs qui ont été non-trivial. Cependant, alors implicitement déclaré en tant que par défaut constructeur/opérateur pourrait être non négligeable et pourtant défini comme supprimé parce que, par exemple, la classe contenait un sous-objet de type classe qui n'a pas pu être copié/déplacé. La présence de ces non-trivial, défini comme supprimé constructeur/opérateur serait la cause de l'ensemble de la classe pour être non négligeable. Un problème similaire existe avec des destructeurs. C++17 précise que la présence d'un tel constructeur/opérateurs n'est pas la cause de la classe non-trivialement copiable, donc non négligeable, et qu'un trivialement copiable classe doit avoir un trivial, non supprimés destructeur. DR1734, DR1928
    2. C++14 permis à un trivialement copiable classe, donc trivial de classe, d'avoir tous les copier/déplacer constructeur/opérateur d'affectation déclaré comme étant supprimés. Si comme la classe a été également mise en page standard, il pourrait, cependant, être légalement copié/déplacé avec std::memcpy. C'était une sémantique de contradiction, parce que, par définition comme supprimé tous les constructeur/opérateurs d'affectation, le créateur de la classe clairement prévu que la classe n'a pas pu être copié/déplacé, mais la classe quand même de rencontrer la définition d'un trivialement copiable classe. Donc en C++17, nous avons une nouvelle clause stipulant que trivialement copiable classe doit avoir au moins un trivial, non supprimés (mais pas forcément accessible au public) copier/déplacer constructeur/opérateur d'affectation. Voir N4148, DR1734
    3. La troisième techniques changement concerne un problème similaire avec des constructeurs par défaut. En vertu de C++14, une classe pourrait avoir trivial constructeurs par défaut qui sont implicitement défini comme étant supprimés, mais encore d'être trivial de classe. La nouvelle définition précise qu'un trivial classe doit avoir au moins un trivial, non supprimés constructeur par défaut. Voir DR1496

    Standard-layout Classes

    La définition de la norme de mise a également été retravaillé à l'adresse des rapports de défaut. De nouveau, les changements étaient de nature technique. Voici le texte de la norme (12.0.7). Comme auparavant, les références internes sont gommés:

    Une classe S est un standard-classe de mise en page si:

    — n'a pas non données membres statiques de type non-standard-classe de mise en page (ou un tableau de ce type) ou de référence,

    — n'a pas de fonctions virtuelles et pas de virtuel les classes de base

    — a la même contrôle d'accès pour tous les non-membres de données statiques,

    — n'a pas non standard-layout classes de base

    — a au plus une classe de base sous-objet de tout type,

    — a tous les non-membres de données statiques et peu-champs dans la classe et de ses classes de base d'abord déclaré dans la même classe, et

    — n'a pas d'élément de l'ensemble M(S) de types (défini ci-dessous) comme une classe de base.108

    M(X) est définie comme suit:

    — Si X est un non-union type de classe avec pas (peut être héritées) non-membres de données statiques, l'ensemble M(X) est vide.

    — Si X est un non-union type de classe dont le premier non-membre de données statiques de type X0 (où ledit membre peut être un anonyme de l'union), l'ensemble M(X) se compose de X0 et les éléments de M(X0).

    — Si X est un type d'union, l'ensemble M(X) est l'union de tous les M(Ui) et l'ensemble contenant l'ensemble de l'Interface utilisateur, où chaque Ui est le type de la ie non-membre de données statiques de X.

    — Si X est une matrice de type avec le type d'élément Xe, l'ensemble M(X) se compose de Xe et les éléments de M(Xe).

    — Si X est un non-classe, non-type de tableau, l'ensemble M(X) est vide.

    [ Note: M(X) est l'ensemble des types de tous les non-de la classe de base sous-objets qui lui sont garantis par un standard-classe de mise en page pour être à un décalage de zéro en X. —la note de fin ]

    [ Exemple:

    struct B { int i; }; //standard-layout class
struct C : B { }; //standard-layout class
struct D : C { }; //standard-layout class
struct E : D { char : 4; }; //not a standard-layout class
struct Q {};
struct S : Q { };
struct T : Q { };
struct U : S, T { }; //not a standard-layout class

    fin de l'exemple ]

    108) Cela garantit que les deux sous-objets qui ont le même type de classe et qui appartiennent au même objet dérivé ne sont pas attribués à la même adresse.

    Changements:

    1. A précisé que l'exigence d'une seule classe dans l'arbre de dérivation "a" non-statique membres de données fait référence à une classe, lorsque de telles données sont membres des premières déclaré, et non des classes où ils peuvent être héréditaires, et a étendu cette obligation de non-statique champs de bits. Également précisé que standard-classe de mise en page "a au plus une classe de base sous-objet de tout type." Voir DR1813, DR1881
    2. La définition de standard-layout n'a jamais autorisé le type de la classe de base doit être du même type que le premier non-membre de données statiques. C'est pour éviter une situation où un membre de données au décalage de zéro a le même type que toute la classe de base. Le C++17 norme fournit plus de rigueur, d'définition récursive de "l'ensemble des types de tous les non-de la classe de base sous-objets qui lui sont garantis par un standard-classe de mise en page pour être à un décalage du zéro" afin d'interdire à ces types de être le type de classe de base. Voir DR1672, DR2120.

    Remarque: Le C++ comité des normes prévu les changements ci-dessus basées sur des rapports de défaut à appliquer à C++14, bien que la nouvelle langue n'est pas dans la publication du C++14 standard. C'est dans le C++17 standard.

    • Remarque je viens de mettre à jour ma réponse le modèle standard, les changements de défauts ont CD4 statut ce qui signifie qu'ils sont réellement appliqués à C++14. C'est pourquoi ma réponse n'a pas les inclure b/c ce qui s'est passé après que j'ai écrit ma réponse.
    • Remarque, j'ai commencé un bounty sur cette question.
    • Merci @ShafikYaghmour. Je passerai en revue les rapports de défaut de statut et de modifier ma réponse en conséquence.
    • Génial, laissez-moi savoir quand vous le mettez à jour.
    • Après quelques examen du C++14 processus et il me semble que, bien que ces DRs ont été "accepté" à la session de juin 2014 Rapperswil réunion de la langue à partir de février 2014 Issaquah réunion a été ce qui est devenu le C++14. Voir isocpp.org/blog/2014/07/trip-report-summer-iso-c-meeting "en conformité avec les règles de l'ISO, nous n'avons pas formellement approuver les modifications à la C++, document de travail." Ai-je raté quelque chose?
    • Ils l'ont CD4 statut qui signifie qu'ils doivent s'appliquer en C++14 mode.
    • J'ai ajouté une note sur les rapports de défaut à la fin de ma réponse. Merci pour les points!

    InformationsquelleAutor ThomasMcLeod
  6. 9

    Ce qui va changer pour le C++20

    C'est encore tôt, de sorte que certains de cette réponse pourrait changer dans le futur. Suivant le reste du thème qui ressort de cette question, la signification et l'utilisation des agrégats continue à changer à chaque norme. Il y a plusieurs changements à l'horizon.

    Types de l'utilisateur déclaré constructeurs P1008

    En C++17, ce type est toujours un agrégat:

    struct X {
X() = delete;
};

    Et, par conséquent, X{} encore compile parce que c'est agrégée d'initialisation - pas un constructeur invocation. Voir aussi: Quand un constructeur privé pas un constructeur privé?

    En C++20, la restriction de changement d'exiger:

    pas fourni par l'utilisateur, explicit, ou hérité des constructeurs

    à

    pas déclaré ou hérité des constructeurs

    Cela a été adoptée dans le C++20 du projet de travail. Ni le X ici, ni la C dans la question sera agrégats en C++20.

    Cela fait aussi un effet yo-yo avec l'exemple suivant:

    class A { protected: A() { }; };
struct B : A { B() = default; };
auto x = B{};

    En C++11/14, B était pas un agrégat en raison de la classe de base, de sorte B{} effectue la valeur d'initialisation qui appelle B::B() qui appelle A::A(), à un point où il est accessible. Cela a été bien formé.

    En C++17, B est devenu un agrégat parce que les classes de base ont été autorisés, ce qui fait B{} globale de l'initialisation. Cela nécessite copie de la liste d'initialisation d'un A de {}, mais en dehors du contexte de B, où il n'est pas accessible. En C++17, c'est mal formé (auto x = B(); serait bien tout de même).

    En C++20 maintenant, en raison de la règle ci-dessus changement, B une fois de plus, cesse d'être un agrégat (pas à cause de la classe de base, mais à cause de l'utilisateur déclaré dans le constructeur par défaut - même si c'est par défaut). Donc, on en revient à passer par Bs'constructeur, et ce fragment devient bien formé.

    De l'initialisation d'agrégats à partir d'une mise entre parenthèses de la liste de valeurs P960

    Un problème commun qui se lève, c'est vouloir utiliser emplace()style de constructeurs avec des agrégats:

    struct X { int a, b; };
std::vector<X> xs;
xs.emplace_back(1, 2); //error

    Cela ne fonctionne pas, parce que emplace va essayer de bien effectuer l'initialisation X(1, 2), ce qui n'est pas valide. La solution habituelle est d'ajouter un constructeur à X, mais avec cette proposition (actuellement en train de travailler son chemin à travers la Base), les agrégats efficacement avons synthétisé les constructeurs qui font la bonne chose - et de se comporter comme des constructeurs. Le code ci-dessus va compiler en tant que-est en C++20 (en supposant que cette fonctionnalité soit approuvée, ce qui semble probable).

    Modèle de classe Argument Déduction (CTAD) pour les Agrégats P1021

    En C++17, cela ne compile pas:

    template <typename T>
struct Point {
T x, y;
};
Point p{1, 2}; //error

    Les utilisateurs auraient à écrire leur propre déduction guide pour la totalité des modèles:

    template <typename T> Point(T, T) -> Point<T>;

    Mais comme c'est dans un certain sens, "la chose la plus évidente" à faire, et qui est fondamentalement juste standard, la langue va le faire pour vous. Ce changement a été approuvé par l'Évolution, en novembre 2018, de sorte que l'exemple ci-dessus va probablement compiler en C++20 (sans le besoin de l'utilisateur fourni par déduction guide).

    • Bien que j'upvote, il ne se sent un peu tôt pour l'ajout de cette, je ne connais rien d'important à venir vers le bas qui allait changer cela avant le C++2x est fait même si.
    • Oui, sans doute trop tôt. Mais étant donné que le dd était la date limite pour les nouvelles fonctionnalités de la langue, ce sont les deux seules en vol que je suis au courant de pire des cas je viens de bloc-supprimer l'une de ces sections plus tard? Je viens de voir la question actif avec la générosité et de la pensée, c'était un bon moment à carillon, avant que j'oublie.
    • Je comprends, j'ai été tenté une couple de fois pour des cas similaires. Je m'inquiète toujours quelque chose de majeur va changer et je vais finir par avoir à la réécrire.
    InformationsquelleAutor Barry