Discussion :

[koala01]

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

T est un pointeur et un pointeur n'est jamais qu'une variable numérique entière (généralement) non signée dont la taille est au minimum suffisante pour représenter l'ensemble des adresses mémoire accessibles sur le système.

Et cette taille est clairement connue à la compilation!

On se fout pas mal de savoir que l'adresse mémoire obtenue donne accès à 5, 10 ou 10000 éléments parce que chacun de ces élément est accessible à une adresse mémoire qui lui est propre et que le processeur est tout à fait en mesure de calculer sur la base de l'adresse du premier élément, de la taille des éléments et de l'indice de l'élément auquel on veut accéder.

il y a au maximum trois inconnues au moment de la compilation:

1. L'adresse à laquelle se trouvera le premier élément
2. le nombre d'élément pour lequel l'allocation dynamique demandera de réserver de la mémoire
3. l'indice de l'élément auquel on essayera d'accéder par la suite

Mais cela ne pose strictement aucun problème: on sait que nous obtiendrons de toutes manière une valeur numérique entière non signée (dont la taille est parfaitement connue) correspondant à l'adresse à laquelle nous trouverons un espace contigu suffisant pour représenter l'ensemble des (to) éléments pour lesquels on a demandé de réserver de la mémoire.

Et nous avons la certitude que, le compilateur sachant parfaitement la taille que représente un élément en mémoire, il nous permettra d'accéder à l'ensemble des adresses mémoires auxquelles se trouve le premier byte de chaque élément.

Après, il peut y avoir certains problème:

• Le système peut ne pas trouver assez d'espace libre pour réserver l'espace pour le nombre d'éléments demandé : new va alors lancer une exception de type std::bad_alloc (ou, si on utilise la version nothrow, renvoyer l'adresse correspondant à NULL / nullptr (c++11) pour indiquer que ce n'est pas une adresse valide)
• en ayant demandé d'allouer (to) éléments, on peut essayer d'accéder à l'élément (to)+1 dont l'adresse mémoire peut contenir strictement tout et n'importe quoi. Mais ça, c'est un problème de logique, et ca n'a rien à voir avec l'alignement des données
• d'autres problèmes similaires que j'oublie peut être

sur une classe, en expliquant l'intérêt. Parce que j'ai beau chercher, je n'en trouve pas.

L'intérêt est tout simple : une classe utilise des données pour fournir les services que l'on en attend.

A ce titre, il faut que le processeur soit en mesure d'accéder à ces données, au même titre qu'il doit pouvoir accéder aux différents champs d'une structure ou à n'importe quelle variable de n'importe quel type.

Seulement, si la donnée en question ne se trouve pas dans un des accumulateur du processeur (et bien qu'il y ai de plus en plus d'accumulateurs, il n'y en a pas un nombre extensible à l'infini), il va devoir aller la chercher "quelque part".

Ce "quelque part", correspond à la mémoire: soit une mémoire interne au processeur que l'on appelle "la pile", soit la mémoire générale du système qu'on appelle "le tas".

Pour pouvoir trouver "la donnée qui l'intéresse", il a donc besoin de savoir "où elle se trouve" en mémoire.

Le seul moyen qu'il ait de savoir où la données se trouve passe... par l'adresse mémoire de l'élément en question.

Et cette adresse doit etre accessible au compilateur.

Or, si les accumulateurs sont en mesure de contenir 32 ou 64 bits de données, les adresses accessibles sont toutes séparées par 32 ou 64 bits de données.

Le processeur ne peut accéder au "subdivision" de ces 32 (ou 64) bits qu'une fois que ces 32 (ou 64) bits sont chargés dans un accumulateur (parce que l'accumulateur est, lui-même subdivisé en différentes parties de 8, 16 et éventuellement 32 bits))

si tu ne précise rien et que tu crées une structure proche de

Code :

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

1
2
3
4
struct MyStruct{
    char c;
    int i;
};

le processeur chercher l'adresse à laquelle commence la structure et qui correspondra à l'adresse de c.

pour que le processeur puisse accéder à i, il devra prendre l'adresse (accessible!) qui suit l'adresse de c et, au final, alors qu'un char a une taille de 1 et qu'il aurait donc suffit de 5 bytes pour représenter les deux données, tu te retrouves avec un strcuture ayant une taille de 8, "simplement" parce que le compilateur a rajouté la taille de 3 char 'de bourrage" afin de placer i à une distance qui permette au compilateur d'y accéder.

