Accès les membres de la structure, comme si ils sont un seul tableau?

J'ai deux structures, avec des valeurs de calcul réfléchi à un moyen, comme cette version simplifiée:

typedef struct
{
  int v_move, v_read, v_suck, v_flush, v_nop, v_call;
} values;

typedef struct
{
  int qtt_move, qtt_read, qtt_suck, qtd_flush, qtd_nop, qtt_call;
} quantities;

Puis-je les utiliser pour calculer:

average = v_move*qtt_move + v_read*qtt_read + v_suck*qtt_suck + v_flush*qtd_flush + v_nop*qtd_nop + v_call*qtt_call;

Chaque maintenant et eux j'ai besoin d'une autre variable. Maintenant, par exemple, j'ai besoin d'inclure v_clean et qtt_clean. Je ne peux pas changer les structures de tableaux:

typedef struct
{
    int v[6];
} values;
typedef struct
{
    int qtt[6];
} quantities;

Qui simplifierait beaucoup mon travail, mais ils font partie d'une API qui ont besoin de noms de variables pour être clair.

Donc, je suis à la recherche d'un chemin pour accéder aux membres de que les structures, peut-être à l'aide de sizeof(), afin que je puisse les traiter comme un tableau, mais toujours garder l'API immuable. Il est garanti que toutes les valeurs sont int, mais je ne peux pas garantir de la taille d'un int.

Écrit la question est venu à mon esprit... Peut un union faire le travail? Est-il un autre moyen astucieux pour automatiser la tâche de l'ajout d'un autre membre?

Grâce,
Beco

  • Afin de mieux vous aider, nous devons savoir comment l'api est...
  • De l'extérieur, le programmeur doit être autorisé à conserver l'ancien code en cours d'exécution. Que le code à utiliser des lignes comme: v. v_move=1. Cela ne peut pas briser.
  • Un peu compliqué, mais vous pouvez effectuer une itération sur struct champs... regardez cette réponse
  • merci! Très beau travail avec #define. Je pense que ma question est plus facile, car ils sont tous garantis int. Mais néanmoins, il est une astuce il faut garder à l'esprit.
  • Pourquoi ne puis-je pas utiliser const int *qt = &(quantities.qtt_move);? Lors de la compilation de la ligne: qt[i]=3; il retourne une erreur: assignment of read-only location ‘*(qt + (long unsigned int)((long unsigned int)i * 4ul)). Ce n'est pas que je vais changer le pointeur lui-même, mais le déréférencement de certains index!
  • La réponse pour le commentaire ci-dessus (const pointer) peut être trouvé here.

InformationsquelleAutor Dr Beco | 2011-04-02
  1. 8

    Si tous les membres d'une garantie pour être de type int vous pouvez utiliser un pointeur de int et de l'incrémenter:

    int *value = &(values.v_move);
