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.
Version imprimable
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.
Ben c'est un peu comme dire que ceux qui se raccrochent � la doc d'une biblioth�ques sont des int�gristes... :aie: 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 :mouarf:
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.
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.Citation:
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.
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�.
Re.
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.
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.
Sur le site de l'ISO.
Tu as une version gratuite t�l�chargeable � partir de : http://isocpp.org/std/the-standard
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?
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.
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.
Peut-�tre as-tu le lien pr�cis ?
Selon le lien http://en.cppreference.com/w/cpp/language/alignas que tu m'as fourni :
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.Citation:
but in C++ this is a keyword
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.
Bonjour,
Qu'est-ce que tu entends par "une d�finition pour les OS de comment aligner les donn�es ?Citation:
C'est une norme pour un mot-cl�, pas une d�finition pour les OS de comment aligner les donn�es.
@moldavi: Commences par lire les sections 3.11 et 7.6.2 :
Citation:
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.
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.Citation:
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).
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
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).Code:
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
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.
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?
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