Si une classe A contient un champ de type T, est-il garanti que sizeof(A)
sera un multiple entier de sizeof(T) ?
Par exemple, si je définis
class A {
int un;
double deux;
}
(ou double d'abord et int ensuite) et que je compile avec le compilateur
Intel, j'obtiens sizeof(A)==16 (sachant que sizeof(int)==4 et
sizeof(double)==8). Est-ce imposé par la norme ? Est-ce un comportement
général des compilateurs courants ?
Quel est l'intérêt d'utiliser une classe sans méthode plutôt qu 'une structure ?
La seule différence entre classe et structure est que dans une structur e lorsque ce n'est pas précisé par une étiquette public: ou private: les données ou fonctions sont par défaut publiques alors qu'elles seraien t privées dans une classe. A part ça c'est la même chose...
Le 05/10/2012 21:38, Benoit Izac a écrit :
Quel est l'intérêt d'utiliser une classe sans méthode plutôt qu 'une
structure ?
La seule différence entre classe et structure est que dans une structur e
lorsque ce n'est pas précisé par une étiquette public: ou private: les
données ou fonctions sont par défaut publiques alors qu'elles seraien t
privées dans une classe.
A part ça c'est la même chose...
Quel est l'intérêt d'utiliser une classe sans méthode plutôt qu 'une structure ?
La seule différence entre classe et structure est que dans une structur e lorsque ce n'est pas précisé par une étiquette public: ou private: les données ou fonctions sont par défaut publiques alors qu'elles seraien t privées dans une classe. A part ça c'est la même chose...
ld
On 9 oct, 16:58, (Marc Espie) wrote:
In article , Jean-Marc Bourguet wrote:
>Interessant. J'ai pas le temps de regarder pour confirmer, mais il me >semble qu'on sort du cadre de ce qui est exprimable comme contrainte >d'alignement en C11 et C++11. (En passant, je me demande d'ailleurs si >ces normes ne contraignent pas l'alignement a etre des puissances de 2, >il faudra que je regarde).
Je te rassure, mais le vieux code de pthread (et le code noyau de gestion de threads) qui gerait ca cree de toutes facons ses piles a la main, en assembleur.
Meme aujourd'hui, surtout en presence d'optimiseurs agressifs comme gcc.
je reste assez dubitatif sur les versions recentes (4.7). Les performances se sont degradees par rapport a 4.5 sans compter les bugs. J'ai un exemple recent ou appeler un printf en plein milieu d'un calcul numerique augmente de 25% les performances du code. La raison est que l'optimiseur de gcc 4.7 ne peut plus "fusionner" deux parties de code qui sont semantiquement separees. L'appel d'une fonction variadique avec effet de bord est vu comme un mur par l'optimiseur. Du coup, il optimise mieux les deux parties separement comme il le devrait et les performances sont meilleures.
Typiquement, il y a quelques options pour respecter ce genre de souci d'ABI dans ton compilo... parce que typiquement, l'alignement de ta pile est susceptible de changer selon les instructions que tu veux utiliser, et parfois tu peux te retrouver a devoir reforcer le bon alignement de pile en entree d'une fonction qui fait du sse, sachant que tu viens de trucs plus "packes" que le reste.
SSE possede aussi des instructions pour charger/sauver des donnees non alignees comme _mm_loadu_pd. Certes il y a une legere perte de performance, mais ca ne crashe pas.
Ca a toujours ete comme ca, et meme si C++ gere de plus en plus de trucs bas niveau, les choses continuent quand meme d'evoluer.
Il manque encore les flexible array members incompatible avec le modele objet actuel. Indispensable pour de bonne performances sur de petits objets dynamiques comme les strings ou les vecteurs.
(et je crois qu'on a des archis sur lesquelles on peut faire du multi-thr ead, mais ou le modele de C++2011 d'atomics ne mappe pas correctement sur l'ar chi).
ld.
On 9 oct, 16:58, es...@lain.home (Marc Espie) wrote:
In article <pxby5jfyb3t....@bourguet.org>,
Jean-Marc Bourguet <j...@bourguet.org> wrote:
>Interessant. J'ai pas le temps de regarder pour confirmer, mais il me
>semble qu'on sort du cadre de ce qui est exprimable comme contrainte
>d'alignement en C11 et C++11. (En passant, je me demande d'ailleurs si
>ces normes ne contraignent pas l'alignement a etre des puissances de 2,
>il faudra que je regarde).
Je te rassure, mais le vieux code de pthread (et le code noyau de gestion
de threads) qui gerait ca cree de toutes facons ses piles a la main, en
assembleur.
Meme aujourd'hui, surtout en presence d'optimiseurs agressifs comme gcc.
je reste assez dubitatif sur les versions recentes (4.7). Les
performances se sont degradees par rapport a 4.5 sans compter les
bugs. J'ai un exemple recent ou appeler un printf en plein milieu d'un
calcul numerique augmente de 25% les performances du code. La raison
est que l'optimiseur de gcc 4.7 ne peut plus "fusionner" deux parties
de code qui sont semantiquement separees. L'appel d'une fonction
variadique avec effet de bord est vu comme un mur par l'optimiseur. Du
coup, il optimise mieux les deux parties separement comme il le
devrait et les performances sont meilleures.
Typiquement, il y a quelques options pour respecter ce genre de souci
d'ABI dans ton compilo... parce que typiquement, l'alignement de ta pile
est susceptible de changer selon les instructions que tu veux utiliser,
et parfois tu peux te retrouver a devoir reforcer le bon alignement de
pile en entree d'une fonction qui fait du sse, sachant que tu viens
de trucs plus "packes" que le reste.
SSE possede aussi des instructions pour charger/sauver des donnees non
alignees comme _mm_loadu_pd. Certes il y a une legere perte de
performance, mais ca ne crashe pas.
Ca a toujours ete comme ca, et meme si C++ gere de plus en plus de
trucs bas niveau, les choses continuent quand meme d'evoluer.
Il manque encore les flexible array members incompatible avec le
modele objet actuel. Indispensable pour de bonne performances sur de
petits objets dynamiques comme les strings ou les vecteurs.
(et je crois qu'on a des archis sur lesquelles on peut faire du multi-thr ead,
mais ou le modele de C++2011 d'atomics ne mappe pas correctement sur l'ar chi).
>Interessant. J'ai pas le temps de regarder pour confirmer, mais il me >semble qu'on sort du cadre de ce qui est exprimable comme contrainte >d'alignement en C11 et C++11. (En passant, je me demande d'ailleurs si >ces normes ne contraignent pas l'alignement a etre des puissances de 2, >il faudra que je regarde).
Je te rassure, mais le vieux code de pthread (et le code noyau de gestion de threads) qui gerait ca cree de toutes facons ses piles a la main, en assembleur.
Meme aujourd'hui, surtout en presence d'optimiseurs agressifs comme gcc.
je reste assez dubitatif sur les versions recentes (4.7). Les performances se sont degradees par rapport a 4.5 sans compter les bugs. J'ai un exemple recent ou appeler un printf en plein milieu d'un calcul numerique augmente de 25% les performances du code. La raison est que l'optimiseur de gcc 4.7 ne peut plus "fusionner" deux parties de code qui sont semantiquement separees. L'appel d'une fonction variadique avec effet de bord est vu comme un mur par l'optimiseur. Du coup, il optimise mieux les deux parties separement comme il le devrait et les performances sont meilleures.
Typiquement, il y a quelques options pour respecter ce genre de souci d'ABI dans ton compilo... parce que typiquement, l'alignement de ta pile est susceptible de changer selon les instructions que tu veux utiliser, et parfois tu peux te retrouver a devoir reforcer le bon alignement de pile en entree d'une fonction qui fait du sse, sachant que tu viens de trucs plus "packes" que le reste.
SSE possede aussi des instructions pour charger/sauver des donnees non alignees comme _mm_loadu_pd. Certes il y a une legere perte de performance, mais ca ne crashe pas.
Ca a toujours ete comme ca, et meme si C++ gere de plus en plus de trucs bas niveau, les choses continuent quand meme d'evoluer.
Il manque encore les flexible array members incompatible avec le modele objet actuel. Indispensable pour de bonne performances sur de petits objets dynamiques comme les strings ou les vecteurs.
(et je crois qu'on a des archis sur lesquelles on peut faire du multi-thr ead, mais ou le modele de C++2011 d'atomics ne mappe pas correctement sur l'ar chi).