int *quantity = &(quantities.qtt_move);
int i;
average = 0;
//although it should work, a good practice many times IMHO is to add a null as the last member in struct and change the condition to quantity[i] != null.
for (i = 0; i < sizeof(quantities) / sizeof(*quantity); i++)
    average += values[i] * quantity[i];

    (Puisque l'ordre des membres dans une structure est garantie ainsi que l'a déclaré)

    • est-il garanti qu'il n'y a pas de rembourrage entre les champs? semble raisonnable dans ce cas, vous demandez-vous.
    • désolé, qu'est ce qu'un rembourrage? Je pense que cette solution a l'air prometteur.
    • question intéressante. I pense que même le rembourrage ne changera pas dans ce cas, puisque le pointeur doit être augmenté respectivement.
    • Beco: voir le Structure de Données d'Alignement page wikipedia.
    • Juste une chose: comment puis-je sais que le dernier indice? Certains sizeof, peut-être?
    • Beco - dire que vous avez une structure comme celle-ci: {char b; int i;}. le sizeof la structure sera probablement 8 octets (en supposant une machine 32 bits) étant donné que l'ordre des paramètres est déclarée, mais un int doit être de 4 octets alignés. si vous modifiez l'ordre, de la taille de la structure sera probablement 5. essayez-le vous-même.
    • beco - si la taille de la structure est connue du compilateur, que oui, sizeof va faire le travail, voir un petit correctif pour la réponse si.
    • Wow! Super réponse! Merci!
    • Un doute: comment puis-je ajouter une valeur null dans la structure? Je veux dire, les champs sont int, pas de pointeurs. Peut-être un int v_last et de le rendre v_last=0?
    • une struct {int i; char b;} occupe exactement la même taille que l'autre struct {char b; int i;}. Le rembourrage se produit encore, mais à un décalage différent.
    • ce n'est pas nécessairement correcte.
    • Merci, mais puisque tous les membres sont garantis int, je pense que je vais pas avoir le rembourrage des problèmes ici.
    • ce que je trouve dans la Norme est 6.7.2.1/14 "Il y a peut être sans nom rembourrage à la fin d'une structure ou d'une union". L'idée est que chaque élément d'un tableau de struct{int i; char b;} est correctement aligné
    • il ne fonctionne pas... Peut-être que c'est juste une faute de frappe quelque part. Est la ligne sizeof(quantities) / sizeof(*quantity) le même que sizeof(quantities) / sizeof(int)? Sur le dernier champ dans la structure NULL, avez-vous des précisions? Merci.
    • Beco - il doit être le même. Quel est le résultat de cette division? (Je vais être en mesure de vérifier, lorsque je suis à proximité d'un ordinateur)
    • Il est de travail. Le problème était juste quelques fautes (au pluriel et singulier de la confusion). Il me donne 16/4 (pour 4 personnes) et 24/4 (pour 6 personnes), c'est exactement ce qu'il doit faire. Parler des fautes de frappe, la moyenne est de average += value[i] * quantity[i];. Notez le singulier value et la *. Merci! 😉
    • Est-il nécessaire de déclarer la totalité d'entre eux dans plusieurs lignes, chacune ayant ses propres int, c'est à dire int v_move; int v_read; et ainsi de suite? Car à partir de maintenant, j'ai 2 lignes pour les 2 groupes: int stuff1, stuff2, stuff3; int stuff4, stuff5, stuff6;. (Est-ce clair?) Tx
    • J'ai toujours déclarer chaque ligne différents, mais je ne pense pas que c'est nécessaire

    InformationsquelleAutor MByD
  2. 18

    Ce que vous essayez de faire n'est pas possible de le faire en toute élégance. Il n'est pas possible de manière fiable l'accès consécutive, les membres de la structure comme un tableau. Actuellement accepté réponse est un hack, pas une solution.

    La bonne solution serait de passer à un tableau, indépendamment de la quantité de travail qu'il va exiger. Si vous utilisez le protocole enum constantes pour le tableau d'indexation (comme @digEmAll suggère, dans son désormais supprimé de réponse), le nom et le code sera aussi claire que ce que vous avez maintenant.

    Si vous ne voulez pas ou ne pouvez pas passer à un tableau, le seul plus ou moins acceptable moyen de faire ce que vous essayez de faire est de créer un "indice-réseau" ou "map-array" (voir ci-dessous). C++ est un langage dédié fonctionnalité qui vous aide à mettre en œuvre avec élégance - pointeurs-à-membres. En C, vous êtes obligé d'en reproduire le C++ à l'aide d' offsetof macro

    static const size_t values_offsets[] = { 
  offsetof(values, v_move),
  offsetof(values, v_read),
  offsetof(values, v_suck),
  /* and so on */
};

static const size_t quantities_offsets[] = { 
  offsetof(quantities, qtt_move),
  offsetof(quantities, qtt_read),
  offsetof(quantities, qtt_suck),
  /* and so on */
};

    Et si maintenant vous êtes donné 

    values v;
quantities q;

    et index

    int i;

    vous pouvez générer les pointeurs sur des champs individuels comme

    int *pvalue = (int *) ((char *) &v + values_offsets[i]);
int *pquantity = (int *) ((char *) &q + quantities_offsets[i]);

*pvalue += *pquantity;

    Bien sûr, vous pouvez maintenant effectuer une itération sur i en aucune façon que vous voulez. C'est également loin d'être élégant, mais au moins, il porte un certain degré de fiabilité et de validité, par opposition à tout moche hack. Toute chose peut être fait pour regarder plus élégamment en enveloppant la répétition des morceaux dans bien nommé fonctions/macros.

    • Salut @AndreyT C'est vraiment un profond réponse. Merci! Pour une question de simplicité, je vais rester avec le vilain hack, mais je vais apprendre à mes élèves de cette façon correcte. 😀 je suppose que vous de l'utilisation des compensations parce que il n'y a aucune garantie que int *value = &(values.v_move); et value[2] vers le second membre? Est-ce vrai? Même le fait d'avoir que des nombres entiers dans la structure? Merci (BTW: +1!)
    • Considérez-vous que les __attribute__ ((packed)) suggestion de @Jason embellir le vilain hack indiqué par @MByD? Je veux dire, ne le rembourrage et l'alignement de résoudre les problèmes? Souvenez-vous, c'est une structure composée de seulement int, et même si je ne connais pas la taille d'un int dans une machine donnée, sizeof ne. Merci pour vos commentaires.
    • vous pouvez voir à travers supprimé réponses ! :O Eheh, je l'ai supprimé parce que l'OP demande était de conserver la compatibilité de l'API... de toute façon, je suis d'accord cette solution est meilleure que la reconnus 🙂
    • Avec 51K il peut voir à travers notre corps comme superman, x-ray! @digEmAll, je ne peux pas, mais merci d'essayer de l'aider. 🙂
    • Êtes-vous d'avis que *(int *)((char *)&v + sizeof(int)) est OK, mais *((int *)&v + 1) ne l'est pas?
    • Avant la publication de C89, le comportement a été reconnu comme utile sur les plates-formes où la struct membres placés à une compensation. Les compilateurs de ces plates-formes essentiellement à l'unanimité soutenu, et à en juger par le C89 justification il semble probable que les auteurs auraient considéré comme une "extension populaire" de la qualité des compilateurs pour de telles plates-formes seraient soutien de savoir si ou non la Norme obligés de le faire. Certains rédacteurs du compilateur serait plutôt, cette construction comme un "hack" et exiger que les programmeurs d'écrire du code supplémentaire pour travailler autour de son absence que de le soutenir, mais...
    • ...même si un compilateur peut prendre le maladroit solution de code et de le transformer en code machine, l'équivalent de ce que le programmeur voulait écrire en premier lieu, il serait plus efficace en termes à la fois de l'homme et du compilateur effort simplement de reconnaître l'original utile de construire sur les plates-formes où il fait sens.

    InformationsquelleAutor AnT
  3. 6

    Écrit la question est venu à mon esprit... un syndicat de faire le travail? Est-il un autre moyen astucieux pour automatiser la tâche de l'ajout d'un autre membre?

    Oui, un union peut certainement faire le travail:

    union
{
  values v;    /* As defined by OP */
  int array[6];
} u;

    Vous pouvez utiliser un pointeur pour u.values dans votre API, et de travailler avec u.array dans votre code.

    Personnellement, je pense que toutes les autres réponses briser la règle de moins surprise. Quand je vois une plaine struct définition, je suppose que la structure sera l'accès à l'aide de la normale méthodes d'accès. Avec un union, il est clair que l'application va accéder à des moyens spéciaux, qui me demande de payer plus d'attention pour le code.

    • Plus j'étudie ce problème, plus je grandis trouvé cette solution.
    InformationsquelleAutor Lindydancer
  4. 4

    Il sonne vraiment comme si c'était un tableau depuis le debut, avec des méthodes accesseur ou des macros, vous permettant de toujours utiliser des jolis noms comme se déplacer, lire, etc. Cependant, comme vous l'avez mentionné, ce n'est pas faisable en raison de l'API de la rupture.

    Les deux solutions qui me viennent à l'esprit sont:

    • Utiliser un compilateur spécifique de la directive afin de vous assurer que votre structure est emballé (et donc, que la conversion d'un tableau est sûr)
    • Mal de macro à la magie noire.
    • LOL de " Mal de macro à la magie noire.'
    • +1 il y a un ascii émoticône pour le dr. le mal du petit doigt? 🙂
    InformationsquelleAutor hugomg
  5. 3

    ce problème est commun, et a été résolu de plusieurs manières dans le passé. Aucun d'eux n'est totalement sûr ou à nettoyer. Cela dépend de votre particuar application. Voici une liste de solutions possibles:

    1) Vous pouvez redéfinir votre les structures de champs deviennent des éléments de tableau, et utiliser des macros pour mapper chaque élément particulier, comme si c'était un champ de structure. E. g:

    struct values { varray[6]; };
#define v_read varray[1]

    L'inconvénient de cette approche est que la plupart des débogueurs ne comprends pas les macros. Un autre problème est que, en théorie, un compilateur pourrait choisir un autre alignement de la structure d'origine et de la redéfinition, donc la compatibilité binaire n'est pas garanti.

    2) Compter sur le compilateur du comportement et de traiter tous les champs comme s'ils étaient les champs array (oups, pendant que j'écrivais ceci, quelqu'un d'autre a écrit la même +1 pour lui)

    3) créer un tableau statique de l'élément de décalages (initialisé au démarrage) et de les utiliser pour "cartographier" les éléments. C'est assez délicat, et pas si rapide, mais a l'avantage d'être indépendant de la disposition réelle du champ dans la structure. Exemple (incomplet, juste pour des précisions):

    int positions[10];
