Est-il légal d'indexer dans une structure?

Indépendamment de la gravité du code, et en supposant que l'alignement, etc. n'est pas un problème sur le compilateur / la plate-forme, ce comportement est-il indéfini ou cassé?

Si j'ai une structure comme celle-ci: -

struct data
{
    int a, b, c;
};

struct data thing;

Est - il légal d'accès a, bet cque (&thing.a)[0], (&thing.a)[1]et (&thing.a)[2]?

Dans tous les cas, sur chaque compilateur et plate-forme, je l'ai essayé, avec chaque paramètre que j'ai essayé, cela `` fonctionnait ''. Je crains juste que le compilateur ne se rende pas compte que b et thing [1] sont la même chose et que les magasins dans 'b' peuvent être placés dans un registre et que thing [1] lit la mauvaise valeur de la mémoire (par exemple). Dans tous les cas, j'ai essayé, cela a fait la bonne chose. (Je réalise bien sûr que cela ne prouve pas grand-chose)

Ce n'est pas mon code; c'est du code avec lequel je dois travailler, je m'intéresse à savoir si c'est du mauvais code ou du code cassé car les différents affectent mes priorités pour le changer beaucoup :)

Tagged C et C ++. Je m'intéresse surtout au C ++ mais aussi au C s'il est différent, juste pour l'intérêt.

C'est illégal ¹ . C'est un comportement non défini en C ++.

