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?