Y a-t-il des inconvénients à passer des structures par valeur en C, plutôt que de passer un pointeur?

Y a-t-il des inconvénients à passer des structures par valeur en C, plutôt que de passer un pointeur?

Si la structure est grande, il y a évidemment l'aspect performant de la copie de beaucoup de données, mais pour une structure plus petite, cela devrait être fondamentalement la même chose que de passer plusieurs valeurs à une fonction.

C'est peut-être encore plus intéressant lorsqu'il est utilisé comme valeur de retour. C n'a qu'une seule valeur de retour des fonctions, mais vous en avez souvent besoin. Une solution simple consiste donc à les mettre dans une structure et à la renvoyer.

Y a-t-il des raisons pour ou contre cela?

Puisque ce dont je parle ici n'est peut-être pas évident pour tout le monde, je vais donner un exemple simple.

Si vous programmez en C, vous commencerez tôt ou tard à écrire des fonctions qui ressemblent à ceci:

void examine_data(const char *ptr, size_t len)
{
    ...
}

char *p = ...;
size_t l = ...;
examine_data(p, l);

Ce n'est pas un problème. Le seul problème est que vous devez convenir avec votre collègue de l'ordre dans lequel les paramètres doivent être afin d'utiliser la même convention dans toutes les fonctions.

Mais que se passe-t-il lorsque vous souhaitez renvoyer le même type d'informations? Vous obtenez généralement quelque chose comme ceci:

char *get_data(size_t *len);
{
    ...
    *len = ...datalen...;
    return ...data...;
}
size_t len;
char *p = get_data(&len);

Cela fonctionne bien, mais est beaucoup plus problématique. Une valeur de retour est une valeur de retour, sauf que dans cette implémentation, ce n'est pas le cas. Il n'y a aucun moyen de dire à partir de ce qui précède que la fonction get_data n'est pas autorisée à regarder vers quoi pointe len. Et rien ne permet au compilateur de vérifier qu'une valeur est effectivement renvoyée via ce pointeur. Donc le mois prochain, quand quelqu'un d'autre modifie le code sans le comprendre correctement (parce qu'il n'a pas lu la documentation?), Il est cassé sans que personne ne s'en aperçoive, ou il commence à planter au hasard.

Donc, la solution que je propose est la structure simple

struct blob { char *ptr; size_t len; }

Les exemples peuvent être réécrits comme ceci:

void examine_data(const struct blob data)
{
    ... use data.tr and data.len ...
}

struct blob = { .ptr = ..., .len = ... };
examine_data(blob);

struct blob get_data(void);
{
    ...
    return (struct blob){ .ptr = ...data..., .len = ...len... };
}
struct blob data = get_data();

Pour une raison quelconque, je pense que la plupart des gens feraient instinctivement examine_data prendre un pointeur vers un blob struct, mais je ne vois pas pourquoi. Il obtient toujours un pointeur et un entier, il est juste beaucoup plus clair qu'ils vont ensemble. Et dans le cas de get_data, il est impossible de gâcher la manière dont j'ai décrit précédemment, car il n'y a pas de valeur d'entrée pour la longueur, et il doit y avoir une longueur retournée.

Pour les petites structures (par exemple point, rect), le passage par valeur est parfaitement acceptable. Mais, mis à part la vitesse, il y a une autre raison pour laquelle vous devriez faire attention en passant / renvoyant de grandes structures par valeur: l'espace de pile.

Une grande partie de la programmation C est destinée aux systèmes embarqués, où la mémoire est limitée, et les tailles de pile peuvent être mesurées en Ko ou même en octets ... Si vous passez ou retournez des structures par valeur, des copies de ces structures seront placées sur la pile, provoquant potentiellement la situation d'après laquelle ce site est nommé ...

Si je vois une application qui semble avoir une utilisation excessive de la pile, les structures passées par valeur sont l'une des choses que je recherche en premier.

Une raison de ne pas faire cela qui n'a pas été mentionnée est que cela peut causer un problème où la compatibilité binaire est importante.

Selon le compilateur utilisé, les structures peuvent être passées via la pile ou les registres en fonction des options / implémentation du compilateur

Voir: http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

-fpcc-struct-return

-freg-struct-return

Si deux compilateurs ne sont pas d'accord, les choses peuvent exploser. Inutile de dire que les principales raisons de ne pas le faire sont illustrées par la consommation de pile et des raisons de performances.

Pour vraiment répondre à cette question, il faut creuser profondément dans la terre de rassemblement:

(L'exemple suivant utilise gcc sur x86_64. N'importe qui est invité à ajouter d'autres architectures comme MSVC, ARM, etc.)

Prenons notre exemple de programme:

// foo.c

typedef struct
{
    double x, y;
} point;

void give_two_doubles(double * x, double * y)
{
    *x = 1.0;
    *y = 2.0;
}

point give_point()
{
    point a = {1.0, 2.0};
    return a;
}

int main()
{
    return 0;
}

Compilez-le avec des optimisations complètes

gcc -Wall -O3 foo.c -o foo

Regardez l'assemblage:

objdump -d foo | vim -

Voici ce que nous obtenons:

0000000000400480 <give_two_doubles>:
    400480: 48 ba 00 00 00 00 00    mov    $0x3ff0000000000000,%rdx
    400487: 00 f0 3f 
    40048a: 48 b8 00 00 00 00 00    mov    $0x4000000000000000,%rax
    400491: 00 00 40 
    400494: 48 89 17                mov    %rdx,(%rdi)
    400497: 48 89 06                mov    %rax,(%rsi)
    40049a: c3                      retq   
    40049b: 0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

00000000004004a0 <give_point>:
    4004a0: 66 0f 28 05 28 01 00    movapd 0x128(%rip),%xmm0
    4004a7: 00 
    4004a8: 66 0f 29 44 24 e8       movapd %xmm0,-0x18(%rsp)
    4004ae: f2 0f 10 05 12 01 00    movsd  0x112(%rip),%xmm0
    4004b5: 00 
    4004b6: f2 0f 10 4c 24 f0       movsd  -0x10(%rsp),%xmm1
    4004bc: c3                      retq   
    4004bd: 0f 1f 00                nopl   (%rax)

À l'exclusion des noplblocs, give_two_doubles()a 27 octets tandis que give_point()a 29 octets. En revanche, give_point()donne une instruction de moins quegive_two_doubles()

Ce qui est intéressant, c'est que nous remarquons que le compilateur a été en mesure d'optimiser movles variantes plus rapides de SSE2 movapdet movsd. De plus, give_two_doubles()déplace réellement les données vers et depuis la mémoire, ce qui ralentit les choses.

Apparemment, une grande partie de cela peut ne pas être applicable dans les environnements embarqués (c'est là que le terrain de jeu pour C est la plupart du temps de nos jours). Je ne suis pas un assistant d'assemblage, donc tout commentaire serait le bienvenu!

La solution simple sera de retourner un code d'erreur comme valeur de retour et tout le reste comme paramètre dans la fonction,
ce paramètre peut être une structure bien sûr mais ne voyez aucun avantage particulier en le passant par valeur, il suffit d'envoyer un pointeur.
Passer une structure par valeur est dangereux, vous devez faire très attention à ce que vous passez, rappelez-vous qu'il n'y a pas de constructeur de copie en C, si l'un des paramètres de structure est un pointeur, la valeur du pointeur sera copiée, cela peut être très déroutant et difficile à maintenir.

Juste pour compléter la réponse (crédit complet à Roddy ), l'utilisation de la pile est une autre raison de ne pas passer la structure par valeur, croyez-moi, le débogage du débogage de la pile est un vrai PITA.

Rejouer pour commenter:

Passer une structure par un pointeur signifie qu'une entité détient un droit de propriété sur cet objet et a une connaissance complète de ce qui doit être libéré et du moment. Passer une structure par valeur crée une référence cachée aux données internes de la structure (pointeurs vers une autre structure, etc.) à ce niveau est difficile à maintenir (possible mais pourquoi?).

Une chose que les gens ici ont oublié de mentionner jusqu'à présent (ou je l'ai négligée) est que les structures ont généralement un rembourrage!

struct {
  short a;
  char b;
  short c;
  char d;
}

Chaque caractère est de 1 octet, chaque court est de 2 octets. Quelle est la taille de la structure? Non, ce n'est pas 6 octets. Du moins pas sur les systèmes les plus couramment utilisés. Sur la plupart des systèmes, ce sera 8. Le problème est que l'alignement n'est pas constant, il dépend du système, donc la même structure aura un alignement différent et des tailles différentes sur différents systèmes.

Non seulement le rembourrage consommera davantage votre pile, mais cela ajoute également l'incertitude de ne pas être en mesure de prédire le remplissage à l'avance, à moins que vous ne sachiez comment votre système se remplit, puis regardez chaque structure que vous avez dans votre application et calculez la taille. pour ça. Passer un pointeur prend une quantité d'espace prévisible - il n'y a pas d'incertitude. La taille d'un pointeur est connue pour le système, elle est toujours égale, quel que soit l'aspect de la structure et les tailles des pointeurs sont toujours choisies de manière à être alignées et ne nécessitent aucun remplissage.

Je pense que votre question résume assez bien les choses.

Un autre avantage du passage des structures par valeur est que la propriété de la mémoire est explicite. On ne se demande pas si la structure provient du tas et à qui incombe la responsabilité de la libérer.

Je dirais que passer des structures (pas trop grandes) par valeur, à la fois en tant que paramètres et en tant que valeurs de retour, est une technique parfaitement légitime. Il faut bien sûr veiller à ce que la structure soit de type POD ou que la sémantique de copie soit bien spécifiée.

Mise à jour: Désolé, j'avais mon cap de réflexion C ++. Je me souviens d'une époque où il n'était pas légal en C de renvoyer une structure à partir d'une fonction, mais cela a probablement changé depuis. Je dirais toujours que c'est valable tant que tous les compilateurs que vous prévoyez d'utiliser prennent en charge la pratique.

Voici quelque chose que personne n'a mentionné:

void examine_data(const char *c, size_t l)
{
    c[0] = 'l'; // compiler error
}

void examine_data(const struct blob blob)
{
    blob.ptr[0] = 'l'; // perfectly legal, quite likely to blow up at runtime
}

Les membres de a const structsont const, mais si ce membre est un pointeur (comme char *), il devient char *constplutôt que ce que const char *nous voulons vraiment. Bien sûr, nous pourrions supposer qu'il consts'agit d'une documentation d'intention et que quiconque enfreint ceci écrit du mauvais code (ce qu'ils sont), mais ce n'est pas suffisant pour certains (en particulier ceux qui viennent de passer quatre heures à rechercher la cause d'un crash).

L'alternative pourrait être de faire un struct const_blob { const char *c; size_t l }et de l'utiliser, mais c'est plutôt compliqué - cela entre dans le même problème de schéma de nommage que j'ai avec typedefles pointeurs ing. Ainsi, la plupart des gens s'en tiennent à n'avoir que deux paramètres (ou, plus probablement dans ce cas, à l'aide d'une bibliothèque de chaînes).

La page 150 du tutoriel d'assemblage PC sur http://www.drpaulcarter.com/pcasm/ explique clairement comment C permet à une fonction de renvoyer une structure:

C permet également d'utiliser un type de structure comme valeur de retour d'une fonction. Evidemment, une structure ne peut pas être retournée dans le registre EAX. Différents compilateurs gèrent cette situation différemment. Une solution courante utilisée par les compilateurs consiste à réécrire en interne la fonction comme une fonction qui prend un pointeur de structure comme paramètre. Le pointeur est utilisé pour placer la valeur de retour dans une structure définie en dehors de la routine appelée.

J'utilise le code C suivant pour vérifier l'instruction ci-dessus:

struct person {
    int no;
    int age;
};

struct person create() {
    struct person jingguo = { .no = 1, .age = 2};
    return jingguo;
}

int main(int argc, const char *argv[]) {
    struct person result;
    result = create();
    return 0;
}

Utilisez "gcc -S" pour générer l'assembly pour ce morceau de code C:

    .file   "foo.c"
    .text
.globl create
    .type   create, @function
create:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $16, %esp
    movl    8(%ebp), %ecx
    movl    $1, -8(%ebp)
    movl    $2, -4(%ebp)
    movl    -8(%ebp), %eax
    movl    -4(%ebp), %edx
    movl    %eax, (%ecx)
    movl    %edx, 4(%ecx)
    movl    %ecx, %eax
    leave
    ret $4
    .size   create, .-create
.globl main
    .type   main, @function
main:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $20, %esp
    leal    -8(%ebp), %eax
    movl    %eax, (%esp)
    call    create
    subl    $4, %esp
    movl    $0, %eax
    leave
    ret
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

La pile avant l'appel crée:

        +---------------------------+
ebp     | saved ebp                 |
        +---------------------------+
ebp-4   | age part of struct person | 
        +---------------------------+
ebp-8   | no part of struct person  |
        +---------------------------+        
ebp-12  |                           |
        +---------------------------+
ebp-16  |                           |
        +---------------------------+
ebp-20  | ebp-8 (address)           |
        +---------------------------+

La pile juste après avoir appelé create:

        +---------------------------+
        | ebp-8 (address)           |
        +---------------------------+
        | return address            |
        +---------------------------+
ebp,esp | saved ebp                 |
        +---------------------------+

Je veux juste souligner l'un des avantages de la transmission de vos structures par valeur, c'est qu'un compilateur d'optimisation peut mieux optimiser votre code.