Vous prenez les membres sous forme de tableau, mais voici ce que dit la norme C ++ (c'est moi qui souligne):

[dcl.array / 1] : ... Un objet de type tableau contient unensemble non vide alloué de manière contiguë de N sous-objets de type T ...

Mais, pour les membres, il n'y a pas d' exigence contiguë :

[class.mem / 17] : ...; Les exigences d'alignement d'implémentation peuvent empêcher deux membres adjacents d'être alloués immédiatement l'un après l'autre ...

Alors que les deux guillemets ci-dessus devraient être suffisants pour indiquer pourquoi l'indexation dans un structcomme vous l'avez fait n'est pas un comportement défini par le standard C ++, prenons un exemple: regardez l'expression (&thing.a)[2]- Concernant l'opérateur d'indice:

[expr.post//expr.sub/1] : Une expression suffixe suivie d'une expression entre crochets est une expression suffixe. L'une des expressions doit être une valeur gl de type «tableau de T» ou une valeur pr de type «pointeur vers T» et l'autre doit être une valeur pr d'énumération non cadrée ou de type intégral. Le résultat est de type «T». Le type «T» doit être un type d'objet complètement défini.66 L'expression E1[E2]est identique (par définition) à((E1)+(E2))

Creuser dans le texte en gras de la citation ci-dessus: concernant l'ajout d'un type intégral à un type pointeur (notez l'accent mis ici).

[expr.add / 4] : Lorsqu'une expression de type intégral est ajoutée ou soustraite d'un pointeur, le résultat a le type de l'opérande du pointeur. Si l'expressionPpointe vers l'élémentx[i]d' un objet xtableau avec n éléments, les expressionsP + JetJ + P(oùJa la valeurj) pointent vers l'élément (éventuellement hypothétique)x[i + j] if0 ≤ i + j ≤ n; sinon , le comportement n'est pas défini. ...

Notez l' exigence de tableau pour la clause if ; sinon le contraire dans la citation ci-dessus. L'expression (&thing.a)[2]n'est évidemment pas qualifiée pour la clause if ; Par conséquent, un comportement indéfini.

Sur une note latérale: Bien que j'aie beaucoup expérimenté le code et ses variations sur divers compilateurs et qu'ils n'introduisent aucun remplissage ici, (cela fonctionne ); du point de vue de la maintenance, le code est extrêmement fragile. vous devez toujours affirmer que l'implémentation a alloué les membres de manière contiguë avant de faire cela. Et restez dans les limites :-). Mais son comportement reste indéfini ...

Certaines solutions de contournement viables (avec un comportement défini) ont été fournies par d'autres réponses.

Comme indiqué à juste titre dans les commentaires, [basic.lval / 8] , qui était dans ma précédente édition ne s'applique pas. Merci @ 2501 et @MM

¹ : Voir la réponse de @ Barry à cette question pour le seul cas juridique où vous pouvez accéder au thing.amembre de la structure via ce partenaire.

Non. En C, il s'agit d'un comportement indéfini même s'il n'y a pas de remplissage.

La chose qui cause un comportement indéfini est l'accès hors limites ¹ . Lorsque vous avez un scalaire (membres a, b, c dans la structure) et que vous essayez de l'utiliser comme tableau ² pour accéder à l'élément hypothétique suivant, vous provoquez un comportement indéfini, même s'il se trouve qu'il y a un autre objet du même type à cette adresse.

Cependant, vous pouvez utiliser l'adresse de l'objet struct et calculer le décalage dans un membre spécifique:

struct data thing = { 0 };
char* p = ( char* )&thing + offsetof( thing , b );
int* b = ( int* )p;
*b = 123;
assert( thing.b == 123 );

Cela doit être fait pour chaque membre individuellement, mais peut être placé dans une fonction qui ressemble à un accès à un tableau.

¹ (Extrait de: ISO / CEI 9899: 201x 6.5.6 Opérateurs additifs 8)
Si le résultat pointe un après le dernier élément de l'objet tableau, il ne doit pas être utilisé comme opérande d'un opérateur unaire * évalué.

² (Extrait de: ISO / CEI 9899: 201x 6.5.6 Opérateurs additifs 7)
Pour les besoins de ces opérateurs, un pointeur vers un objet qui n'est pas un élément d'un tableau se comporte comme un pointeur vers le premier élément d'un tableau de longueur un avec le type de l'objet comme type d'élément.

En C ++ si vous en avez vraiment besoin - créez un opérateur []:

struct data
{
    int a, b, c;
    int &operator[]( size_t idx ) {
        switch( idx ) {
            case 0 : return a;
            case 1 : return b;
            case 2 : return c;
            default: throw std::runtime_error( "bad index" );
        }
    }
};


data d;
d[0] = 123; // assign 123 to data.a

il est non seulement garanti de fonctionner, mais l'utilisation est plus simple, vous n'avez pas besoin d'écrire une expression illisible (&thing.a)[0]

Remarque: cette réponse est donnée en supposant que vous avez déjà une structure avec des champs et que vous devez ajouter un accès via un index. Si la vitesse est un problème et que vous pouvez modifier la structure, cela pourrait être plus efficace:

struct data 
{
     int array[3];
     int &a = array[0];
     int &b = array[1];
     int &c = array[2];
};

Cette solution modifierait la taille de la structure afin que vous puissiez également utiliser des méthodes:

struct data 
{
     int array[3];
     int &a() { return array[0]; }
     int &b() { return array[1]; }
     int &c() { return array[2]; }
};

Pour c ++: si vous devez accéder à un membre sans connaître son nom, vous pouvez utiliser un pointeur vers une variable membre.

struct data {
  int a, b, c;
};

typedef int data::* data_int_ptr;

data_int_ptr arr[] = {&data::a, &data::b, &data::c};

data thing;
thing.*arr[0] = 123;

Dans l'ISO C99 / C11, le poinçonnage de type basé sur l'union est légal, vous pouvez donc l'utiliser au lieu d'indexer des pointeurs vers des non-tableaux (voir diverses autres réponses).

ISO C ++ n'autorise pas le poinçonnage de type basé sur l'union. GNU C ++ le fait, en tant qu'extension , et je pense que certains autres compilateurs qui ne supportent pas les extensions GNU en général prennent en charge le poinçonnage de type union. Mais cela ne vous aide pas à écrire du code strictement portable.

Avec les versions actuelles de gcc et clang, écrire une fonction membre C ++ en utilisant a switch(idx)pour sélectionner un membre optimisera les index constants au moment de la compilation, mais produira de terribles asm branchés pour les index d'exécution. Il n'y a rien de mal en soi switch()pour cela; il s'agit simplement d'un bogue d'optimisation manquée dans les compilateurs actuels. Ils pourraient compiler efficacement la fonction switch () de Slava.

La solution / solution de contournement à cela est de le faire dans l'autre sens: donnez à votre classe / structure un membre de tableau et écrivez des fonctions d'accesseur pour attacher des noms à des éléments spécifiques.

struct array_data
{
  int arr[3];

  int &operator[]( unsigned idx ) {
      // assert(idx <= 2);
      //idx = (idx > 2) ? 2 : idx;
      return arr[idx];
  }
  int &a(){ return arr[0]; } // TODO: const versions
  int &b(){ return arr[1]; }
  int &c(){ return arr[2]; }
};

Nous pouvons jeter un œil à la sortie asm pour différents cas d'utilisation, sur l' explorateur du compilateur Godbolt . Ce sont des fonctions System V x86-64 complètes, avec l'instruction RET de fin omise pour mieux montrer ce que vous obtiendriez lorsqu'elles sont en ligne. ARM / MIPS / tout ce qui serait similaire.

# asm from g++6.2 -O3
int getb(array_data &d) { return d.b(); }
    mov     eax, DWORD PTR [rdi+4]

void setc(array_data &d, int val) { d.c() = val; }
    mov     DWORD PTR [rdi+8], esi

int getidx(array_data &d, int idx) { return d[idx]; }
    mov     esi, esi                   # zero-extend to 64-bit
    mov     eax, DWORD PTR [rdi+rsi*4]

Par comparaison, la réponse de @ Slava utilisant un switch()pour C ++ rend asm comme ceci pour un index de variable d'exécution. (Code dans le lien Godbolt précédent).

int cpp(data *d, int idx) {
    return (*d)[idx];
}

    # gcc6.2 -O3, using `default: __builtin_unreachable()` to promise the compiler that idx=0..2,
    # avoiding an extra cmov for idx=min(idx,2), or an extra branch to a throw, or whatever
    cmp     esi, 1
    je      .L6
    cmp     esi, 2
    je      .L7
    mov     eax, DWORD PTR [rdi]
    ret
.L6:
    mov     eax, DWORD PTR [rdi+4]
    ret
.L7:
    mov     eax, DWORD PTR [rdi+8]
    ret

C'est évidemment terrible, comparé à la version de punition de type union basée sur C (ou GNU C ++):

c(type_t*, int):
    movsx   rsi, esi                   # sign-extend this time, since I didn't change idx to unsigned here
    mov     eax, DWORD PTR [rdi+rsi*4]

En C ++, il s'agit principalement d' un comportement non défini (cela dépend de l'index).

De [expr.unary.op]:

Aux fins de l'arithmétique des pointeurs (5.7) et de la comparaison (5.9, 5.10), un objet qui n'est pas un élément de tableau dont l'adresse est prise de cette manière est considéré comme appartenant à un tableau avec un élément de type T.

L'expression &thing.aest donc considérée comme faisant référence à un tableau de un int.

De [expr.sub]:

L'expression E1[E2]est identique (par définition) à*((E1)+(E2))

Et de [expr.add]:

Lorsqu'une expression de type intégral est ajoutée ou soustraite à un pointeur, le résultat a le type de l'opérande du pointeur. Si l'expression Ppointe vers l'élément x[i]d'un objet tableau xavec des néléments, les expressions P + Jet J + P(où Ja la valeur j) pointent vers l'élément (éventuellement hypothétique) x[i + j]if 0 <= i + j <= n; sinon, le comportement n'est pas défini.

(&thing.a)[0]est parfaitement bien formé car il &thing.aest considéré comme un tableau de taille 1 et nous prenons ce premier index. C'est un index autorisé à prendre.

(&thing.a)[2]constitue une violation de la condition que 0 <= i + j <= n, puisque nous avons i == 0, j == 2, n == 1. Construire simplement le pointeur &thing.a + 2est un comportement indéfini.

(&thing.a)[1]est le cas intéressant. Il ne viole en fait rien dans [expr.add]. Nous sommes autorisés à prendre un pointeur au-delà de la fin du tableau - ce qui serait. Ici, nous passons à une note dans [basic.compound]:

Une valeur d'un type pointeur qui est un pointeur vers ou après la fin d'un objet représente l'adresse du premier octet en mémoire (1.7) occupé par l'objet53 ou le premier octet en mémoire après la fin du stockage occupé par l'objet , respectivement. [Remarque: un pointeur au-delà de la fin d'un objet (5.7) n'est pas considéré comme pointant vers un objet non lié du type d'objet qui pourrait être situé à cette adresse.

Par conséquent, prendre le pointeur &thing.a + 1est un comportement défini, mais le déréférencer n'est pas défini car il ne pointe vers rien.

Il s'agit d'un comportement indéfini.

Il existe de nombreuses règles en C ++ qui tentent de donner au compilateur l'espoir de comprendre ce que vous faites, afin qu'il puisse raisonner et l'optimiser.

Il existe des règles concernant l'aliasing (accès aux données via deux types de pointeurs différents), les limites de tableau, etc.

Lorsque vous avez une variable x, le fait qu'elle ne soit pas membre d'un tableau signifie que le compilateur peut supposer qu'aucun []accès basé sur un tableau ne peut la modifier. Il n'est donc pas nécessaire de recharger constamment les données de la mémoire chaque fois que vous l'utilisez; seulement si quelqu'un aurait pu le modifier à partir de son nom .

Ainsi, (&thing.a)[1]le compilateur peut supposer qu'il ne fait pas référence à thing.b. Il peut utiliser ce fait pour réorganiser les lectures et les écritures thing.b, invalider ce que vous voulez qu'il fasse sans invalider ce que vous lui avez réellement dit de faire.

Un exemple classique de ceci est de rejeter const.

const int x = 7;
std::cout << x << '\n';
auto ptr = (int*)&x;
*ptr = 2;
std::cout << *ptr << "!=" << x << '\n';
std::cout << ptr << "==" << &x << '\n';

ici, vous obtenez généralement un compilateur disant 7 puis 2! = 7, puis deux pointeurs identiques; malgré le fait qui ptrpointe vers x. Le compilateur prend le fait qu'il xs'agit d'une valeur constante pour ne pas prendre la peine de la lire lorsque vous demandez la valeur de x.

Mais lorsque vous prenez l'adresse de x, vous la forcez à exister. Vous rejetez ensuite const et vous le modifiez. Ainsi, l'emplacement réel en mémoire où il xa été modifié, le compilateur est libre de ne pas le lire réellement lors de la lecture x!

Le compilateur peut devenir assez intelligent pour comprendre comment éviter même de suivre ptrpour lire *ptr, mais ce n'est souvent pas le cas. N'hésitez pas à utiliser ptr = ptr+argc-1ou à utiliser une telle confusion si l'optimiseur devient plus intelligent que vous.

Vous pouvez fournir une personnalisation operator[]qui obtient le bon article.

int& operator[](std::size_t);
int const& operator[](std::size_t) const;

avoir les deux est utile.

Voici un moyen d'utiliser une classe proxy pour accéder aux éléments d'un tableau de membres par nom. Il est très C ++ et n'a aucun avantage par rapport aux fonctions d'accesseur renvoyant ref, sauf pour la préférence syntaxique. Cela surcharge l' ->opérateur pour accéder aux éléments en tant que membres, donc pour être acceptable, il faut à la fois ne pas aimer la syntaxe des accesseurs ( d.a() = 5;), ainsi que tolérer l'utilisation ->avec un objet non pointeur. Je pense que cela pourrait également dérouter les lecteurs qui ne sont pas familiers avec le code, donc cela pourrait être plus une astuce intéressante que quelque chose que vous souhaitez mettre en production.

La Datastructure de ce code inclut également les surcharges pour l'opérateur d'indexation, à des éléments indexés d'accès à l' intérieur de son arélément de réseau, ainsi que beginet les endfonctions, par itération. En outre, tous ces éléments sont surchargés de versions non const et const, qui, à mon avis, devaient être incluses par souci d'exhaustivité.

Lorsque Data's ->est utilisé pour accéder à un élément par son nom (comme ceci:) my_data->b = 5;, un Proxyobjet est renvoyé. Puis, comme cette Proxyrvalue n'est pas un pointeur, son propre ->opérateur est appelé automatiquement en chaîne, qui renvoie un pointeur sur lui-même. De cette façon, l' Proxyobjet est instancié et reste valide pendant l'évaluation de l'expression initiale.

La construction d'un Proxyobjet remplit ses 3 membres de référence a, bet cselon un pointeur passé dans le constructeur, qui est supposé pointer vers un tampon contenant au moins 3 valeurs dont le type est donné comme paramètre de modèle T. Ainsi, au lieu d'utiliser des références nommées qui sont membres de la Dataclasse, cela économise de la mémoire en remplissant les références au point d'accès (mais malheureusement, en utilisant ->et non l' .opérateur).

Afin de tester dans quelle mesure l'optimiseur du compilateur élimine toutes les indirection introduites par l'utilisation de Proxy, le code ci-dessous comprend 2 versions de main(). La #if 1version utilise les opérateurs ->et [], et la #if 0version exécute l'ensemble de procédures équivalent, mais uniquement en accédant directement Data::ar.

La Nci()fonction génère des valeurs entières d'exécution pour l'initialisation des éléments du tableau, ce qui empêche l'optimiseur de simplement brancher des valeurs constantes directement dans chaque std::cout <<appel.

Pour gcc 6.2, en utilisant -O3, les deux versions de main()génèrent le même assembly (basculez entre #if 1et #if 0avant le premier main()à comparer): https://godbolt.org/g/QqRWZb

#include <iostream>
#include <ctime>

template <typename T>
class Proxy {
public:
    T &a, &b, &c;
    Proxy(T* par) : a(par[0]), b(par[1]), c(par[2]) {}
    Proxy* operator -> () { return this; }
};

struct Data {
    int ar[3];
    template <typename I> int& operator [] (I idx) { return ar[idx]; }
    template <typename I> const int& operator [] (I idx) const { return ar[idx]; }
    Proxy<int>       operator -> ()       { return Proxy<int>(ar); }
    Proxy<const int> operator -> () const { return Proxy<const int>(ar); }
    int* begin()             { return ar; }
    const int* begin() const { return ar; }
    int* end()             { return ar + sizeof(ar)/sizeof(int); }
    const int* end() const { return ar + sizeof(ar)/sizeof(int); }
};

// Nci returns an unpredictible int
inline int Nci() {
    static auto t = std::time(nullptr) / 100 * 100;
    return static_cast<int>(t++ % 1000);
}

#if 1
int main() {
    Data d = {Nci(), Nci(), Nci()};
    for(auto v : d) { std::cout << v << ' '; }
    std::cout << "\n";
    std::cout << d->b << "\n";
    d->b = -5;
    std::cout << d[1] << "\n";
    std::cout << "\n";

    const Data cd = {Nci(), Nci(), Nci()};
    for(auto v : cd) { std::cout << v << ' '; }
    std::cout << "\n";
    std::cout << cd->c << "\n";
    //cd->c = -5;  // error: assignment of read-only location
    std::cout << cd[2] << "\n";
}
#else
int main() {
    Data d = {Nci(), Nci(), Nci()};
    for(auto v : d.ar) { std::cout << v << ' '; }
    std::cout << "\n";
    std::cout << d.ar[1] << "\n";
    d->b = -5;
    std::cout << d.ar[1] << "\n";
    std::cout << "\n";

    const Data cd = {Nci(), Nci(), Nci()};
    for(auto v : cd.ar) { std::cout << v << ' '; }
    std::cout << "\n";
    std::cout << cd.ar[2] << "\n";
    //cd.ar[2] = -5;
    std::cout << cd.ar[2] << "\n";
}
#endif

Si la lecture des valeurs est suffisante et que l'efficacité n'est pas un problème, ou si vous faites confiance à votre compilateur pour bien optimiser les choses, ou si struct ne fait que 3 octets, vous pouvez le faire en toute sécurité:

char index_data(const struct data *d, size_t index) {
  assert(sizeof(*d) == offsetoff(*d, c)+1);
  assert(index < sizeof(*d));
  char buf[sizeof(*d)];
  memcpy(buf, d, sizeof(*d));
  return buf[index];
}

Pour la version C ++ uniquement, vous voudrez probablement l'utiliser static_assertpour vérifier que la disposition struct dataest standard, et peut-être lancer une exception sur un index non valide à la place.

C'est illégal, mais il existe une solution de contournement:

struct data {
    union {
        struct {
            int a;
            int b;
            int c;
        };
        int v[3];
    };
};

Vous pouvez maintenant indexer v: