operator new sans delete

Bonjour à tous,
Je suis actuellement dans la lecture d'un excellent bouquin sur la programmation de jeu, une partie traite des classes optionnelles voila un bout du code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

// Base : template <unsigned long size> class optional_base { public: optional_base(); optional_base(const optional_base &t);   optional_base & operator = (const optional_base &t);   bool const Valid() const; bool const UnValid() const;   protected: bool m_bValid; char m_data[size]; };   // Optional : template <class T> class optional : public optional_base<sizeof(T)> { public:   // Constructeurs... // Operateurs... private:   const T * const GetT() const { return reinterpret_cast<const T * const>(m_data); } T * const GetT() { return reinterpret_cast<T * const>(m_data); } void Construct(const T &t) { new (GetT()) T(t); } void Destroy() { GetT()->~T(); } };

---

Seulement c'est la première fois que je vois l'opérateur new utilisé de cette manière, il n'y a de delete associé nulle part dans le code et GetT dans ce cas retourne un T*const donc les données ne sont pas sencé être modifié sauf si j'ai rien compris....... Si vous pouviez m'éclairer sur ce mystère 8O, si il faut plus de détail sur le code n'hésitez pas à demander:D
Merci d'avance

Salut,

C'est un placement new, cf. cette entrée de la FAQ.
Un new "normal" est séparé en deux : allocation de la mémoire et initialisation, un placement new (comme son nom l'indique un peu) se contente d'effectuer la partie initialisation (donc d'appeler le constructeur en gros).

edit : il y a une ) en trop dans le corps de Construct a priori.

MAT.

Si la méthode retourne un T * const, alors c'est le pointeur qui est constant, pas la donnée pointée ;).

C'est d'ailleurs parceque la donnée retournée peut être modifiée que la fonction elle même n'est pas const.

Citation:

---

il y a une ) en trop dans le corps de Construct a priori

---

Petite faute d'inattention c'est réglé... Merci beaucoup pour le lien sur la faq je l'avais loopé :oops:. En tout cas tout est limpide désormais concernant la syntaxe :D

Citation:

---

Si la méthode retourne un T * const, alors c'est le pointeur qui est constant, pas la donnée pointée

---