Ca, c'est ce qu'on appelle l'alignement.

Maintenant, que ce soit une structure ou une classe ne changera rien parce que le processeur devra toujours, à un moment ou à un autre, être en mesure d'accéder aussi bien à i qu'à c.

Il ne faut pas chercher un intérêt quelconque à cela, il faut y voir une obligation propre au style de fonctionnement du processeur!

C'est parce que le processeur a un mode de fonctionnement qui lui empêche d'accéder "facilement" à des données qui ne sont pas séparées par 32 (ou 64) bits que le compilateur s'arrange pour que chaque donnée de type différent se retrouve à une adresse qui sera accessible par le processeur!

Mais, pardon, tu demandes quel serait l'intérêt de modifier la manière dont les données d'une classe seraient alignées

Ce serait exactement le même que celui que tu aurais à modifier la manière dont les données d'une structure sont alignées : "grignoter" quelque bytes en espace mémoire nécessaire.

Je n'y ai personnellement jamais eu recours, mais comme on peut parfaitement utiliser C++ en embarqué et / ou pour programmer des eeprom et/ou des systèmes où le moindre byte de mémoire est important, les occasions de modifier la manière dont les données d'une classe sont alignée sont au moins aussi nombreuses que celle de le faire en C sur pour les structures.

Par contre, l'intérêt de le faire avec des données privées est, bien sur, d'en faciliter l'encapsulation

Certes il y a la norme C++, et il y a aussi l'utilisation de cette norme.

Sauf que la norme est la seule chose qui te permette d'obtenir un résultat pour lequel tu puisse espérer une portabilité totale.

Le fait de jouer avec la manière dont les données sont alignées te fais prendre de très gros risques à ce niveau

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.

Nuance: les développeurs C utilisent que l'alignement de structures. Les pauvres, il n'ont pas d'autre choix

Les développeurs C++ peuvent parfaitement (pour des raisons qui leur sont propres, entre autre de mémoire disponible) utiliser l'alignement sur des classes.

Et, surtout, les développeur C++ qui ont le choix utiliseront l'alignement "par défaut" des données

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.

Non!!! on peut le faire sur tout, même sur une union si tu le souhaites!

Ce n'est pas parce qu'il n'est pas courent de le faire (qu'il s'agisse d'une classe ou d'une structure, je n'ai personnellement jamais éprouvé le besoin de "jouer" avec l'alignement des données ... et je suis sur que beaucoup de développeurs C++ qui ne travaillent pas dans l'embarqué sont dans mon cas ) que cela ne se fait pas.

C'est "simplement" que le besoin est souvent "moins présent"

PS: j'ai dit qu'on ne pouvait pas aligner des classes, c'étatit une erreur 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.

Mais c'est une erreur de taille!!!

Parce que tu avais commencé par dire qu'on ne pouvait pas aligner une classe, ce qui est faux.

Et, en plus, tu présentais cela comme une différence entre les classes et les structures.

Mais comme ton assertion (on ne peut pas aligner des classes) était fausse, on peut difficilement dire qu'il s'agisse d'une différence entre les deux

Du coup, on en revient strictement à la norme : la seule différence qui existe entre une classe et une structure en C++, c'est l'accessibilité par défaut qui est appliquée par le compilateur

[r0d]

[...]une mémoire interne au processeur que l'on appelle "la pile"

Ho. Je croyais que la pile était en RAM. Je n'ai rien lu et je n'ai aucune connaissance sur le sujet, mais ça me semble assez intuitif: la mémoire du proc se résume à quelques registres, or on peut mettre des Go dans la pile non?

[germinolegrand]

Ho. Je croyais que la pile était en RAM. Je n'ai rien lu et je n'ai aucune connaissance sur le sujet, mais ça me semble assez intuitif: la mémoire du proc se résume à quelques registres, or on peut mettre des Go dans la pile non?

Je pense que Koala pensait plutôt au registre esp qui pointe vers la dernière assiette de la pile si je puis me permettre la métaphore
La pile elle-même est bel et bien située dan la ram. (mais je ne suis pas certain que ton OS soit d'accord avec une pile de plusieurs Go )

[Klaim]

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).

