Comment lire:
Cet article est assez long. Si vous voulez en savoir plus sur les agrégats et les POD (Plain Old Data), prenez le temps de le lire. Si vous êtes uniquement intéressé par les agrégats, lisez uniquement la première partie. Si vous n'êtes intéressé que par les POD, vous devez d'abord lire la définition, les implications et les exemples d'agrégats, puis vous pouvez passer aux POD, mais je recommanderais toujours de lire la première partie dans son intégralité. La notion d'agrégats est essentielle pour définir les POD. Si vous trouvez des erreurs (même mineures, y compris la grammaire, la stylistique, le formatage, la syntaxe, etc.) veuillez laisser un commentaire, je vais le modifier.
Cette réponse s'applique à C ++ 03. Pour d'autres normes C ++, voir:
Que sont les agrégats et pourquoi ils sont spéciaux
Définition formelle du standard C ++ ( C ++ 03 8.5.1 §1 ) :
Un agrégat est un tableau ou une classe (article 9) sans constructeurs déclarés par l'utilisateur (12.1), sans membres de données non statiques privés ou protégés (article 11), sans classes de base (article 10) et sans fonctions virtuelles (10.3 ).
Alors, OK, analysons cette définition. Tout d'abord, tout tableau est un agrégat. Une classe peut aussi être un agrégat si… attendez! rien n'est dit sur les structures ou les unions, ne peuvent-elles pas être des agrégats? Oui, ils peuvent. En C ++, le terme classfait référence à toutes les classes, structures et unions. Ainsi, une classe (ou struct, ou union) est un agrégat si et seulement si elle satisfait aux critères des définitions ci-dessus. Qu'impliquent ces critères?
Cela ne signifie pas qu'une classe d'agrégat 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
Aucun membre de données non statique privé ou protégé . Vous pouvez avoir autant de fonctions membres privées et protégées (mais pas de constructeurs) ainsi que autant de membres de données statiques privés ou protégés et de fonctions membres que vous le souhaitez et ne pas enfreindre les règles pour les classes agrégées
Une classe agrégée peut avoir un opérateur et / ou un destructeur d'affectation de copie déclaré / défini par l'utilisateur
Un tableau est un agrégat même s'il s'agit d'un tableau de type 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 avez eu l'idée. Voyons maintenant en quoi 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 connue pour les tableaux, et nous venons d'apprendre qu'il s'agit d'agrégats. Commençons donc avec eux.
Type array_name[n] = {a1, a2, …, am};
si (m == n)
le i ème élément du tableau est initialisé avec un i
sinon si (m <n)
les premiers m éléments du tableau sont initialisés avec un 1 , un 2 ,…, un m et les autresn - méléments sont, si possible, initialisés en valeur (voir ci-dessous pour l'explication du terme)
sinon si (m> n)
le compilateur émettra une erreur
sinon (c'est le cas lorsque n n'est pas spécifié du tout comme int a[] = {1, 2, 3};)
la taille de le tableau (n) est supposé être égal à m,int a[] = {1, 2, 3};estdoncéquivalent àint a[3] = {1, 2, 3};
Quand un objet de type scalaire ( bool, int, char, double, pointeurs, etc.) est la valeur initialisée cela signifie qu'il est initialisé avec 0pour ce type ( falsepour bool, 0.0pour double, etc.). Lorsqu'un objet de type classe avec un constructeur par défaut déclaré par l'utilisateur est initialisé en valeur, son constructeur par défaut est appelé. Si le constructeur par défaut est implicitement défini, tous les membres non statiques sont récursivement initialisés en valeur. Cette définition est imprécise et un peu incorrecte mais elle devrait vous donner l'idée de base. Une référence ne peut pas être initialisée en valeur. L'initialisation de la valeur d'une classe non agrégée peut échouer si, par exemple, la classe n'a pas de constructeur par défaut approprié.
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 accolades. À peu près 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). S'il y a moins d'initialiseurs que de membres, les autres sont initialisés en valeur. S'il est impossible d'initialiser la valeur d'un des membres qui n'ont pas été explicitement initialisés, nous obtenons une erreur au moment de la compilation. S'il y a plus d'initialiseurs que nécessaire, nous obtenons également 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.cest initialisé avec 'a', y.x.i1avec 10, y.x.i2avec 20, y.i[0]avec 20, y.i[1]avec 30et y.fest initialisé en valeur, c'est-à-dire initialisé avec 0.0. Le membre statique protégé dn'est pas du tout initialisé, car il l'est static.
Les unions agrégées sont différentes en ce sens que vous ne pouvez initialiser que leur premier membre avec des accolades. Je pense que si vous êtes suffisamment avancé en C ++ pour même envisager d'utiliser des unions (leur utilisation peut être très dangereuse et doit être réfléchie attentivement), vous pouvez rechercher vous-même les règles pour les unions dans la norme :).
Maintenant que nous savons ce qui est spécial au sujet des agrégats, essayons de comprendre les restrictions sur les classes; c'est pourquoi ils sont là. Nous devons comprendre que l'initialisation des accolades par membre implique que la classe n'est rien de plus que la somme de ses membres. Si un constructeur défini par l'utilisateur est présent, cela signifie que l'utilisateur doit effectuer un travail supplémentaire pour initialiser les membres, donc l'initialisation de l'accolade 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 la soi-disant vtable de la classe, qui est définie dans le constructeur, donc l'initialisation de l'accolade serait insuffisante. Vous pouvez comprendre le reste des restrictions de la même manière qu'un exercice :).
Assez parlé des agrégats. Maintenant, nous pouvons définir un ensemble plus strict de types, à savoir, les POD
Que sont les POD et pourquoi ils sont spéciaux
Définition formelle du standard C ++ ( C ++ 03 9 §4 ) :
Un POD-struct est une classe agrégée qui n'a pas de membres de données non statiques de type non-POD-struct, non-POD-union (ou tableau de ces types) ou référence, et n'a pas d'opérateur d'affectation de copie défini par l'utilisateur et pas destructeur défini par l'utilisateur. De même, une union POD est une union agrégée qui n'a pas de membres de données non statiques de type non-POD-struct, non-POD-union (ou tableau de ces types) ou référence, et n'a pas d'opérateur d'affectation de copie défini par l'utilisateur et aucun destructeur défini par l'utilisateur. Une classe POD est une classe qui est soit une structure POD, soit une union POD.
Wow, celui-ci est plus difficile à analyser, n'est-ce pas? :) Laissons de côté les syndicats (pour les mêmes motifs que ci-dessus) et reformulons de façon un peu plus claire:
Une classe agrégée est appelée POD si elle n'a pas d'opérateur et de destructeur d'affectation de copie définis par l'utilisateur et qu'aucun de ses membres non statiques n'est une classe non POD, un tableau de non-POD ou une référence.
Qu'implique 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, ce n'est certainement pas un POD
- Les classes, tout comme les structures, peuvent être des POD même si le terme standard est POD-struct dans les deux cas
- Tout 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
};
Les classes POD, les unions POD, les types scalaires et les tableaux de ces types sont collectivement appelés types POD.
Les POD sont spéciaux à bien des égards. Je vais vous donner quelques exemples.
Les classes POD sont les plus proches des structures C. Contrairement à eux, les POD peuvent avoir des fonctions membres et des membres statiques arbitraires, mais aucun de ces deux ne modifie 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ée à partir de C et même de .NET, vous devriez essayer de faire en sorte que toutes vos fonctions exportées prennent et retournent uniquement les paramètres des types POD.
La durée de vie des objets de type non POD commence à la fin du constructeur et se termine à la fin du destructeur. Pour les classes POD, la durée de vie commence lorsque le stockage de l'objet est occupé et se termine lorsque ce stockage est libéré ou réutilisé.
Pour les objets de types POD, il est garanti par la norme que lorsque vous mettez memcpyle contenu de votre objet dans un tableau de caractères ou de caractères non signés, puis que memcpyle contenu retourne dans votre objet, l'objet conserve sa valeur d'origine. Notez qu'il n'y a pas de telle garantie pour les objets de types non-POD. Vous pouvez également copier des objets POD en toute sécurité avec memcpy. L'exemple suivant suppose que T est de type POD:
#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 dans la portée à un point où elle est déjà dans la portée. Cette restriction s'applique uniquement si la variable est de type non POD. Dans l'exemple suivant, il f()est mal formé alors qu'il g()est bien formé. Notez que le compilateur de Microsoft est trop libéral avec cette règle - il émet simplement 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 remplissage au début d'un objet POD. En d' autres termes, si un premier élément de POD classe A est de type T, vous pouvez en toute sécurité à reinterpret_castpartir A*de T*et obtenir le pointeur sur le premier membre et vice - versa.
La liste se rallonge de plus en plus…
Conclusion
Il est important de comprendre ce qu'est exactement un POD car de nombreuses fonctionnalités de langage, comme vous le voyez, se comportent différemment pour elles.