position[0] = ((char *)(&((values*)NULL)->v_move)-(char *)NULL);
position[1] = ((char *)(&((values*)NULL)->v_read)-(char *)NULL);
//...
values *v = ...;
int vread;
vread = *(int *)(((char *)v)+position[1]);

    Ok, pas du tout simple. Macros comme "offsetof" peut aider dans ce cas.

    • Merci @Giuseppe - mon grand-père du nom! 😉
    • Il ressemble à la troisième solution est liée à la solution donnée par @AndreyT, mais dans une syntaxe différente.
    • Oui. J'ai dû être plus syntetic parce que je voulais signaler, peu de temps le plus commun des solutions au lieu de décrire en profondeur. AndreyT la réponse est beaucoup plus détaillé.
    InformationsquelleAutor Giuseppe Guerrini
  6. 2

    Comment sur l'utilisation de __attribute__((packed)) si vous utilisez gcc?

    De sorte que vous pouvez déclarer vos structures comme:

    typedef struct
{
    int v_move, v_read, v_suck, v_flush, v_nop, v_call;
} __attribute__((packed)) values;

typedef struct 
{
    int qtt_move, qtt_read, qtt_suck, qtd_flush, qtd_nop, qtt_call;
} __attribute__((packed)) quantities;

    Selon le manuel de gcc, vos structures pourront ensuite utiliser la quantité minimale de mémoire possible pour le stockage de la structure, à l'exclusion d'un rembourrage qui auraient normalement été là. Le seul problème serait alors de déterminer la sizeof(int) sur votre plate-forme qui pourrait être fait par un compilateur à l'aide de macros ou <stdint.h>.

    Encore une chose, c'est qu'il y aura une pénalité de performances pour le déballage et le ré-emballage de la structure lorsqu'il doit être accessible et ensuite stockés dans la mémoire. Mais au moins, vous pouvez être assuré alors que le modèle est cohérent, et il peut être consulté comme un tableau à l'aide d'un plâtre pour un type de pointeur comme tu voulais (c'est à dire, vous n'aurez pas à vous soucier de rembourrage gâcher le pointeur de compensations).

    Merci,

    Jason

    • Sonne bien. Je vais regarder plus en détails. Est-ce portable? Merci.
    • +1 Bon conseil qui complète la réponse. Juste que la syntaxe correcte, en raison de typedef est typedef struct { int v_move; ...} __attribute__ ((packed)) values;. Je ne suis pas sûr si ce est portable, parce que le programme s'exécute en plus d'un OS. Merci
    • merci, la syntaxe est fixé maintenant ... aussi loin que la portabilité, j'ai pu le port de ce type de code à n'importe quelle plateforme que gcc prend en charge. Mais comme je l'ai mentionné dans mon post, vous pourriez avoir à utiliser certains compilateur macros, etc. pour vous assurer d'obtenir le sizeof(int) correct pour cette plate-forme spécifique.
    • Ai-je vraiment besoin de le prendre en compte? Ne pas sizeof( int ) toujours dit la vérité sur une machine donnée? sizeof sur wikipedia
    • Il se doit ... et ce n'est pas vraiment dirigé vers vous, c'est à dire, pour quelqu'un de lire ce fil plus tard, qui ne peut pas avoir l'expérience que vous avez, je ne veux pas qu'ils supposent que sizeof(int) est automatiquement 4 octets et commencer à faire des "intelligent" des trucs comme int a = (int)(*((char*)&structure + (4 * offset_value));
    • Yep! De bons conseils.
    • -1 C'est vraiment un mauvais conseils. 1) Il ne permet pas de résoudre le problème d'origine, comme une structure de int:s auront la même disposition de la mémoire comme un tableau de int:s. 2) Il permettra de réduire l'alignement de la structure à 1, forçant le code généré pour accéder aux éléments octet par octet. 3) Les éléments ne pouvant pas être accessible de toute autre manière, par exemple à l'aide d'un int *. 4) Il est GCC spécifiques.
    • Comment pouvez-vous être assuré que une structure de ints auront la même disposition de la mémoire comme un tableau de ints? Il peut y avoir de rembourrage, introduite par le compilateur, et il dépendra de la plate-forme. Donc je ne vois pas comment la #1 et #2 sont assurés par le C99 spec. J'ai aussi mentionné dans le post les mises en garde à l' #3 et #4, c'est-c'était gcc-spécifique et qu'il y aurait une perte de performance en raison de l'emballage. Je ne vois pas pourquoi cela mérite un vote.

    InformationsquelleAutor Jason