Un alignement applique a une struct est un alignement applique a une class qui ne s'appelle pas comme tel. On a pas besoin de te montrer des exemples (tu peux les trouver sur github d'ailleurs) puisque ca reviens EXACTEMENT AU MEME.

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).

Tu realises la difference importante entre ce que le language dis et les conventions arbitraires que s'imposent les gens en entreprises? Tu ne t'es jamais dis que ca pouvait etre different hors de ces entreprises? Sachant qu'ici on parle du langage, les conventions qu'utilisent tel ou tel devs n'ont pas de poids ou de sens ici.

Note aussi que cette convention est partiellement heritee du C, ou struct n'a pas exactement le meme sens, meme si c'est un sens compatible avec une class dont les membres sont publiques.

On aligne des structures, et non pas des classes.

C'est la meme chose. Il n'y a pas a affirmer des choses decidemment fausses.

Note d'ailleurs qu'en 10 ans de carriere pro je n'ai vu cette convention qu'une fois. Dans tous les autres cas, on fait comme on veut (parceque franchement c'est pas important et ca depends des cas)

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.

Tu realises le non sens que tu proposes ici? La norme definis le language, un point c'es tout. Le compilo l'implement aussi bien qu'il peut, et les conventions maisons auquel tu adheres n'ont valeur que dans ta maison. Ellles aident a relire rapidement le meme code de cette maison, mais ca ne veut pas dire que c'est pas different ailleurs (ca l'est, et meme tres tres different).

C'est aussi absurde que de dire qu'on ne dois jamais utiliser de templates: Certes on peut les utiliser parceque la norme le dis, mais les developeurs ont leur propre norme qui dis de ne pas les utiliser. Eh ben chez toi peut etre mais pas chez moi.

[r0d]

Tu realises le non sens que tu proposes ici?

Bah, il ne faut pas être aussi radical. Je ne suis pas choqué quand, par exemple, sur une des millions de discussions sur struct vs class, je lis quelqu'un qui écrit quelque chose du style: "une pratique courante est d'utiliser struct pour des PODs et les foncteurs". Ce n'est pas une différence technique, mais c'est une pratique, donc pourquoi ne pas en parler?

[Klaim]

Parce que ce n'est pas affirme comme tel par moldavi. Alors peut etre que c'est un probleme de communication mais moldavi semble croire fermement que c'est vrai partout, tandis que j'affirme que c'est effectivement une convention commune mais pas utilisee par tous. Ca ne me choque pas non plus tel que tu le dis rod, mais je trouve dangereux (pour les debutants en particulier) de ne pas preciser la difference entre la norme (CE QUI EST VRAI PARTOUT) et une convention (CE QU'ON PREFERE CHEZ NOUS). Affirmer que la convention est plus importante que la norme est dangereux pour l'education des devs (enfin dans mon experience).

[Bousk]

T est un pointeur et un pointeur n'est jamais qu'une variable numérique entière (généralement) non signée dont la taille est au minimum suffisante pour représenter l'ensemble des adresses mémoire accessibles sur le système.

En fait dans son exemple (foireux) T n'est même pas un membre de la classe.
Alors vouloir l'aligner avec a,b,c,d qui sont membres, c'est d'un non sens complet.

[oodini]

J'attends que vous me montriez plein de code qui utilise l'alignement sur une classe, en expliquant l'intérêt.

Le même que celui sur une structure.
Avec ce qui peut parfois être un avantage : l'accès qui est par défaut privé.

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).

Je l'ai encore fait il y a quelques jours pour une déserialisation...

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++. [...] 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.

Sache alors que tes pratiques ne sont pas représentatives ne tous les développeurs.

[moldavi]

Bonjour.

Je vais essayer d''être plus précis dans les choses, il est vrai que j'ai l'impression d'être dans un dialogue de sourds.

