Merci pour ces informations, mais relis mes messages précédents. J'ai compris depuis longtemps l'aspect pratique de cette norme pour les développeurs multiplateformes.
Version imprimable
En fait je suis en train de me dire que moldavi tu parles de l'alignement qu'imposent certaines architectures (pas cote languages donc).
Note que generalement ca ne viens pas de l'OS mais du hardware (la memoire ou le processeur ou la combinaison des deux) qui est juste plus rapide si les memoires sont alignees d'une certaine facon, ou encore qui ne s'executera carrement pas correctement.
Ca ne se decide pas dans le code de l'OS. L'OS au mieux pourra faire des verifications au runtime pour eviter de crasher toute la machine, mais c'est tout. La convention est induite par la machine et c'est le compilateur qui connait l'architecture en question et qui va faire son possible pour que ca rentre dans ce que l'architecture accepte.
Sauf si tu precises a la main que ut veux un alignement precis. Auquel cas tu utilises les commandes dont on parle.
L'idée pour résumer, c'est que cette norme n'a rien à spécifier sur l'alignement, parce qu'elle n'invente rien. L'alignement ce sont des données contigües en mémoire. Donc cette norme ne fait que préciser, pas spécifier. On l'a pas attendu pour dire ce qu'était l'alignement de données. Elle ne fait que préciser, pas spécifier. Elle parle peut-être même d'une chose qui existait avant le langage C++.
Vous allez me dire, oui mais c'est le but d'une norme. Sauf que là, les OS/compilateurs ont précédé la norme. La norme ne fait que s'adapter à la pratique.
Dans cette situation là, la norme ne fait que des choses pour faciliter la vie du développeur (elle institue un mot-clé). Elle s'adapte aux pratiques courantes des compilateurs. Elle n'invente rien.
Donc personnellement, je n'appelle pas cela de la spécification, mais de l'adaptation. C'est aussi le rôle que j'attends d'une norme : facilité la vie des développeurs.
Oui, la norme n'a rien invente, c'est pareil pour toutes les features, elles ne fais que les normer, les standardiser, ces pratiques existantes et repandues (meme les lambdas par exemple).
Mais quel est le probleme avec ca?
Ce n'est pas cela du tout, mais il faut comprendre aussi le fonctionnement de la norme (du moins de la norme C++).
Avant qu'il n'y ait la norme, il y a une évolution dans la manière d'envisager la conception et la programmation, une nouvelle idée, un nouveau concept (un nouveau langage).
cette "nouveauté" peut être (ou non) implémentée de "n'importe quelle manière" par le compilateur, sous la forme de ce que l'on pourrait plus ou moins appeler "une extension".
C'est ce qui fait que VC utilise __declspec et que Gcc utilise __attribute__.
Tot ou tard, on se rend compte qu'une possibilité (quelle qu'elle soit) est généralisée, mais que chaque compilateur l'implémente "à sa sauce" et que les différentes implémentations sont faites de manière "décousues" (comprend :sans qu'il n'y ait la moindre concertation entre les différents éditeur de compilateur quant aux noms utilisés ou aux comportements observés).
La norme apporte donc un formalisme indiquant clairement quelle fonctionnalité doit être proposée, sous quel nom, ainsi que les comportements qu'elle doit proposer.
A partir de là, les compilateurs qui prétendent respecter la norme sont obligés de fournir la fonctionnalité telle que décrite par la norme.
Or, l'alignement des données en mémoire n'est, sommes toutes, qu'un aspect purement et simplement marginal d'un aspect beaucoup plus global qui est le modèle mémoire utilisé par C++, qui a été normalisé dés le début!
On peut trouver quantité de raisons au fait que le mot clé alignas n'est apparu qu'en C++11, mais cela ne change rien au fait, tout ce que tu as dit (à part le fait que l'on ne peut pas aligner les arguments d'une fonction) est totalement faux:
- On peut aligner tout aussi bien des structures que des classes (ou meme des unions), et ce, même si l'habitude de x ou de y tend plus ou moins à n'aligner que des structures
- Le fait qu'une fonction aie recours à l'allocation dynamique de la mémoire n'empêche absolument pas l'alignement des données
- L'accessibilité des données n'a strictement rien à voir avec l'alignement des données en mémoire
- La présence (ou l'absence) de fonction(s) membre(s) ne joue absolument pas sur la capacité d'aligner les données en mémoire
Cela fait maintenant près de 60 messages que l'on te dis que presque tout ce que tu déclares est erroné, et tu essayes malgré tout de te contorsionner comme un chat afin de retomber sur tes pattes.
Il ne faut donc pas forcément t'étonner si tes propos sont réfutés ;)
Bonjour.
Flob90 nous a fournit un lien qui montre que cela existe... Je veux bien que tu me donnes des cours sur la norme C++, ce n'est pas inintéressant. Mais il faudrait que je sois certain que tu maîtrises le sujet pour te faire confiance.
Sinon je suis comme un chat, c'est vrai, mais pas pour le contorsionnisme, plutôt pour l'indépendance (d'esprit) et la paresse.
:calim2: Je te prie de ne pas détourner mes propos :aie:
Je ne vois rien dans les éléments que j'ai cité quelque-chose que va dans le sens :
Qui était l'assertion à laquelle s'opposait Koala01 et Germinolegrand.
Mon message s'opposait aussi à ton assertion :
Alors oui c'est un mot-clé, oui la norme explique comment ce mot-clé doit impacter le codé généré par rapport au modèle mémoire du C++. Le lien OS <-> code est fait par le compilateur, c'est un peu le principe d'un compilateur.
Franchement, je suis ouvert à la discussion. Mais là cela devient lourd.
Là je dis que Flob90 nous a fournit un lien... C'est tout... Je répète.. Flob90 nous a fournit un lien qui montre que la norme nous parle d'alignement.
Dis-moi où je dis que Flob90 appuie mon propos initial ? Tu ne peux pas. Voilà ce à quoi je bataille depuis 60 messages, dixit un posteur.
Je cherche la phrase où je dis que Flob90 est 100% d'accord avec moi, je ne la trouve pas...
Désolé mais pour moi la discussion est close.
Il y a un point sur lequel on est d'accord : ça devient lourd.
Je pense que le tour de la question de la différence entre struct et class a été fait. Le lecteur intéressé pourra se faire sa propre opinion en lisant les 4 pages de discussion (ou juste la première réponse, qui répondait déjà à la question). Il n'est donc pas nécessaire de continuer plus en avant une discussion qui risque de tourner aux argumentations personnelles...
Merci
Non mais c'était une vraie question de ma part, rien de plus.
C'est ce que j'avais compris dans ton message à cause de :
Citation:
Envoyé par koala01
Mais si tu voulais juste dire que Flob avait fourni un lien sur le draft de la norme, alors OK.Citation:
Envoyé par moldavi