Discussion :

[Bousk]

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.

Il est assez extraordinaire oui qu'apr�s 3 pages et autant de messages tu n'aies pas remarqu� que class ou struct sont strictement identiques. A la visibilit� par d�faut pr�s.

[moldavi]

Il est assez extraordinaire oui qu'apr�s 3 pages et autant de messages tu n'aies pas remarqu� que class ou struct sont strictement identiques. A la visibilit� par d�faut pr�s.

Oui �a j'ai compris depuis tr�s longtemps, conf�re mes messages pr�c�dents. Enfin je le savais m�me avant que le d�bat ne soit lanc�.

Par contre, toi, tu ne comprends pas la vision diff�rente que je propose.

C'est marrant, il y a des int�gristes de la norme C++ (je ne dis pas int�griste dans le but d'�tre blessant), et le reste n'a pas lieu d'exister. C'est pas dans la bible, alors il ne faut surtout pas en parler.

Et bien je ne vais pas m'en priver, et je fais part de mon exp�rience, sans jamais dire que c'est une v�rit� absolue, mais juste en argumentant le pourquoi. Cela ne m'emp�che pas de me remettre en cause quand j'ai tort.

[germinolegrand]

C'est marrant, il y a des int�gristes de la norme C++, et le reste n'a pas lieu d'exister. C'est pas dans la bible, alors il ne faut surtout pas en parler.

Ben c'est un peu comme dire que ceux qui se raccrochent � la doc d'une biblioth�ques sont des int�gristes... La doc du C++ c'est sa norme. C'est d'ailleurs un trait� international, sign� par les repr�sentants des diff�rents pays, ce qui l'�l�ve au rang de loi. On pourrait donc presque mettre des amendes � ceux qui ne la respectent pas

[moldavi]

Ben c'est un peu comme dire que ceux qui se raccrochent � la doc d'une biblioth�ques sont des int�gristes... La doc du C++ c'est sa norme. C'est d'ailleurs un trait� international, sign� par les repr�sentants des diff�rents pays, ce qui l'�l�ve au rang de loi. On pourrait donc presque mettre des amendes � ceux qui ne la respectent pas

Arf, le comit� du C++ va me mettre une amende pour avoir oser penser diff�remment.

[Bousk]

Oui �a j'ai compris depuis tr�s longtemps, conf�re mes messages pr�c�dents.

Par contre, toi, tu ne comprends pas la vision diff�rente que je propose.

C'est marrant, il y a des int�gristes de la norme C++ (je ne dis pas int�griste dans le but d'�tre blessant), et le reste n'a pas lieu d'exister. C'est pas dans la bible, alors il ne faut surtout pas en parler.

Et bien je ne vais pas m'en priver, et je fais part de mon exp�rience, sans jamais dire que c'est une v�rit� absolue, mais juste en argumentant le pourquoi. Cela ne m'emp�che pas de me remettre en cause.

Tu ne proposes rien du tout, au d�but tu poses que struct et class sont diff�rentes, il n'en est rien.
Que Bob ou [insert random nom de boite ici] utilise que des class, �a signifierait que struct est interdit en C++ et r�serv� au C ?
Ce que tu dis n'as rien d'une vision ou remise en cause. Il y a une norme qui d�finit comment �a fonctionne. Les r�gles de codage que chacun utilse on s'en moque royalement � ce sujet.
Si Bobby et sa boite veulent nommer leurs variables en camelCase ou utiliser une indentation invers�e, �a n'en fait en rien une norme, vision ou quoi que ce soit, tout au plus une bonne pratique, chez eux pour leur code avec leurs r�gles de codage � respecter.
Et quasi-totalement ind�pendante du fait qu'on soit en C++ btw.

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.

Tu l'as constat�, grand bien t'en fasse. Mais on te r�p�te que ce n'est pas une r�gle, obligation ou quoi que ce soit.
Que chacun revient mettre en cause/red�finir la norme en se basant sur sa propre exp�rience de r�gles de codage n'avance � rien. Tu confonds la norme et les r�gles du langage avec des r�gles de codage.

Oui moi-m�me quand je fais de l'alignement j'ai tendance � utiliser une struct. Parce qu'en g�n�ral il s'agira de POD, �ventuellement am�nag� de constructeurs et qqs m�thodes "helper". Et apr�s ? Ce sont 2 concepts totalement orthogonaux entre eux. Les relier n'apporte rien et est totalement eron�.

[moldavi]

mais moldavi semble croire fermement que c'est vrai partout,

D�sol� si j'ai donn� cette impression. J'ai employ� le mot souligner, donc lorsque je souligne, je n'affirme pas. Je parle juste d'une pratique courante.

[moldavi]

Re.

Tu l'as constat�, grand bien t'en fasse. Mais on te r�p�te que ce n'est pas une r�gle, obligation ou quoi que ce soit.

C'est bien de me dire que ce ne n'est pas une r�gle, j'ai d'ailleurs ironiquement parler de r�gle implicite, conf�re le mot Troll. Mais je n'ai jamais impos� cette r�gle comme une loi de la bible du d�veloppeur C++. Ou alors reprends mes dires et je ferai mon mea culpa.

