Discussion :

[Armulis]

Salut!

J'ai continué ma lecture, et en arrivant au chapitre qui explique comment utiliser des "classes" en C++, je n'ai pas pu m'empêcher de penser sans arrêt aux structures.

Apparemment, les classes sont plus complètes que les structures: on peut gérer l'encapsulation (public/private), y ajouter des fonctions...

Concrètement, mes questions sont les suivantes:
- Est-ce que les classes sont au C++ ce que les structures sont au C (sachant que les classes ont apparemment des possibilités plus étendues).
- Si dans mes classes, je mettais tout en "public", quelle incidence cela pourrait-il avoir sur mon programme?
- Les fonctions contenues dans mes classes peuvent-elles y être seulement déclarées, et implémentées ailleurs dans le programme? (Ou alors je risque de me retrouver avec des classes hyper-grandes si j'ai un code complexe a y intégrer?)

Merci pour ces petits éclaircissements. Si jamais je vais un peu vite (parce que je suis encore en train de lire), contentez-vous de me le signaler et merci de votre compréhension.

[Ehonn]

Salut

Voici un début de réponse via les entrées de la FAQ

- Est-ce que les classes sont au C++ ce que les structures sont au C (sachant que les classes ont apparemment des possibilités plus étendues).

En C++, class et struct sont quasiment équivalents.
FAQ C++ - Quelle est la différence entre class et struct ?

- Si dans mes classes, je mettais tout en "public", quelle incidence cela pourrait-il avoir sur mon programme?

Tu vas t'attirer les foudres des autres développeurs ^^
Tu vas complexifier l'utilisation de ta classe et si tu veux faire évoluer ta classe sans casser la compatibilité, ça sera plus difficile (voire impossible).
FAQ C++ - Qu'est-ce que l'encapsulation ?

- Les fonctions contenues dans mes classes peuvent-elles y être seulement déclarées, et implémentées ailleurs dans le programme? (Ou alors je risque de me retrouver avec des classes hyper-grandes si j'ai un code complexe a y intégrer?)

Oui, bien sûr
FAQ C++ - Comment structurer ma classe en un fichier .h et un fichier .cpp ?

[r0d]

Quelques précisions supplémentaires (juste une addition au message de Ehonn)

- Est-ce que les classes sont au C++ ce que les structures sont au C (sachant que les classes ont apparemment des possibilités plus étendues).

En fait, classe et structure en c++ c'est la même chose. Seule l'accessibilité par défaut (public/private) change. En revanche, les classes/structs en C++ ça n'a rien à voir avec les structs en C. En C, la notion d'objet (donc héritage, polymorphisme et tout ce qui en découle) n'existe pas. Pas plus que la notion de template. Il est possible de simuler un comportement orienté objet en C, mais il faut passer par des mécanismes "artificiels", non natifs, mais au final ce ne sera jamais vraiment la même chose.

- Si dans mes classes, je mettais tout en "public", quelle incidence cela pourrait-il avoir sur mon programme?

L'incidence d'un tel choix est que tu te priverais d'un outil très puissant de la poo, à savoir l'encapsulation. L'encapsulation a plusieurs avantages. En particulier, cela permet de mieux structurer ton programme. Pour un petit programme de 10 lignes, ça n'a aucun sens. Mais dès que ton programme grandit (et ça va souvent très vite), une bonne encapsulation te permet d'éviter des erreurs, d'ajouter plus rapidement de nouvelles fonctionnalités, d'avoir une meilleure vision du code que tu as déjà écrit, etc.

- Les fonctions contenues dans mes classes peuvent-elles y être seulement déclarées, et implémentées ailleurs dans le programme? (Ou alors je risque de me retrouver avec des classes hyper-grandes si j'ai un code complexe a y intégrer?)

C'est même un des principe de base du c++: les déclarations dans les en-tête (fichier.h), l'implémentation dans le fichier source (fichier.cpp). Avec un bémol, car on ne peut pas vraiment faire ça dans le cas de classes templates.
C'est un principe parfois critiqué (le code d'une classe se retrouve séparé dans 2 fichiers, c'est parfois compliqué pour les programmeurs qui viennent d'autres langages où ce n'est pas le cas), mais ça a de nombreux avantages, dont celui que tu cites.

[koala01]

Salut,

Juste pour rajouter mon grain de sel (et en mettre une couche supplémentaire ):

L'incidence d'un tel choix est que tu te priverais d'un outil très puissant de la poo, à savoir l'encapsulation. L'encapsulation a plusieurs avantages. En particulier, cela permet de mieux structurer ton programme. Pour un petit programme de 10 lignes, ça n'a aucun sens. Mais dès que ton programme grandit (et ça va souvent très vite), une bonne encapsulation te permet d'éviter des erreurs, d'ajouter plus rapidement de nouvelles fonctionnalités, d'avoir une meilleure vision du code que tu as déjà écrit, etc.

Il faut d'ailleurs constater que, même C essaye d'apporter une certaine encapsualtion...

C'est beaucoup moins évident qu'en C++, où la notion d'encapsulation vient "naturellement" avec le paradigme orienté objets, mais c'est néanmoins faisable. Prend, par exemple, la structure FILE dont on ne sait absolument rien, à part les fonctions qui la manipulent .

C++ t'offre la possibilité d'encapsuler les données de manière simple et efficace, il serai dommage de ne pas le faire même si une classe dans laquelle tout serait public serait strictement à équivalent à une structure utilisant sa visibilité par défaut et contenant les même données (et inversément une structure où tout serait privé serait strictement équivalent à une classe utilisant sa visibilité par défaut et contenant les mêmes données, bien que cela n'aurait pas beaucoup de sens )

[bayaola93]

au fait en c++ la classe est ce qu'est la structure en c, mais faut noter que en c++ on peut dire ''class = struct'' et si tu met tout en public dans ta classe et surtout les attributs croit moi tu auras plus d'ennemis que de programmeurs qui font du c++ sur terre donc pas touche a ce niveau: méthodes en public et attributs en private.

[germinolegrand]

au fait en c++ la classe est ce qu'est la structure en c, mais faut noter que en c++ on peut dire ''class = struct'' et si tu met tout en public dans ta classe et surtout les attributs croit moi tu auras plus d'ennemis que de programmeurs qui font du c++ sur terre donc pas touche a ce niveau: méthodes en public et attributs en private.

Balivernes, mettre des attributs en public n'est pas plus idiot que mettre des méthodes en private. Se priver systématiquement de le faire lorsque cela est possible/utile, voilà la véritable erreur.

[moldavi]

Bonjour.

La différence essentielle en C++ entre une structure et une classe (hormis l'aspect public/private), c'est que l'on peut aligner (niveau mémoire) une structure, mais pas une classe. C'est utile lorsque l'on veut optimiser son code, ou lorsque l'on mélange code c++ et code assembleur (l'asssembleur nécessite en général un alignement mémoire des données).

croit moi tu auras plus d'ennemis que de programmeurs qui font du c++ sur terre donc pas touche a ce niveau: méthodes en public et attributs en private.

Je rejoins germinolegrand, en C++ on utilise une structure quand c'est judicieux, et une classe quand c'est judicieux. Les développeurs C++ n'ont jamais aboli l'utilisation de structure au profit de classe.

Je pense que tu fais référence aux débats qui disent de toujours protéger les variables membres d'une classe C++ par un accesseur. Cela n'a rien à voir avec le débat structure/classe.

[germinolegrand]

on peut aligner (niveau mémoire) une structure, mais pas une classe.

J'aimerais beaucoup voir le passage de la norme qui certifie une telle chose...

[moldavi]

J'aimerais beaucoup voir le passage de la norme qui certifie une telle chose...

Je ne connaît pas le norme à ce sujet, mais la pratique est éloquente :

http://msdn.microsoft.com/fr-fr/libr.../83ythb65.aspx

Cela ne parle que de structure, jamais de classe. Cela me paraît logique, on ne peut aligner que des données dont la taille est connue à la compilation, pas des fonctions. Fonctions qui peuvent allouer des tableaux de tailles variables. C'est donc c'est imprédictible par le compilateur et par le runtime.

Certes une structure peut contenir des fonctions, je n'ai pas poussé plus loin la chose. Je parle bien dans le cas de structure de données pures.

Et une structure qui sert de foncteur ne sera pas destinée à être alignée niveau mémoire, en général.

Après, une classe qui ne contient que des données publiques, sans accesseurs/fonctions, sera certainement alignables en mémoire... Une structure quoi.

[germinolegrand]

Les fonctions membres d'une struct/class n'influent en rien sur la taille en mémoire de celle-ci... cela ne peut donc influencer l'alignement de quelconque manière. Ce serait d'ailleurs une perte énorme si les classes avec des centaines de fonction étaient plus lourdes .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct A
{
    int i;
 
    int f();
};

c'est la même chose que ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct A
{
    int i;
};
 
int f(A* this_ptr);

Cela ne parle que de structure, jamais de classe.

Et pour cause... c'est strictement la même chose, pourquoi faire deux fois les mêmes exemples ? D'ailleurs si, ça parle de classe :

Vous pouvez utiliser __declspec(align(#)) lorsque vous définissez struct, union, ou class, ou lorsque vous déclarez une variable.

[moldavi]

En effet ce code compile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
__declspec(align(8)) class S2 { int a, b, c, d; void test(const int to){ int* t = new int[to]; } };
 
void main(){
 
  S2 test;
}

Mais bon, le compilateur peut aligner a, b, c, d. Mais comment peut-il aligner t ? Il ne connaît pas sa taille.

[germinolegrand]

D'une part ton code montre une alloc dynamique qui se fait sur le tas donc tout ce que ça prend sur la pile c'est la taille d'un pointeur.

D'autre part, ainsi que je l'ai dit plus haut, la fonction (et encore moins son corps) n'appartient pas à la classe, c'est juste une fonction qui prend un paramètre this caché et qui est a accès aux private, en clair c'est purement du sucre syntaxique.

[JolyLoic]

Les fonctions membres d'une struct/class n'influent en rien sur la taille en mémoire de celle-ci... cela ne peut donc influencer l'alignement de quelconque manière.

Léger bémol (mais je suis d'accord avec le reste) : La première fonction virtuelle d'une classe va modifier la taille des instances de cette classe (typiquement pour y ajouter un pointeur caché vers une table de fonctions virtuelles).

Sinon, pour savoir à quoi va ressembler une classe en mémoire, il faut qu'elle soit "standard layout" :

A standard-layout class is a class that:
— has no non-static data members of type non-standard-layout class (or array of such types) or reference,
— has no virtual functions (10.3) and no virtual base classes (10.1),
— has the same access control (Clause 11) for all non-static data members,
— has no non-standard-layout base classes,
— either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and
— has no base classes of the same type as the first non-static data member.108

[moldavi]

Prenons un cas pratique. Une fonction assembleur attends des datas qui sont alignées.

Une fonction d'une classe ne peut pas prétendre à cela (confère l'allocation dynamique). Une structure le peut, ou une classe aussi, qui se comporte comme une structure... ou comme une classe c'est selon.

Enfin, ce que je dis c'est que pour aligner des données on utilise des structures, pas des classes. C'est une différence entre struture /classe en C++, que j'ai voulu souligner dans ce débat.

Merci d'avoir précisé qu'on peut aussi aligner une classe. Même si je pense que cela doit être d'une utilisation marginale, dont on ne trouve aucun code source sur internet...

[koala01]

on peut aligner (niveau mémoire) une structure, mais pas une classe.

J'aimerais beaucoup voir le passage de la norme qui certifie une telle chose...

Tu peux toujours le chercher... il n'existe pas

[Bousk]

La seule "explication" que j'y verrai c'est qu'en général ce qu'on aligne ce sont des POD, et pour faire un POD classiquement on utilisera une struct.

Mais ça n'a absolument rien d'une règle, je peux faire un équivalent strict à ma structure POD avec une classe.

Une fonction d'une classe ne peut pas prétendre à cela (confère l'allocation dynamique).

Ha ? Pourquoi ?
Quel rapport entre l'allocation dynamique et l'alignement ?
On peut avoir une structure correctement alignée qui ne fasse que stockage de pointeurs.

[koala01]

Je ne connaît pas le norme à ce sujet, mais la pratique est éloquente :

http://msdn.microsoft.com/fr-fr/libr.../83ythb65.aspx

Cela ne parle que de structure, jamais de classe.

Ouh là...

Il faut se méfier des documentations, et c'en est un exemple flagrant.

Déjà, il faut se rappeler que tout ce qui commence par un (ou deux) underscore "_" est "implementation specific", c'est à dire spécifique à un compilateur donné.

cet article traitant de __declspec(align), de __alignof et __unalinged, nous sommes clairement en présence d'un article présentant une spécificité propre à visual studio.

De plus, il faut faire la part des choses des articles traitant du mot clé struct d'une part et des "strctures de données définies par l'utilisateur" dans leur ensemble d'autre part.

Les "structures de données définies par l'utilisateur" (on parle souvent de "type défini par l'utilisateur ) dans leur ensemble peuvent être de trois type (si on excepte le typedef ou l'alias de type, quel que soit le langage utilisé):

1. les struct
2. les class
3. les union

La première ligne de l'article précise qu'il parle de la

précision l'alignement des données définies par l'utilisateur

C'est donc bel et bien un article qui parle de l'alignement des données de "toute structure définie par l'utilisateur" dans leur ensemble

Cela me paraît logique, on ne peut aligner que des données dont la taille est connue à la compilation,

En effet, il n'est possible d'aligner en mémoire que ce dont la taille est connue à la compilation...

Mais...

pas des fonctions.

Faux: la taille d'une fonction est parfaitement connue à la compilation

Ce que l'article dit, c'est qu'on ne peut pas aligner les arguments en mémoire, et la raison n'a rien à voir avec le fait que c'est quelque chose propre à une fonction, mais bien au fait que le argument ne finissent pas en mémoire, mais dans la pile d'appel (qui est, techniquement parlant, de la mémoire, mais qui n'a rien à voir avec la mémoire "RAM").

Meme les

Fonctions qui peuvent allouer des tableaux de tailles variables.

ont une taille clairement définie à la compilation.

Autrement, le compilateur serait incapable de placer plus de deux fonctions dans le code binaire exécutable généré.

Ce qui reçoit le résultat de l'allocation dynamique, c'est un pointeur!

si l'on ne peut effectivement pas prévoir la taille en mémoire de qui sera effectivement réservée par l'allocation dynamique, on connait par contre parfaitement la taille de ce qui récupérera le résultat de cette allocation dynamique: ce sera la taille d'un pointeur.

Et, quel que soit le type pointé par un pointeur, la taille d'un pointeur est parfaitement connue à la compilation

C'est donc c'est imprédictible par le compilateur et par le runtime.

Ben non (cf juste au dessus )

L'allocation dynamique se résume au final à un appel système, car c'est carrément le système d'exploitation qui doit gérer la mémoire allouée dynamiquement (pour éviter que deux applications distinctes ne se retrouvent à travailler sur des adresses mémoires identiques), mais le résultat est parfaitement prédictible au niveau de la fonction qui y a recours: Ce que l'on obtient, c'est l'adresse mémoire à laquelle se trouve le premier byte alloué

Certes une structure peut contenir des fonctions, je n'ai pas poussé plus loin la chose. Je parle bien dans le cas de structure de données pures.

Que l'on parle de structure de données"pures" ou de contenant des fonction en plus des données membres, cela ne change strictement rien...

Les fonctions membres de classes et de structures sont, au niveau du code binaire exécutable généré, strictement assimilées à des fonctions libres.

La seule chose, c'est que le compilateur y ajoute silencieusement un pointeur sur l'objet courent (this) et se débrouille avec cela pour retrouver les différents membres (qu'il s'agisse de données membres ou d'autres fonctions membres )

Et une structure qui sert de foncteur ne sera pas destinée à être alignée niveau mémoire, en général.

En effet, mais pour une raison tout autre, et dans un cas bien particulier: celui dans lequel ton foncteur ne disposerait d'aucune donnée membre (tout serait passé par l'opérateur () ).

Dans ce cas, la structure correspondante serait une structure vide, qui est garantie par la norme être de taille nulle.

Mais, la particularité d'un foncteur n'est pas de ne pas avoir de données membres, c'est, avant tout, de ne présenter qu'une seule fonction qui est... l'opérateur () !

et comme tout type ayant sémantique de valeur doit respecter la forme canonique orthodoxe de coplien, le fait d'y rajouter un constructeur (par exemple) ne changera rien car le compilateur le rajouterait automatiquement si on ne le faisait pas nous même

Il m'arrive, par exemple, régulièrement de créer des foncteurs (composés du seul opérateur () ) auquel je rajoute des données membres et un constructeur

Après, une classe qui ne contient que des données publiques, sans accesseurs/fonctions, sera certainement alignables en mémoire... Une structure quoi.

Toutes les structures de données doivent être alignables en mémoire. C'est un impératif matériel:

Il faut impérativement que le compilateur puisse accéder à l'adresse mémoire à laquelle se trouve le premier byte correspondant à la structure de données en question.

Le fait que ce soit une classe, une structure ou même une union (dont la seule particularité est que tous les membres utilise le même espace mémoire) ne changera rien

La seule concession qui est faite (sauf si on force le compilateur à faire autrement) concerne les types primitifs dont la taille est "suffisamment petite pour permettre d'en représenter plusieurs dans un accumulateur donné" (typiquement les char et les short, voire les int pour les architectures 64 bits) car, à ce moment là, le compilateur peut décider de travailler sur un "sous registre" de l'accumulateur en question afin d'y accéder.

Et encore, cela doit suivre des règles particulières, dont la principale est qu'il faut que ces soit des données contigües en mémoire et de type identique (par exemple : 3 char successifs ou deux short).
La première donnée de type différent sera (sauf si on force le compilateur à faire autrement, toujours) se retrouvera première adresse accessible par le compilateur suivant l'adresse (non accessible en elle-même) du dernier élément contigü

PS: j'ai bien conscience d'avoir pris des raccourcis, d'avoir simplifié les choses, mais le principe global reste malgré tout correct

[Klaim]

Prenons un cas pratique. Une fonction assembleur attends des datas qui sont alignées.

Une fonction d'une classe ne peut pas prétendre à cela (confère l'allocation dynamique). Une structure le peut, ou une classe aussi, qui se comporte comme une structure... ou comme une classe c'est selon.

Enfin, ce que je dis c'est que pour aligner des données on utilise des structures, pas des classes. C'est une différence entre struture /classe en C++, que j'ai voulu souligner dans ce débat.

Merci d'avoir précisé qu'on peut aussi aligner une classe. Même si je pense que cela doit être d'une utilisation marginale, dont on ne trouve aucun code source sur internet...

Nope.

Tu t'es juste emmêlé les pinceaux. Peut etre en touchant a d'autres langages (je pense a D et C#).

Ou alors tu as trop vu de conventions maisons. Dans tous les cas il n'y a pas de debat et class/struct n'a rien a voir avec l'alignement. Parcequ'il n'y a pas de différence entre struct et class autre que les niveaux acces a la compilation. Certains utilisent struct comme une convention pour dire "donnee brute" mais ce n'est qu'une convention et qui en fait n'est qu'un racourcis pour une class aux membres publiques.

Est-ce que tu peux nous dire si tu te souviens ou tu as eu cette info erronée?

Au passage: le C++ n'est defini QUE par la norme, le document standard ISO. Ce n'est pas parceque ton compilateur marche d'une facon que les autres font pareil et que ca corresponds au standard (malheureusement). Quand tu te demandes si un truc est possible, verifier avec le compilateur est une bonne chose, mais verifier ce que dis la norme est beaucoup mieu parcequ'a ce moment la tu apprends la veritee qui doit etre quel que soit le compilateur "en theorie".

[koala01]

Prenons un cas pratique. Une fonction assembleur attends des datas qui sont alignées.

Oui, parce que c'est une contrainte matérielle.

Le processeur ne peut accéder au donnée que s'il dispose d'une adresse qui correspond au premier bit de cette donnée

Une fonction d'une classe ne peut pas prétendre à cela (confère l'allocation dynamique). Une structure le peut, ou une classe aussi, qui se comporte comme une structure... ou comme une classe c'est selon.

Non!!

S'il est vrai que tu ne peux pas (forcément) déterminer à la compilation la taille totale qui sera réservée lors d'une allocation dynamique de la mémoire, tu as cependant une certitude garantie:

L'espace mémoire alloué sera suffisant pour permettre de représenter le nombre de données demandé de manière contigüe en faisant en sorte que chaque donnée soit dispose d'une adresse accessible par le processeur.

C'est, encore une fois, un impératif matériel (car, autrement, le processeur ne pourrait pas accéder à toutes les données) et c'est amplement suffisant pour apporter la prédictibilité voulue.

En effet, si tu souhaites accéder au troisième élément, il te "suffit" de prendre la première adresse mémoire accessible qui se trouve à trois fois la taille de chaque élément, en partant de l'adresse mémoire du premier.

Le fait qu'il y ait 3, 5 ou 10 éléments n'importe pas ici, et c'est bien la cause de tous les problèmes liés au fait d'essayer d'accéder au onzième élément d'un espace mémoire prévu pour en compter 10:

Tu te retrouves alors à une adresse mémoire qui se trouve "à distance suffisante" de l'adresse mémoire du premier élément pour pouvoir prétendre contenir les informations relatives à l'élément, alors que cette adresse mémoire peut contenir strictement n'importe quoi

Mais c'est alors bien plus un problème de logique (le fait de demander "un fois de trop" de décaler l'adresse mémoire à laquelle aller chercher la donnée) qu'autre chose.

Enfin, ce que je dis c'est que pour aligner des données on utilise des structures, pas des classes. C'est une différence entre struture /classe en C++, que j'ai voulu souligner dans ce débat.

Faux!!!

Il n'y a strictement aucune différence en terme d'alignement des données entre une classe et une structure (et l'on pourrait meme parler des énumérations ici).

La seule différence qui existe entre une classe et une structure en C++, c'est l'accessibilité des membres par défaut à considérer au moment de la compilation.

D'autres langages (C#, par exemple) donnent une sémantique différente aux classes et aux structures, de manière à ce qu'une classe soit systématiquement utilisée pour tout type ayant sémantique d'entité et qu'une structure soit systématiquement utilisée pour les types ayant sémantique de valeur.

Mais cela n'empêche absolument pas que les données soient alignées de manière strictement similaire (encore une fois, c'est un impératif matériel! ), ni de décider de déclarer des variables membres dans une accessibilité ou une autre, ni même de décider de déclarer (et de définir) des fonctions dans une accessibilité ou une autre.

Merci d'avoir précisé qu'on peut aussi aligner une classe. Même si je pense que cela doit être d'une utilisation marginale, dont on ne trouve aucun code source sur internet...

Absolument pas... C'est une utilisation classique, normale et nécessaire, quelle que puisse être le langage envisagé, pour la simple et bonne raison que c'est le processeur qui "mène la danse" à ce niveau là, et qu'il doit pouvoir accéder à l'adresse mémoire à laquelle commence n'importe quelle instance de n'importe quel type de donnée (exception faite des types primitifs suffisamment petit pour tenir à plusieurs dans un seul et même accumulateur)

[moldavi]

Bonjour.

Tous ces romans pour moi. J'apprécie.

Si c'est juste pour m'expliquer qu'on peut aligner un pointeur, donc une fonction (enfin son adresse), donc une classe. Alors relisez le commentaire où je montre le code avec un alignement d'une classe...

Absolument pas... C'est une utilisation classique, normale et nécessaire..

J'attends que vous me montriez plein de code qui utilise l'alignement sur une classe, en expliquant l'intérêt. Parce que j'ai beau chercher, je n'en trouve pas (en fait, je pense juste que cela ne sert à rien, et que personne ne l'utilise). Les compilateurs font de l'alignement à l'intérieur des fonctions avec des instructions nop(). Mais je crois que c'est tout.

Certes il y a la norme C++, et il y a aussi l'utilisation de cette norme. Les développeurs n'utilisent que l'alignement de structures (jusqu'à ce que vous me prouviez le contraire, bien sûr).

Cela devient comme une norme implicite...

On aligne des structures, et non pas des classes. Et c'est bien une différence d'utilisation entre une classe et une structure en C++. Seule chose que j'ai voulu souligner. Quand je lis vos commentaires, vous êtes bornés sur l'aspect Norme, et vous avez raison sur cet aspect. Mais il n'y a pas que la Norme C++ dans la vie, il y a aussi l'utilisation de cette Norme par les développeurs.

PS: j'ai dit qu'on ne pouvait pas aligner des classes, c'était une erreur au niveau compilateur en effet, mais que j'ai corrigé lorsque j'ai donné le code qui compile un alignement de classe. Cela ne change pas le raisonnement qu'on utilise des structures pour l'alignement.

PS2: on peut faire de l'alignement dynamique (new align...). Mais c'est résolu à l'exécution, pas à la compilation.

PS3: désolé de ne pas avoir répondu à chacun d'entre vous, la prochaine fois, je prendrai le temps.