Discussion :

[HanLee]

Salut,

Je sais que pour le moment, la mani�re dont les membres d'une structures sont align�es en C++ est implementation-defined.

Mais j'ai parfois vu que le moteur 3D Irrlicht faisait du code comme �a :

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
struct vector3
{
    float x;
    float y;
    float z;
 
    float const* get() const {
        return &x;
    }
};

Pour que leur vecteur 3D puisse � la fois �tre repr�sent� comme un couple de flottants ou comme un tableau C (un avantage parfois, pour de la concision).

Je me demande si la contiguit� est ici garantie, vu qu'on a bien 3 membres cons�cutifs de m�me type ?

Merci d'avance

[loufoque]

Oui, si j'ai bien interpr�t� la norme.

[Jean-Marc.Bourguet]

Oui, si j'ai bien interpr�t� la norme.

A mon avis il n'y a rien qui autorise a penser que c'est valide dans la
norme actuelle. (Peut-etre dans le draft avec tout le jeu sur la
redefinition des POD, mais c'est quelque chose encore en etat de flux.

En pratique, je ne vois pas de raisons qui pousseraient un compilateur a ne
pas placer les membres comme s'ils etaient dans un tableau. Par contre, je
vois bien l'optimiseur decider que des alias sont impossibles dans ce cas
et donc foutre le bordel dans des cas d'utilisation complexes qui va
disparaitre des qu'on simplifie un peu le test case...

[loufoque]

J'avais conclu une fois que

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
struct
{
    T valeur1;
    T valeur2;
    ...
    T valeurN;
} valeurs;

avait le m�me layout que

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

T valeurs[N];

[bolhrak]

Hello,

Il n'y a � priori aucune garantie (du moins de m�moire), maintenant sous Visual et gcc effectivement l'impl�mentation fait que les membres de 4 octets ou plus sont contig�s en m�moire. Donc � v�rifier pour quel compilo ce code est pr�vu.

Apr�s, m�me si ce code fonctionne, je ne pense pas que l'imiter dans tes propres programmes soit une bonne id�e. Quelque chose du genre :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
class vector3
{
 
public:
 
    float getX() const { return p[0]; }
    float getY() const { return p[1]; }
    float getZ() const { return p[2]; }
 
    const float *const get() const { return p; }
 
    //Le constructeur et/ou les setters qui vont bien
    //....
 
private:
 
    float p[3];
 
};

Fournira les m�mes servies et la m�me souplesse (voire plus puisque tu es moins d�pendant de la mani�re de stocker les membres).

[HanLee]

Il faut s'entendre alors.

Loufoque tu l'as trouv� sur quel partie de la norme ton paragraphe ?

@bolhrak : on sait que c'est d�fini par l'impl�mentation quand les types sont m�lang�s. Ici on a trois du m�me type, et plusieurs posts trouv�s ici et l� sur google tendent � faire penser que quand les types sont homog�nes, c'est contig� mais j'ai pas r�ussi � trouver des r�f�rences valides vers la norme.

Sinon pour ta remarque, une classe de vecteur g�om�trique est quand m�me un cas particulier.

Les classes de vecteurs 2D/3D/4D ne sont pas des vraiment des classes au sens OO du terme, un peu comme std::pair, ce ne sont que des n-uplets tout simples, mais qui respectent certaines r�gles (addition, et tout). Elles sont quasiment tjrs con�ues de la m�me mani�re.

C'est clairement plus pratique et lisible d'�crire .x, .y, .z que des getters/setters, m�me r�duits au minimum (x(), y(), z()).

C'est juste que parfois les interfaces C prennent soit 3 valeurs distinctes, soit un tableau C.

Apr�s, la biblio CGAL fait avec des accesseurs, mais ils ont leurs raisons.

J'avais aussi pens� � mettre le tableau priv�, et mettre des r�f�rences publiques qui s'appeleraient x, y, z pointant vers le bon endroit, mais apr�s la taille de la structure devenait d�raisonnablement grosse pour rien.

[koala01]

Salut,

La norme assure que, si tu copie un objet POD (avec memcpy) dans un tableau de char de taille �gale � celle du POD, puis que tu recopie le tableau de "char" dans un objet POD, tu obtiendra exactement les memes valeurs pour les membres.

Par contre, cela ne veut absolument pas dire que les membres successifs de m�mes types puissent �tre consid�r�s comme contigus en m�moire...

En outre, pour les objet non PODS, voici ce qu'on lit:

Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated
so that later members have higher addresses within a class object. The order of allocation of nonstatic
data members separated by an access-specifier is unspecified (11.1). Implementation alignment requirements
might cause two adjacent members not to be allocated immediately after each other; so might
requirements for space for managing virtual functions (10.3) and virtual base classes (10.1).

Autrement dit:

Si tu as un indicateur d'acces (AKA public: private: protected: ), entre deux membres non statiques, l'alignement est au choix de l'impl�mentation.

En outre, les obligation d'alignement existantes (et qui sont �galement d�pendantes de l'impl�mentation ) font qu'il est tout � fait possible que deux membres de m�me type qui se suivent, sans �tre d�clar�s au sein d'un tableau, peuvent tout � fait ne pas utiliser des adresses contigues

L'un dans l'autre, il semblerait que irrlicht prenne donc certains risques si l'on ne se r�f�re qu'� la norme, et sans pr�juger du compilateur/ de la platteforme avec lequel/sur laquelle elle va tourner