Que chacun revient mettre en cause/red�finir la norme en se basant sur sa propre exp�rience de r�gles de codage n'avance � rien.

Je n'ai jamais remis en cause la norme C++. J'estime m�me qu'elle est importante pour la stabilit� des d�veloppements.

Par contre dire que de parler d'autre chose que de la norme, n'avance � rien, l� c'est certain on est pas d'accord. Je crois que c'est juste un probl�me d'ouverture d'esprit.

[moldavi]

Re.

Il y a une norme qui d�finit comment �a fonctionne.

Ok. Elle est o� cette norme qui d�finit le fonctionnement ?

[oodini]

Sur le site de l'ISO.

[JolyLoic]

Tu as une version gratuite t�l�chargeable � partir de : http://isocpp.org/std/the-standard

[r0d]

Il y a une diff�rence entre la version payante et la version gratuite? Ou comme d'habitude, c'est juste une question de format/typo?

[ternel]

Il me semble avoir lu qu'il n'y en aurait pas.

Ca serait un peu dans le genre:
la proposition est publi�e.
Elle est adopt�e.
Le document est r��dit� en changeant les pieds-de-page avec le nom de la nouvelle norme. Ce n'est plus un draft.

[koala01]

Il y a une diff�rence entre la version payante et la version gratuite? Ou comme d'habitude, c'est juste une question de format/typo?

En fait, la version gratuite est a priori un draft, alors que la version payante est la version finale.

C'est, peu ou prou, la diff�rence qu'il peut exister entre une release-candidate et une version finale

[moldavi]

Bonjour.

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

Excuse-moi, mais je ne vois pas � quel moment la norme d�finit comment aligner les donn�es. Peut-�tre que je ne farfouille pas suffisamment dans la norme, mais je ne trouve pas.

Peut-�tre as-tu le lien pr�cis ?

Selon le lien http://en.cppreference.com/w/cpp/language/alignas que tu m'as fourni :

but in C++ this is a keyword

C'est m�me pas moi qui le dit, c'est la norme. C'est une norme pour un mot-cl�, pas une d�finition pour les OS de comment aligner les donn�es.

PS: je ne cherche pas � alimenter le troll. Ce qui est certain, c'est que l'on arrive pas � se comprendre. Mais par �crit ce n'est pas toujours �vident. Mon message original �tait l� pour signaler une diff�rence. De mon point de vue. Prenez-le juste comme, je fais part de mon exp�rience, peut-�tre que cela vous apportera quelque chose dans vos futurs d�veloppements. Si ce n'est pas le cas, oubilez-le.

[Arzar]

Bonjour,

C'est une norme pour un mot-cl�, pas une d�finition pour les OS de comment aligner les donn�es.

Qu'est-ce que tu entends par "une d�finition pour les OS de comment aligner les donn�es ?

[Flob90]

@moldavi: Commences par lire les sections 3.11 et 7.6.2 :

When the alignment-specifier is of the form alignas( assignment-expression ):
� the assignment-expression shall be an integral constant expression
� if the constant expression evaluates to a fundamental alignment, the alignment requirement of the
declared entity shall be the specified fundamental alignment
� if the constant expression evaluates to an extended alignment and the implementation supports that
alignment in the context of the declaration, the alignment of the declared entity shall be that alignment
� if the constant expression evaluates to an extended alignment and the implementation does not support
that alignment in the context of the declaration, the program is ill-formed
� if the constant expression evaluates to zero, the alignment specifier shall have no effect
� otherwise, the program is ill-formed.

Object types have alignment requirements (3.9.1, 3.9.2) which place restrictions on the addresses at which an
object of that type may be allocated. An alignment is an implementation-defined integer value representing
the number of bytes between successive addresses at which a given object can be allocated. An object type
imposes an alignment requirement on every object of that type; stricter alignment can be requested using
the alignment specifier (7.6.2).

Donc si je me trompe pas, la norme dit bien que ce fameux mot-cl� impose l'adresse que peut prendre une donn�e membre : on impose bien l'alignement.

[Flob90]

Le draft n3485, novembre 2012

[koala01]

Bonjour.

Excuse-moi, mais je ne vois pas � quel moment la norme d�finit comment aligner les donn�es. Peut-�tre que je ne farfouille pas suffisamment dans la norme, mais je ne trouve pas.


C'est m�me pas moi qui le dit, c'est la norme. C'est une norme pour un mot-cl�, pas une d�finition pour les OS de comment aligner les donn�es.

PS: je ne cherche pas � alimenter le troll. Ce qui est certain, c'est que l'on arrive pas � se comprendre. Mais par �crit ce n'est pas toujours �vident. Mon message original �tait l� pour signaler une diff�rence. De mon point de vue. Prenez-le juste comme, je fais part de mon exp�rience, peut-�tre que cela vous apportera quelque chose dans vos futurs d�veloppements. Si ce n'est pas le cas, oubilez-le.