On utilise l'alignement de données afin de garantir que les données sont contigües, sans bourrage. On aligne donc des données qu'une fonction assembleur pourra utiliser (c'est un exemple). S'il y a du bourrage, la fonction assembleur ne fonctionnera pas.

Quand j'ai fait l'erreur de dire qu'on ne peut pas aligner une classe, c'était dans le sens où une classe qui contient des fonctions, on ne peut pas aligner ce qu'il y a à l'intérieur des fonctions. On peut aligner le pointeur de la fonction, mais pas ses paramètres et pas le code de la fonction.

http://msdn.microsoft.com/en-us/library/83ythb65.aspx

You cannot specify alignment for function parameters.

Donc quand au départ j'ai dis qu'on ne pouvait pas aligner une classe, c'était avec cette idée là. D'ailleurs quel serait l'intérêt par exemple, de passer le code alignée d'une fonction à une fonction assembleur.

Et pour ceux qui vont me dire que c'est spécifique à Visual Studio, et bien faites-nous part de ce qu'il en est sous Linux ou Mac. On apprendra des choses au moins.

J'ai ensuite corrigé mon erreur en fournissant un code qui compile un alignement de classe. Bien avant toutes vos remarques. Alors comprenez que je prends cela pour de l'archanement .

On a pas besoin de te montrer des exemples (tu peux les trouver sur github d'ailleurs)

Le problème c'est que je n'en trouve pas. Je suis comme Saint-Thomas, je ne crois que ce que je vois.

Pour l'alignement de structure, tu as déjà le lien que j'ai fourni, il y a ffmpeg, libavcodec, openframeworks.

La norme definis le language, un point c'es tout. Le compilo l'implement aussi bien qu'il peut, et les conventions maisons auquel tu adheres n'ont valeur que dans ta maison.

Un point c'est tout...

Le problème c'est que l'alignement de données n'a rien à voir avec la norme du langage. La norme ne définit rien sur l'alignement, une personne l'a précisé dans les messages précédents (on va lui faire confiance).

Donc désolé, je ne vois aucun non-sens dans ce que je dis.

Affirmer que la convention est plus importante que la norme est dangereux pour l'education des devs (enfin dans mon experience).

Je ne crois pas avoir affirmé une telle chose, si c'est le cas mea culpa. D'ailleurs j'ai surtout employé le mot souligner il me semble. J'ai juste souligné une pratique, je ne vois pas en quoi c'est dangereux. De plus, ce dont je parle n'a rien à voir avec la norme...

Je l'ai encore fait il y a quelques jours pour une déserialisation...

Sache alors que tes pratiques ne sont pas représentatives ne tous les développeurs.

Je peux te retourner le même argument. Ce n'est pas parce que tu l'a fais, que c'est courant.

Mais j'attends toujours que vous me montriez du code sur Github, sourceforge et autre.

Je raisonne juste en statisticien. Je ne vois que des codes sources qui utilisent l'alignement de structure, et je comprends aussi pourquoi, alors je le signale sur ce forum comme différence d'utilisation entre struct et classe.

Vous m'opposer la norme, mais la norme n'a rien à voir dans l'alignement.

Quand vous m'aurez fourni suffisamment de lien sur des codes qui utilisent de l'alignement de classe, je réviserai mon jugement, et je ferai mon mea culpa.

[germinolegrand]

La norme C++11 propose le mot clé alignas qui justement traite de l'alignement.

J'ai l'impression que tu crois qu'un objet contient des pointeurs vers les fonctions membres de sa classe... si c'est le cas laisse moi te dire que ce n'est pas le cas (sauf les fonctions virtuelles, mais c'est particulier et propre à la classe et non à l'objet).

Aussi le fait d'aligner une classe ne concerne nullement ses fonctions membres (sauf pour les vtables, mais JolyLoic en a parlé), que ce soit leur adresse ou leur implémentation.

[Klaim]

Bonjour.

Je vais essayer d''être plus précis dans les choses, il est vrai que j'ai l'impression d'être dans un dialogue de sourds.

Il y a effectivement un probleme entre ce que tu dis et ce que tu montres, d'ou un quiproquo du a une mauvaise interpretation, j'y reviens.

On utilise l'alignement de données afin de garantir que les données sont contigües, sans bourrage. On aligne donc des données qu'une fonction assembleur pourra utiliser (c'est un exemple). S'il y a du bourrage, la fonction assembleur ne fonctionnera pas.

Je ne suis pas sur de comprendre ce que tu veux dire la, essentielement parcequ'on parle ici des types, pas des fonctions, a ce que je sache. J'y reviens.

Quand j'ai fait l'erreur de dire qu'on ne peut pas aligner une classe, c'était dans le sens où une classe qui contient des fonctions, on ne peut pas aligner ce qu'il y a à l'intérieur des fonctions. On peut aligner le pointeur de la fonction, mais pas ses paramètres et pas le code de la fonction.

http://msdn.microsoft.com/en-us/library/83ythb65.aspx

You cannot specify alignment for function parameters.

Donc quand au départ j'ai dis cela, c'était avec cette idée là. D'ailleurs quel serait l'intérêt par exemple, de passer le code alignée d'une fonction à une fonction assembleur.

La ligne que tu viens de citer dis que tu ne peux specifier l'alignement des paramettres de fonctions. Ce qui est evident. Et n'a rien a voir avec ce qu'on dis ici (a priori). Ici on parle du fait qu'on puisse preciser l'alignement de types. Les types ne sont pas des instances de type. Les paramettres de fonctions sont des instances de type. Tu peux utilises tes types en paramettres de fonction qu'ils soient ou pas alignes. Ce que tu ne peux pas faire, c'est preciser l'alignement que tu veux au niveau de la signature de fonction. Sous entendu: si tu precises un alignement pour un type, ca dois etre le meme pour toutes les instances de ce type.

Autrement dis, tu parles de quelque chose qui ne marche pas (peut etre que tu ne comprends pas bien le modele de memoire en C++?), mais nous on parle d'autre chose qui marche , a savoir que tu peux preciser l'alignement (quel que soit le compilo, ca depends de la syntaxe fournies ou si ils fournissent alignas() ) d'un type, cela incluant enum, union, class et struct et qu'il n'y a pas de difference du point de vue du compilateur, vu que ce n'est "que" de l'agencement en memoire, ce n'est pas lie a la semantique (ca n'a rien a voir avec la difference entre une class, une struct, une enum ou une union).

Et pour ceux qui vont me dire que c'est spécifique à Visual Studio, et bien faites-nous part de ce qu'il en est sous Linux ou Mac. On apprendra des choses au moins.

Evidemment!
Si tu nous montre le code que tu as teste, je suis certain qu'il n'est pas conforme, d'ou l'erreur.

Un point c'est tout...

Le problème c'est que l'alignement de données n'a rien à voir avec la norme du langage. La norme ne définit rien sur l'alignement, une personne l'a précisé dans les messages précédents (on va lui faire confiance).

Vous m'opposer la norme, mais la norme n'a rien à voir dans l'alignment.

La norme fournis de quoi faire de l'alignment de maniere cross-platform depuis C++11. Oui c'est nouveau. Gcc4.8 l'implement apparament, je pense que VS2012 aussi mais c'est a verifier.
Regarde la http://en.cppreference.com/w/cpp/language/alignas
puis les liens en bas, ya d'autres trucs.

The alignas specifier may be applied to the declaration of a variable or a class data member, or it can be applied to the definition of a class/struct/union or enum.

C'est la norme et les compilateurs la suivent, donc si tu penses qu'une pratique ne marche pas sur des compilateurs mais est bien specifiee par la norme, c'est un "bug" du compilateur (ou une feature controversee mais c'est tres rare).

Le problème c'est que je n'en trouve pas.

Pour l'alignement de structure, tu as déjà le lien que j'ai fourni, il y a ffmpeg, libavcodec, openframeworks. C'es très facile d'en trouver.

Quand vous m'aurez fourni suffisamment de lien sur des codes qui utilisent de l'alignement de classe, je réviserai mon jugement, et je ferai mon mea culpa.

Effectivement les moteurs de recherche de github et autres hosting de code sont vraiment tout pourris.
En plus comme je dis dans la suite, alignas() est recent donc tu en trouves tres peux (dans le code de clang aparamment). Du coup tu dois chercher avec les instructions specifiques aux compilateurs.

Par exemple, si tu cherches avec la syntaxe de gcc pour l'alignement sur 4 bytes, tu vas trouver, parmis un million de bouts de code sur github seulement, ce bout de code qui aligne bien des class et des struct: https://github.com/SRabbelier/Netbea...igned_class.cc

C'est apparament une partie de NetBeans. C'est pas comme si NetBeans etait pas utilise.

La recherche que j'ai fait: https://github.com/search?q=class+__...ults&type=Code

Il n'y a pas ENORMEMENT de code qui aligne des class (par contre yen a pas mal sur les membres de class et les v-table ) mais uniquement par convention. Ca n'a rien a voir avec du code correct et ca n'a rien de bien ou de mal. C'est une habitude, comme souligne precedemment, issue du C.

Je suis sur que tu peux trouver plus d'exemple en cherchant avec les differentes syntaxes des differents compilateurs.

Bref, tout ca pour dire que soit:
- ya un truc que tu sais pas qui te fais penser que C++ marche d'une facon alors que c'est pas le cas, d'ou une sorte de quiproquo;
- on comprends pas ce que tu veux dire, ou tu dis un truc qui n'a pas de sens (la page que tu pointes est eloquente);

Donc probleme de comprehension quelque part.

[moldavi]

J'ai l'impression que tu crois qu'un objet contient des pointeurs vers les fonctions membres de sa classe...

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);

Faudra demander à germinolegrand, lui il l'a spécifié.

[Klaim]

Et donc? Parceque la je vois pas du tout ou tu veux en venir.

[moldavi]

Re.

En plus comme je dis dans la suite, alignas() est recent donc tu en trouves tres peux (dans le code de clang aparamment).

J'ai jeté un oeil sur alignas(). Je dis peut-être une bêtise, mais de ce que j'ai lu, ce n'est qu'un mot-clé. Il n'y à rien de spécifié sur l'alignement. D'ailleurs, pourquoi spécifier que "align", ça doit être de l'alignement sans bourrage. Les compilateurs n'ont pas attendu la norme C++ pour leur spécifier comment on devait aligner des données. C'est juste un mot-clé que chaque compilateur pourra identifier. Ca évitera tous les #ifdef...

La recherche que j'ai fait: https://github.com/search?q=class+__...ults&type=Code

Effectivement, premier lien qui y ressemble. Mais je ne vois qu'une déclaration, pas une utilisation.

Tu me dis que les liens en bas y d'autres trucs. Je dois être naze, j'ai rien trouvé...

[Klaim]

Re.



J'ai jeté un oeil sur alignas(). Je dis peut-être une bêtise, mais de ce que j'ai lu, ce n'est qu'un mot-clé. Il n'y à rien de spécifié sur l'alignement. D'ailleurs, pourquoi spécifier que "align", ça doit être de l'alignement sans bourrage. Les compilateurs n'ont pas attendu la norme C++ pour leur spécifier comment on devait aligner des données. C'est juste un mot-clé que chaque compilateur pourra identifier.

O__o;

Est-ce que tu realises qu'on parle de l'utilisation de ce mot clee (ou de ses equivalent implementes dans chaque compilateur)?
Tu dis que ca n'a rien a voir avec la norme, mais la norme specifie bien de quoi aligner, donc si ca a tout a voir avec la norme (mais la recente seulement), d'ou le mot clee.

Faut vraiment que tu montres un exemple de code dont tu parles sinon on va jamais se comprendre.

Effectivement, premier lien qui y ressemble. Mais je ne vois qu'une déclaration, pas une utilisation.

(tu as du te tromper de liens je pense, celui ci est celui d'alignas, je suppose que tu parlais ce celui ou je montre du code qui aligne une classe...


C'est clair, on parle pas du tout de la meme chose. L'alignement se specifie sur la declaration d'un type ou de ses membres, pas autre part, meme avec les instructions specifiques des compilateurs (sauf fantaisies louches de certaines implementations je pense).

[moldavi]

Oui, je viens juste de corriger le lien. Problème de copier/coller.

Je dis juste que cette norme (de ce que j'ai lu), ne définit qu'un mot-clé. Elle ne dit pas au compilateur comment aligner les données.

D'ailleurs si tous les langages avaient leur propre définition de l'alignement des données, ce serait invivable pour les développeurs d'OS, non ? Et puis l'alignement de données, c'est juste des données contigües en mémoire, pourquoi le spécifier ? Les compilateurs savent très bien le faire.

[Klaim]

Je dis juste que cette norme (de ce que j'ai lu), ne définit qu'un mot-clé. Elle ne dit pas au compilateur comment aligner les données.

La specification du mot clee defins comment aligner les donnees (peut etre avec des details d'implementations volontairement omis pour que les compilateurs fassent le boulot pour les systemes cible).

La page que je t'ai fournis explique comment l'utiliser pas comment c'est implemente exactement.

D'ailleurs si tous les langages avaient leur propre définition de l'alignement des données, ce serait invivable pour les développeurs d'OS, non ? Et puis l'alignement de données, c'est juste des données contigües en mémoire, pourquoi le spécifier ? Les compilateurs savent très bien le faire.

On dirait que tu ne comprends pas le rôle d'une norme ou d'un standard.

La norme definis et standardise les pratiques qui sont deja existante (ou des abstractions de ces pratiques), dans une version utilisable par tous, qui sera alors implementee par tous les compilateurs de la meme facon, meme si certaines parties de l'implementation dependent de la plateforme cible (auquel cas la norme dis explicitement que l'implementation, le compilateur, fais ce qui lui chante tant que ce que la norme garanti reste vrai).

Pourquoi le specifier? Pour que quand tu ecris le code qui aligne, tu n'ais pas a changer ce code pour chaque compilateur que tu utilises. C'est pareil pour toutes les features. C'est aussi le principe d'un language...

L'essentiel de mon code est compilable sur plusieurs compilateurs qui ne fournissent aps du tout les memes instructions specifiques, parceque je suis le standard et que je n'utilises rien de specifique a un compilateur.

Autrement dis, la norme c'est la loi. Tout ce qui s'en ecarte est soit illegal, soit non-specifie.

Pour l'alignement, oui c'etait deja implemente a priori de la meme facon dans tous les compilateurs, mais il n'y avait pas une syntaxe unique pour l'utiliser. Comme c'est implemente partout pareil, il suffit d'une syntaxe en plus, standard, et hop c'est bon. Comme c'est partout pareil, ca implique que class/struct/union/enum sont tous sujet a alignement, comme la norme le specifie, quel que soit le compilateur (et ca l'etait avant la norme).

D'ou les dernieres pages de discussions, qui disent en gros, que meme si on se fie pas a la norme, l'alignement s'applique a n'importe quel type, ou membre de type.

[Bousk]

Quand j'ai fait l'erreur de dire qu'on ne peut pas aligner une classe, c'était dans le sens où une classe qui contient des fonctions, on ne peut pas aligner ce qu'il y a à l'intérieur des fonctions. On peut aligner le pointeur de la fonction, mais pas ses paramètres et pas le code de la fonction.

http://msdn.microsoft.com/en-us/library/83ythb65.aspx



Donc quand au départ j'ai dis qu'on ne pouvait pas aligner une classe, c'était avec cette idée là. D'ailleurs quel serait l'intérêt par exemple, de passer le code alignée d'une fonction à une fonction assembleur.

Je vais p-e dire des grosses conneries mais...
- ce qu'il y a à l'intérieur d'une fonction, on s'en moque, on utilise des types, ce sont les types qui sont alignés ou non. Le code généré pour/par la fonction n'est pas notre souci.
- Les paramètres d'appel à une fonction sont gérés par la callstack (ou truc du genre), encore une fois on s'en moque, ce n'est pas un type à aligner, c'est juste qqs registres qui sont paramétrés, rien à voir avec l'alignement de données
- je ne vois absolument pas ce qu'est sensé montré ton lien vers msdn. Rien de plus que de l'alignement de données avec un mot-clé. On a aussi un #pragma pack (de mémoire) utilisable pour l'alignement

[moldavi]

On dirait que tu ne comprends pas le rôle d'une norme ou d'un standard.

Oui ça c'est possible, mais relis bien un de mes messages. J'ai dit que ça évitera les #ifdef.

Tu penses toujours que je ne comprends rien aux normes, enfin surtout aux conséquences pratiques.

[moldavi]

- ce qu'il y a à l'intérieur d'une fonction, on s'en moque, on utilise des types, ce sont les types qui sont alignés ou non. Le code généré pour/par la fonction n'est pas notre souci.

Et oui, comme tu le dis si bien, on aligne des types, et que pour les fonctions ce n'est pas notre souci (je reprends tes mots).

Et comme on aligne des types, on va naturellement utiliser des structures et non pas des classes.

Mais visiblement je suis le seul à faire cette constatation.