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