Ce qu'il faut comprendre, c'est que la possibilit� offerte par VC++ qui utilise __declspec( align( XXX ) ) et celle offerte par Gcc qui utilise __attribute__((__aligned__(YYY))) ont strictement le m�me effet, � savoir celui d'aligner les donn�es sur le nombre de byte indiqu�.

Seulement, ces deux possibilit�s sont d�pendantes du compilateur utilis� : si tu essayes __declpsec(align(XXX)) avec gcc, il te dira qu'il ne connait pas cette fonction et il en ira de m�me si tu utilises __attribute__((__aligned__(YYY))) avec visual studio.


Tu pourrais tr�s bien cr�er ton propre compilateur et impl�menter un truc du genre __aligneMoiCaSur(ZZZ)

Du coup, si tu veux aligner des donn�es et que tu veux permettre la compilation avec les deux compilateur, tu te retrouves � devoir d�finir un symbole unique qui puisse prendre la "bonne valeur" en fonction du compilateur utilis�, au minimum sous une forme proche de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
#ifdef /* n'importe quoi qui t'assures que c'est visual studio */
#define ALIGN(x) __declspec(align(x))
#else if /* n'importe quoi qui t'assure que c'est gcc */
#define ALIGN(x) __attribute__((__aligned__(x)))
#else if /* n'importe quoi qui t'assure que c'est ton compilateur perso */
#define ALIGN(x) __aligneMoiCaSur(x)
#endif

Le probl�me, c'est que j'ai d�cid� de nommer le symbole ALIGN et que mon voisin l'aura sans doute nomm� ALIGNMENT (ou n'importe quel autre identifiant � la noix).

La norme nous dit maintenant que le comportement qui consiste � aligner les donn�es sur un nombre fix� de bytes peut (doit) �tre accessible au travers du mot cl� alignas.

H� bien, VC++ va faire en sorte que __declspec(align(x)) soit utilis� lorsque alignas est utilis�, alors que de son cot� Gcc va faire en sorte que ce soit __attribute__((__aligned__(x))) qui sera utilis� (et moi, de mon cot�, je ferai en sorte que ce soit __aligneMoiCaSur(x) ).

Mais ca, on s'en contre fout royalement : ce qui importe, c'est que le d�veloppeur puisse maintenant s'assurer que les donn�es seront align�es (de la m�me mani�re, car cela se joue au niveau du code binaire ex�cutable propre au processeur!!) en n'ayant pas besoin de faire attention au compilateur envisag� : on utilise aligneas(x), et "le tour est jou�".

Et si un compilateur n'avait jamais pr�vu de permettre de pr�ciser l'alignement des donn�es, h� bien, il devra finir par le faire pour assurer le respect de la norme.

[moldavi]

Le draft n3485, novembre 2012

D�sol�, Flob90 j'ai supprimer mon message. Mais merci pour le lien.

[Klaim]

Peut etre que tu ne comprends pas ce qu'est un mot-clee? C'est la base de la definition d'un language. Ce mot clee identifie justement la feature. Apres, la norme dis qu'est-ce que ce mot clee est cense donner, du point de vue de l'utilisateur - ou si tu preferes, ca definis l'interface du language, parfois en expliquant comment ca pourrait etre implemente.

L'alignement, en soit, est une specification qui n'a pas de rapport avec l'OS. L'OS (ou plutot la combinaison Hardware+OS) impose, ou pas, des alignements possible, ce qui est pris en compte par le compilateur. Les differentes commandes d'alignement dont on parle ici ne font qu'une chose: demander au compilateur de faire l'alignement selon une regle que l'on impose au lieu de le laisser faire (generalement pour que l'alignement soit le meme pour les types de toutes les plateformes cibles, ce qui fait eu niveau binaire les donnees ont toujours la meme taille et sont plus facile a traiter quand on les envoie via le reseau par exemple).

Autrement dis, tu ne vas pas avoir la description de l'implementation du mot-clee, celui ci n'est qu'une interface pour une fonctionalite. Libre a l'implementeur du compilateur de faire ce qu'il veut tant que ca suit ce qui est dit dans la norme (a savoir les paragraphes cites par Flob90).

Et comme on disais, la commande d'alignement n'impacte que la facon dont les donnees sont ...alignees en memoire. Donc ca n'impacte que comment le compilateur va organiser les donnees d'un type. Donc peut importe si c'est un struct ou une classe (dans la norme d'ailleurs, c'est la meme chose...) ou une union (qui est un type fait de plusieurs types partageant la meme memoire) ou un enum (qui reste similaire a un type d'entier). Si on ajoutait d'autre variantes de types, ca ne changerai pas qu'on puisse faire de l'alignement pour forcer la facon dont les donnees sont organisees.

Quand c'est pas le cas, le compilateur est libre d'ajouter des bytes entre les differents membres. Il fait comme il veut. Le seul truc qui est impose a ce niveau la (si on oublie le bordel lie a l'heritage) c'est que les donnees membres sont ordonnees en memoire dans l'ordre dans lesquelles elles aparaissent dans le type, le compilateur n'a pas le droit de leur changer d'ordre, meme si il insert autant de bytes entre qu'il le souhaite.

Est-ce que ca te clarifie un peu les choses?