A vrai dire je ne me suis jamais vraiment posé la question pour moi "const T *" était associé à un pointeur constant et du coup "const T * const" à un pointeur constant sur donnée constante(d'après ma logique :mouarf:) Mais alors ce que je comprend pas c'est pourquoi utiliser ces deux syntaxes pour définir la même chose mais surtout pourquoi mettre deux 'const' sachant que l'un d'entre eux ne veut strictement rien dire....:roll:
En tout cas merci beaucoup pour votre aide :merci:

Edit : Finalement le compilateur ne semble pas apprécier sans les parenthèse donc en fait il en manquait une je suppose, pour compiler :

Code:

---

new (GetT()) T(t);

---

Wue,

Citation:

---

Envoyé par babar63

alors ce que je comprend pas c'est pourquoi utiliser ces deux syntaxes pour définir la même chose mais surtout pourquoi mettre deux 'const' sachant que l'un d'entre eux ne veut strictement rien dire....:roll:

---

Attention : un pointeur constant signifie qu'on ne peut pas le modifier, n'est pas la même chose que "données pointées constantes".

Par exemple, avoir un pointeur constant n'interdit absolument pas de modifier les données pointées, SAUF si elles-mêmes sont déclarées constantes. :)

Pour être tout à fait précis sur la constance avec les pointeurs :

La donnée et le pointeur sont constants :
const T * const ou T const * const

ex :

Code:

---

1 2 3 4 5 6 7 8

int i, j; int const * const p_i = &i;   //on ne peut pas modifier i à partir de p_i //*p_i = 10 interdit   //on ne peut pas modifier p_i //p_i = &j interdit

---

La donnée est constante mais pas le pointeur :
const T * ou T const *
ex :

Code:

---

1 2 3 4 5 6 7 8

int i, j; int const * p_i = &i;   //on ne peut pas modifier i à partir de p_i //*p_i = 10 interdit   //on peut modifier p_i p_i = &j; //ok

---

Le pointeur est constant mais pas la donnée :
T * const
ex :

Code:

---

1 2 3 4 5 6 7 8

int i, j; int * const p_i = &i;   //on peut modifier i à partir de p_i *p_i = 10; //ok   //on ne peut pas modifier p_i //p_i = &j interdit

---

Pour faciliter la mémorisation de ce qui est constant, le mieux est de tojours utiliser la syntaxe const après (T const * const), puisque pour les pointeurs constants c'est obligé.
Dans ce cas ce qui est constant se situe avant le const.
Et puis cette règle n'induit pas vraiment en erreur dans le cas ou on utilise le const avant (const T * const) puisqu'on voit vite qu'il n'y a rien avant.


La :faq: en parle

Et pour ce qui est des fonctions membres const :
une fonction membres const ne doit pas modifier ou permettre de modifier l'instance à laquelle elle appartient (il y a un cas particulier avec le mot clef mutable).
Et donc en conséquence, seul les fonctions membres const pourront être appellées sur les objets constant.

ex:

Code:

---

1 2 3 4

optional<int> const opt; opt.GetT(); //l'objet opt est constant, c'est donc la fonction déclarée const qui sera utilisée, et le pointeur retournée sera int const * const; //Si seule la fonction non const avait été déclarée, la compilation ne serait pas passée.

---

Il y a donc une réelle différence entre les deux fonctions :

Code:

---

1 2 3

const T * const GetT() const; T * const GetT();

---

Les 2 renvois un pointeurs constant vers une donnée membre de l'instance (m_data).
Mais la première renvois un pointeur constant sur donnée constante, il ne permet donc pas de modifier m_data.
La deuxième version le permet.

C'est pourquoi la première fonction peut être déclarée const.


La :faq: en parle

Vu de ce coté tout est logique :D en fait je confondais "const T *" et "T * const". C'est la raison pour laquelle je ne saisissais pas le code puisque pour moi la donnée ne pouvait pas être modifié :oops:. C'est vrai que dans ce cas il est préférable d'utiliser const après pour mieux de compréhension... Encore merci pour vos réponses claires et précises qui m'ont permis d'y voir plus clair sur ce point :king:

Citation:

---

Envoyé par MatRem

Si la méthode retourne un T * const, alors c'est le pointeur qui est constant, pas la donnée pointée ;).

---

On ne peut pas renvoyer un scalaire constant en C++. Dans :

Code:

---

const int f ();

---

le const est tout simplement ignoré, comme dans :

Code:

---

void f (const int i);

---

Citation:

---

Envoyé par babar63

Je suis actuellement dans la lecture d'un excellent bouquin

---

Bof...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

template <unsigned long size> class optional_base { char m_data[size]; };   template <class T> class optional : public optional_base<sizeof(T)> { void Construct(const T &t) { new (GetT()) T(t); } };

---

Qu'est-ce qui va garantir l'alignement de m_base? Comment ce code peut avoir la moindre chance de marcher?

Il s'agit de Game Coding Complete (Second Edition). Et oui je confirme le livre est excellent :D, même si il est possible de trouver quelques erreur de code sur presque 900 pages je pense que ce code a du marcher d'une manière ou d'une autre, il est présenté comme un des outils dont utilisé l'auteur (enfin la je m'avance un peu :mouarf:)... Pour en revenir à l'alignement peut être quelque chose ma échappé mais n'est-il pas possible de le désactiver simplement?

EDIT : En fait c'est stupide :mouarf: le sizeof en revanche garantit bien l'alignement...

Citation:

---

Envoyé par babar63

Il s'agit de Game Coding Complete (Second Edition). Et oui je confirme le livre est excellent :D, même si il est possible de trouver quelques erreur de code sur presque 900 pages je pense que ce code a du marcher d'une manière ou d'une autre

---

Sur certains processeur les accès non alignés sont "seulement" beaucoup plus lents. (Pour des jeux c'est fâcheu.)

Citation:

---

Envoyé par babar63

(enfin la je m'avance un peu :mouarf:)... Pour en revenir à l'alignement peut être quelque chose ma échappé mais n'est-il pas possible de le désactiver simplement?

---

C'est une caractéristique du processeur.

Citation:

---

Envoyé par babar63

EDIT : En fait c'est stupide :mouarf: le sizeof en revanche garantit bien l'alignement...

---

Pardon?

Voila ce que je pense : Les données de l'objet T est représenté par un tableau de char, par défaut cette structure est alignée, et la taille du tableau devrait être correct puisqu'on utilise sizeof(T). Quand je disais qu'il garantissait bien l'alignement je voulais dire que le reinterpret_cast fonctionnerait (du moins je pense...). Pour ce qui est du placement new c'était le sujet du topic donc forcément je ne vais pas trop m'avancer mais j'ai cru comprendre que c'était simplement l'appel au constructeur de l'objet (l'allocation étant déjà effectué), le pointeur sur la zone étant valide et la taille correct je ne vois pas d'où vient le problème... Peut-tu me dire sur quel point je me trompe?

EDIT : En relisant plus correctement la faq c'est vrai qu'il est bien préciser que l'objet doit être correctement aligné pour utiliser le placement new, donc si c'est le cas aucun problème pour le code je suppose? Par défaut le compilateur aligne bien non? il y aurait donc danger seulement si on "trafique" l'alignement? ...Dites moi si j'ai tout faux:aie:

EDIT2 : En tout cas je crois que je vais devoir réviser mes cours, réguler mon optimisme sur le livre et faire des tests histoire de mieux comprendre :D

Citation:

---

Envoyé par babar63

Voila ce que je pense : Les données de l'objet T est représenté par un tableau de char, par défaut cette structure est alignée,

---

Pourquoi le serait-elle?

Citation:

---

Envoyé par babar63

et la taille du tableau devrait être correct puisqu'on utilise sizeof(T).

---

Ce n'est pas le problème. C'est l'alignement qui est en cause.

Citation:

---

Envoyé par babar63

Quand je disais qu'il garantissait bien l'alignement je voulais dire que le reinterpret_cast fonctionnerait (du moins je pense...).

---

Au delà du reinterpret_cast (qui sur les archi courantes "fonctionne" toujours), il faut pouvoir construire et manipuler un objet à cette adresse, sans générer un segfault ou équivalent.

Citation:

---

Envoyé par babar63

Pour ce qui est du placement new c'était le sujet du topic donc forcément je ne vais pas trop m'avancer mais j'ai cru comprendre que c'était simplement l'appel au constructeur de l'objet (l'allocation étant déjà effectué),

---

C'est exactement ça.

Citation:

---

Envoyé par babar63

le pointeur sur la zone étant valide et la taille correct je ne vois pas d'où vient le problème...

---

Le problème vient de ce que le pointeur n'est pas valide, car non-aligné.

Citation:

---

Envoyé par babar63

Peut-tu me dire sur quel point je me trompe?

---

Sur le fait que l'alignement est un "non-problème". (Méfiez-vous des "non-problèmes".)

Citation:

---

Envoyé par babar63

Par défaut le compilateur aligne bien non? il y aurait donc danger seulement si on "trafique" l'alignement? ...Dites moi si j'ai tout faux:aie:

---

Selon la norme, tu as tout faux. :cry:

Après, je ne sais pas ce que fait "par défaut" ton compilateur.

Citation:

---

Envoyé par corrector

le const est tout simplement ignoré, comme dans :

Code:

---

void f (const int i);

---

---

Ce n'est pas tout à fait vrai. Vue de l'extérieur, cette fonction est effectivement identique à si on avait déclaré

Code:

---

void f (int i);

---

Mais vue de l'intérieur, i est une variable constante, ce qui ne serait pas le cas sinon (ce serait juste une variable dont les modifications ne seraient pas visible du code appelant).

Citation:

---

Envoyé par corrector

le const est tout simplement ignoré, comme dans :

Code:

---

void f (const int i);

---

---

Comme le dit JolyLoic, c'est faux ce que tu dis. Si tu essaies de compiler ceci

Code:

---

1 2 3 4 5

int identite (const int i) { i = 1 ; return i ; }

---

Tu obtiens une erreur à la compilation. En fait, il serait intelligent d'en mettre régulièrement. Cela rajoute une sécurité supplémentaire.

Citation:

---

Envoyé par Garulfo

Comme le dit JolyLoic, c'est faux ce que tu dis. Si tu essaies de compiler ceci

Code:

---

1 2 3 4 5

int identite (const int i) { i = 1 ; return i ; }

---

Tu obtiens une erreur à la compilation.

---

Il ne faut pas plus lire dans ce que j'ai écris que ce que j'ai écris :

Code:

---

int identite (const int i);

---

est synonyme de

Code:

---

int identite (int i);

---

Dans une définition de fonction, ça n'est pas équivalent évidemment.

Citation:

---

Envoyé par Garulfo

En fait, il serait intelligent d'en mettre régulièrement. Cela rajoute une sécurité supplémentaire.

---

Je ne suis pas sûr : est-ce que ce genre d'erreurs se arrive vraiment?

Alors je suppose que le code provenant du livre se basé uniquement sur des structures de base alignés c'est vrai qu'il y à une partie juste avant sur l'utilisation de la mémoire et l'importance de l'alignement dans les jeux çaE ne doit pas être un hasard... En revanche très dommage de donner le code sans plus d'avertissement :cry:

Y à t-il une explication au fait que la structure doit être alignée pour appelé le new placement? Si vous connaissez des bonnes documentations sur internet traitant de çà je suis preneur :P

Merci beaucoup pour ton aide corrector :merci:

EDIT : Après quelques tests sur visual 2005 (32bits) voilà le résultat :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

struct MyStruct1 { char c; int i; char c2; };   #pragma pack( push, 1 )   struct MyStruct2 { char c; int i; char c2; char unused[2]; };   #pragma pack( pop )   int main(int argc, char *argv[]) { cout << "size of MyStruct1 :" << sizeof(MyStruct1)*8 << endl; cout << "size of MyStruct2 :" << sizeof(MyStruct2)*8 << endl;   system( "pause" ); return 0; }

---

Resultat :

Citation:

---

size of MyStruct1 :96
size of MyStruct2 :64

---

Conclusion : le compilateur aligne mais pas de manière optimal :mouarf:

Citation:

---

Envoyé par babar63

Alors je suppose que le code provenant du livre se basé uniquement sur des structures de base alignés

---

Je ne comprends pas ce que veux dire.

Citation:

---

Envoyé par babar63

... En revanche très dommage de donner le code sans plus d'avertissement :cry:

---

Je ne dirais pas le contraire.

Citation:

---

Envoyé par babar63

Y à t-il une explication au fait que la structure doit être alignée pour appelé le new placement?

---

Tout simplement parce qu'un accès à une donnée, mettons à une adresse A, ne peut être fait que si cette donnée peut effectivement être stoquée à l'adresse A.

Citation:

---

Envoyé par babar63

Merci beaucoup pour ton aide corrector :merci:

---

Je t'en prie.

Citation:

---

Envoyé par babar63

EDIT : Après quelques tests sur visual 2005 (32bits) voilà le résultat :

Code:

---

1 2 3 4 5 6

struct MyStruct1 { char c; int i; char c2; };

---

---

Le calcul est simple (m(n) étant le n-ième membre, partant de 0, N le nombre de membres) :
offset(m(0)) = 0
offset(m(n+1)) = min { x tq x >= offnext(m(n)) et x mod alignof(m(n+1)) = 0 }
offnext(m(n)) = offset(m(n)) + sizeof(m(n))

Comme vous pouvez le voir, offnext(m(n)) est l'offset de la première place disponible dans la structure après le membre m(n).

Soit structure(m) la structure dont les membres sont les m(n) :

alignof(structure(m)) = PPCM(alignof(m(n))) (pour 0<=n<N)
sizeof(structure(m)) = min { x tq x >= offnext(m(N)) et x mod alignof(structure(m)) = 0 }

Puisque les alignements sont des puissances de 2, on a:
PPCM(alignof(m(i))) = max(alignof(m(i)))
et donc
alignof(structure(m)) = max(alignof(m(i)))

La définition de sizeof(structure(m)) équivaut à ajouter à la structure un membre qui serait la structure elle-même, après son dernier membre, et à calculer l'offset de ce membre inventé, formellement :

soit m' tq
m'(n) = m(n) (pour 0<=n<N)
m'(N) = structure(m)
et
s'(m) = structure(m')

on voit que sizeof(structure(m)) = offset(m'(N))

(J'espère ne pas m'être emmêlé dans mes notations.:?)

Ce qui nous donne :

Code:

---

1 2 3 4 5 6

membre type taille alignement offset offnext c char 1 1 0 1 i int 4 4 4 8 c2 char 1 1 8 9   invent MyStruct1 4 12

---

(invent est le membre inventé)
(Désolé, je ne sais pas comment faire un vrai tableau.)

Finalement :
alignof(MyStruct1) = 4
sizeof(MyStruct1) = 12

Citation:

---

Envoyé par babar63

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#pragma pack( push, 1 )   struct MyStruct2 { char c; int i; char c2; char unused[2]; };   #pragma pack( pop )

---

---

Je suppose qu'on défini un alignement de 1. C'est à dire que le compilateur n'aligne plus rien, ça ne veut pas dire que le processeur va changer d'avis sur l'alignement.

Citation:

---

Envoyé par babar63

Code:

---

1 2 3 4 5 6 7 8

int main(int argc, char *argv[]) { cout << "size of MyStruct1 :" << sizeof(MyStruct1)*8 << endl; cout << "size of MyStruct2 :" << sizeof(MyStruct2)*8 << endl;   system( "pause" ); return 0; }

---

Resultat : Conclusion : le compilateur aligne mais pas de manière optimal :mouarf:

---

Pourquoi pas optimale? Tu peux préciser ce qui ne va pas?

Et pourquoi donner les résultats en bits en pas en octets?

Les deux structures crees devaient stocker deux char et un int, dans le premier cas, en laissant le compilateur aligner, la taille de la structure est de 96bits. Dans le second cas en alignant moi-meme(char unused) j'obtiens 64bits, c'est pour ca que j'ai dit que le compilateur n'alignait pas de maniere optimale... si je remplace la premiere structure :

Code:

---

1 2 3 4 5 6

struct MyStruct1 { char c; char c2; int i; };

---

La taille passe a 64bits...

Pourquoi en bit... je travaille sur une platforme 32bits et a moins d'avoir rien compris une structure alignee signifie que la taille est multiple de 32bits...voila pourquoi, je me trompe?

NOTE : C'est vrai que les notations donne mal au crane mais le tableau aide bien encore merci de te donner autant de mal

NOTE : Desole pour les accents je suis sur qwerty :cry:

Citation:

---

Envoyé par babar63

Les deux structures crees devaient stocker deux char et un int, dans le premier cas, en laissant le compilateur aligner, la taille de la structure est de 96bits. Dans le second cas en alignant moi-meme(char unused) j'obtiens 64bits, c'est pour ca que j'ai dit que le compilateur n'alignait pas de maniere optimale...

---

Dans le second cas si j'ai bien compris le pragma tu désactive l'alignement par le compilateur! Bien sûr que c'est plus compact!

Citation:

---

Envoyé par babar63

Pourquoi en bit... je travaille sur une platforme 32bits et a moins d'avoir rien compris une structure alignée signifie que la taille est multiple de 32bits...voila pourquoi, je me trompe?

---

Tu n'as effectivement rien compris... désolé. Le problème c'est la notion d'alignement. L'arrangement des membres d'une structure vient après.

Qu'est-ce que signifie "processeur 32 bits", c'est une question que je me pose depuis que je suis petit (mais à l'époque c'était surtout "console 16 bits"). En fait, cela peut vouloir dire plein de choses :
- que les registres font x bits
- que les registres de donnée font x bits, que l'UAL calcule sur x bits
- que les registres d'adresse font x bits, que l'espace d'adressage fait 2**x
- que le bus mémoire fait x bits, que x bits peuvent être écrit atomiquement dans la mémoire
(Attention : les affirmations séparées par des virgules ne sont pas équivalentes.)

Si tu y réfléchi, tu remarquera une discrimination implicite contre les flottants en faveur des entiers, des pointeurs, ou des registres généraux. Tu parles d'architecture 32 bits, mais sur x86 les registres flottants font 80 bits ("flottants étendus"). Pourquoi pas "processeur 80 bits"?

Que je saches (et je ne veux pas le savoir!), certains registres généraux x86 de 32 bits se divisent en 2 registres de 16 bits utilisables indépendamment. (On a alors plus de registres, sur un processeur qui en manque cruellement.) Je défendrais donc le point de vue selon lequel c'est un processeur 16 bits.

Mais sur ce même processeur (de très loin le plus étrange que je connaisse), il existe un multitude de façons d'adresser la mémoire (j'exagère à peine), dont un mode, je crois, permet d'adresser 48 bits. Va t-on parler de processeur 48 bits? (Ici on voit que l'espace mémoire adressable n'est pas équivalent à la taille des registres.)

Juste pour montrer qu'on peut tout dire et son contraire.

Plus on y réfléchi, plus on se dit que "architecture x bits", "processeur x bits" est un slogan technico-commercial qui ne veut strictement rien dire, à part que quelque part, dans le système, un traitement se fait sur x bits, ou un registre a une taille de x bits. La belle affaire!

Après, Intel 32 bits peut être une façon de différencier les processeurs compatibles 8086 et la nouvelle architecture Intel explicitement parallèle ia64. Donc un nom de produit sans plus de signification que "mt68040" (qui n'a pas 68040 transistors).

Revenons à nos moutons : qu'est-ce que l'alignement? Je vais prendre le cas des architecture d'ordinateurs personnels, à l'exclusion d'autres cas que tu n'es pas près de rencontrer.

L'alignement est une contrainte qu'impose le processeur sur les accès mémoire : il veut que l'adresse utilisée pour certains accès à plusieurs octets soit alignée.

Déjà, rappelons que l'adressage se fait au niveau des octets. C'est à dire que l'unité dans une adresse c'est l'octet : on ne peut pas désigner un bit, ou un demi-octet avec un adresse.

Il faut savoir que, même si RAM permet la modification d'un seul octet à la fois, elle est organisée par unités de 32 ou 64 bits (selon architecture). Ce qui permet aussi de lire ou d'écrire 32 ou 64 bits d'un coup, mais à condition qu'ils soient "d'un bloc", stoqués ensemble. Par exemple, pour lire un "mot", il voudra que l'accès se fasse sur un "mot mémoire" entier, pas à cheval entre deux. Les adresses multiples de cette taille sont donc au début d'un bloc qui peut être manipulé d'un seul coup. Pour lire le même nombre de bits non-alignés sur cette frontière de "blocs", il est nécessaire de faire plusieurs accès.

Bien sûr, tu ne travaille pas directement au niveau de la RAM mais au niveau du processeur. Lui aussi va imposer des contraintes d'alignement.

Si tu accèdes à un "mot", mettons de 32 bits, avec une adresse qui est correctement alignée, c'est à dire qui désigne le premier octet d'un mot mémoire, le processeur n'a qu'à faire un accès à la RAM (ou au cache, peu importe). Si au contraire l'adresse ne désigne pas le premier octet d'un mot mémoire, mais, par exemple le second, et que donc la donnée se trouve à cheval sur deux mots mémoire, certains processeurs vont considérer que c'est une erreur et le système va interrompre ton programme. D'autres (dont x86) vont permettre l'accès en récupérant les deux partie de la donnée et en les assemblant si c'est une lecture, ou bien en découpant la valeur à écrire en deux et en faisant deux écritures partielles. Ceci est deux ou trois fois plus lent qu'un accès aligné, et il n'y aucun chance pour que ça s'améliore : les concepteur de processeur n'ont aucune raison d'optimiser un code qui se moque de l'alignement. (Un tel code ne cherche manifestement pas la vitesse en premier lieu.)

Il n'est pas évident, d'ailleurs, que permettre les accès non-alignés soit un cadeau au programmeur : si ils sont le résultat d'une erreur de programmation, ou de la méconnaissance d'une notion élémentaire, mieux vaut le signaler que de tolérer, inefficacement, une telle programmation. En général, les architectures très optimisées ne vont pas s'amuser à supporter une telle programmation peu rigoureuse.

Bon, tout ceci portait sur les processeur, et donc la programmation en assembleur; évidemment tu ne programme pas en assembleur, mais en C++. Mais le C++ permet d'utiliser les opérations de base du processeur quand on utilise les types primitifs. Ainsi, int est conçu pour correspondre à un mot processeur, qu'il fasse 16, 32, 64 ou même 36 bits! Donc la contrainte d'alignement est transposée telle-quelle en C++.

Les types de base char, short, int , long, float double et long double sont censées correspondre à des fonctionnalité présentes dans le processeur. Les type structurés (structure, union), eux sont des outils de programmation qui n'ont pas de traduction directe fixée.

Une structure particulière a un alignement, pour les besoins de la cause : elle a des membres, qui sont des types primitifs (ou d'autres structures, qui contiennent des types primitifs, etc.). Ce sont ces membres qui ont besoin d'être alignés. Les structures, en tant que tel, n'ont pas d'alignement particulier.

Par exemple, il n'y a aucune raison d'aligner cette structure:

Code:

---

1 2 3

struct non_aligné { char seul_membre; };

---

parce qu'un char, par définition, n'a pas d'alignement.

Si par contre une structure possède au moins un membre qui a un alignement > 1, la structure est alignée pour que le membre le soit :

Code:

---

1 2 3

struct struct_alignée { int seul_membre; };

---

Sur ton système, ça va donner un alignement de 4 pour struct_alignée. Si on ajoute d'autres membres, il faudra toujours que l'alignement soit au moins 4 (ce qui veut dire multiple de 4).

Si, sur ton système "32 bits", les int font bien 32 bits et ont un alignement de 4, les double en font 64 et je suis quasiment sûr que leur alignement préféré est de 8. De même, il me semble, pour long long (ou _int64 ou je ne sais quoi). Une structure dont un membre a une alignement de 8 devra aussi avoir un alignement de 8.

Déjà un grand merci à toi pour avoir pris la peine de donner une réponse aussi détaillé :merci:

Et puis, en effet..... j'avais rien compris du tout... et même après avoir relu ton message plusieurs fois ce n'est pas forcément évident à assimiler (enfin pour moi en tout cas:?)

Si j'ai à peu près compris, le but de l'alignement et de faire correspondre les structures de données à des mots (mémoire/processeur). La taille de la structure doit quand même au final être multiple de la taille d'un mot, taille qui peut varier et dépend du processeur(Ne travaillant pas sur la RAM).

Certains détails restent flou quand même (:roll:) par exemple :

Code:

---

1 2 3 4 5 6

struct MyStruct1 { char c; int i; char c2; };

---

Le compilateur donne une taille de 12 Octets par défaut, cela signifie bien que le compilateur à aligné sur une base de 4...? Dans ce cas et si je travaille uniquement avec des données codées sur maximum 4 octets toutes mes structures seront alignées...?

Pour ma deuxième structure en revanche je ne suis pas sur de comprendre si elle est aligné ou pas(dans mon cas) :

Code:

---

1 2 3 4 5 6 7 8 9

#pragma pack( push, 1 ) struct MyStruct2 { char c; int i; char c2; char unused[2]; }; #pragma pack( pop )

---

Une autre question, ce problème n'est-il posé (à la base) que par les types prédéfinis, je m'explique : en supposant qu'une structure X est bien aligné, la taille donnée est de...16 Octets..., si maintenant une autre structure Y possèdent l'élément X alors tous les éléments doivent être aligné sur 16Octets...??? Si c'est le cas ça peut vite devenir "non-négligeable" pour des structures de donnée importante (dans le sens ou il faut faire encore plus attention pour aligner ET ne pas gaspiller inutilement de la place).

Enfin pour la route... si tout cela dépend de tout pleins de composants au niveau du hardware, un code ou toutes les structures seraient bien alignées, l'application produite est-elle supposée être aussi rapide sur d'autres machines ou les contraintes d'alignement ne seraient pas respectées?

Encore merci pour ton aide :D