Une structure regroupe un ou plusieurs membres (ou champs), c'est-à-dire un ensemble de variables qui sont constitutives d'une telle structure.
(https://en.cppreference.com/w/c/language/struct) Le mot-clef struct permet d'inventer un nouveau type : struct MyStruct ici.
La définition de ce type revient à déclarer des variables de type quelconque dans la paire d'accolades associée (le point-virgule final est obligatoire)✍.
Ce nouveau type, comme n'importe quel autre, peut ensuite servir à déclarer des variables, des paramètres, le type de retour d'une fonction...
Généralement, une telle définition de structure est placée à l'extérieur de toute fonction, dans un fichier d'en-tête par exemple, mais rien n'empêche d'y avoir recours localement pour un usage très spécifique à une fonction.

Le nom du nouveau type ainsi introduit est composé de deux mots : le mot-clef struct et le nom que nous avons choisi de donner à la structure.
Ceci alourdit l'écriture du code et beaucoup de programmeurs préfèrent désigner le type d'une structure par un mot unique grâce à l'utilisation du mot-clef typedef✍. Dans la pratique, toujours dans un soucis d'économie d'écriture, il est très courant de fusionner ces deux définitions de types (struct et typedef). Remarquez que, dans cette forme, le nom qui suit le mot-clef struct est optionnel.
Il est utile dans le cas d'une structure auto-référencée, comme Node ici, dont un membre est un pointeur vers ce même type : le compilateur ne connaît pas encore le nom attribué avec typedef, le type du membre doit donc utiliser le nom complet de la structure.

Ces nouveaux types étant utilisables comme n'importe quel autre, ils peuvent également servir de membre pour d'autres structures.
Ici une première structure décrit un triplet de réels représentant un vecteur de l'espace tridimensionnel.
Une particule est un type un peu plus élaboré qui contient, en plus de ses propriétés de rayon et de masse, deux tels vecteurs tridimensionnels pour représenter sa position et sa vitesse.
Les variables p1 et p2 de cet exemple sont toutes les deux constituées de toutes ces informations.
Nous constatons ici l'intérêt de cette notion : une structure permet de regrouper dans une même entité logique des données dont la signification serait confuse si elles étaient éparses.

Puisqu'une unique variable de type structure peut être constituée de plusieurs membres, le langage doit proposer une notation pour distinguer chacun d'eux.
L'opérateur . (point) est dédié à ce propos.
(https://en.cppreference.com/w/c/language/operator_member_access) L'usage de cet opérateur est trivial : il désigne le membre dont le nom suit au sein de la variable dont le nom précède.
Chaque membre ainsi désigné est alors vu comme n'importe quelle variable usuelle que l'on peut modifier, consulter, dont on peut prendre l'adresse...
Remarquez que si un membre est lui-même une structure (tel p.vel ici), un emploi supplémentaire de l'opérateur . (point) permet de désigner un membre de cette structure imbriquée.

Les structures étant des variables comme les autres il est tout à fait envisageable d'en relever l'adresse ou de les placer dans un tableau (alloué dynamiquement ou non).
Ceci fait qu'elles peuvent être désignées par des pointeurs.
Il est ainsi possible de déréférencer un tel pointeur pour évoquer la structure désignée, puis d'utiliser l'opérateur . (point) pour accéder à l'un de ses membres.
L'opérateur

->

(flèche) permet toutefois de simplifier l'écriture. Nous constatons ici que l'invocation de pointeur->membre n'est qu'une forme plus lisible pour la notation (*pointeur).membre.
Remarquez que l'opérateur . (point) est plus prioritaire que l'opérateur de déréférencement ce qui imposerait l'usage des parenthèses si nous n'utilisions pas l'opérateur

->

(flèche).

Dans les quelques exemples précédents, toutes nos variables de type structure étaient déclarées sans être initialisées.
Elles avaient donc, comme tout autre type de variables, une valeur indéterminée à leur apparition ; il nous fallait alors en initialiser tous les membres un à un.
Il existe toutefois une notation qui permet l'initialisation de tous les membres d'une variable de type structure lors de la déclaration ; celle-ci est très proche de ce que nous connaissons à propos de l'initialisation des tableaux (voir cette section).
(https://en.cppreference.com/w/c/language/struct_initialization) Il s'agit en effet d'une liste d'initialisation qui énumère, dans une paire d'accolades et séparées par des virgules, les valeurs initiales dans le même ordre que les membres✍.
Tout comme en ce qui concerne les tableaux, si au moins un membre est spécifié, tous les autres sont implicitement initialisés à zéro.
Les listes d'initialisation des tableaux et des structures peuvent être imbriquées (tableaux de structures, structures imbriquées, structures dont des membres sont des tableaux...).
La liste d'initialisation d'une structure ne peut être utilisée qu'à la déclaration d'une variable et ne peut pas servir à une affectation ultérieure ni comme paramètre effectif d'un appel de fonction.
Ceci est cohérent avec ce ce que nous connaissons à propos de la liste d'initialisation des tableaux.

Les variables de type structure peuvent être directement recopiées comme le sont les types de base ; il s'agit là d'une différence fondamentale avec les tableaux.
Ces recopies peuvent avoir lieu suite à l'usage de l'opérateur d'affectation, à l'occasion d'un passage de paramètre à une fonction, ou encore lors du retour d'un résultat par une fonction. Nous constatons en particulier sur cet exemple que la variable v1 servant de paramètre effectif à l'appel de la fonction n'est pas du tout modifiée malgré la modification du paramètre formel par cette dernière ; il s'agit donc bien d'un passage par valeur contrairement aux tableaux.
Les multiples recopies effectuées transmettent bien les valeurs de tous les membres.

Pour aller encore plus loin sur les points communs et les différences de comportement entre la manipulation de structures et de tableaux, envisageons le cas où un membre d'une structure est un tableau. Ce nouvel exemple reprend le même scénario que le précédent.
Nous constatons que, bien qu'un membre de la structure soit un tableau, la recopie des contenus des structures a bien lieu comme attendu.
Nous en déduisons que si dans une application nous avons besoin de recopier des tableaux dont le nombre d'éléments est bien déterminé à la compilation, nous pouvons contourner la limitation imposée par le langage en inventant un type de structure contenant un tel tableau.
Attention toutefois, ceci n'est vrai que pour les tableaux déclarés avec des crochets : lors de la recopie d'une structure, les membres qui sont des pointeurs sont recopiés comme de simples pointeurs, c'est-à-dire que les données qu'ils désignent ne sont pas recopiées (seule l'adresse qu'ils mémorisent l'est).

Puisqu'une structure peut être constituée de multiples membres, une variable de ce type doit occuper en mémoire un ensemble d'octets suffisant à leur mémorisation.
L'opérateur sizeof, découvert plus tôt, s'applique bien entendu aux types qui sont des structures. La norme impose qu'un char occupe un octet (un byte exactement) et sur la plateforme d'exécution ayant servi à cet exemple nous constatons qu'un int en occupe quatre.
La structure S1 qui est constituée de quatre int et quatre char occupe bien les vingt octets attendus, ce qui semble naturel.
En revanche, la structure S2 qui contient trois char de moins fait également la même taille que S1, ce qui est contre-intuitif.
La structure S3 contient, quant à elle, les mêmes membres que S1 mais disposés dans un ordre différent, ce qui, étonnamment, augmente sa taille.

L'explication de ce phénomène tient dans la notion d'alignement des données.
Tout comme chaque type a une propriété de taille, il a une propriété d'alignement.
Celle-ci traduit le fait qu'une donnée d'un certain type ne peut être située à une adresse quelconque.
De manière générale, en ce qui concerne les types de base, une donnée d'un seul octet n'a aucune contrainte d'adresse, une donnée de deux octets doit être située à une adresse paire, une donnée de quatre octets doit être située à une adresse multiple de quatre, etc.
Toutefois, ces contraintes ne sont pas toujours aussi systématiques et dépendent très fortement du processeur qui exécutera le code✍.
Le compilateur connaît exactement les propriétés spécifiques à la plateforme d'exécution et choisit d'aligner les données en conséquence.
(https://en.cppreference.com/w/c/language/object) Nous constatons ici que les quatre char de la structure S1 ne sont séparés que d'un octet et que les int le sont de quatre.
Dans la structure S2, l'espace entre l'unique char et le premier int est toujours de quatre octets alors qu'un seul octet est utile.
Ceci est dû au fait que le compilateur a décidé d'aligner le prochain int pour qu'il soit situé à une adresse multiple de quatre ; pour ceci il le fait précéder de trois octets de bourrage.
Le cas de la structure S3 est exagérément symptomatique de ce phénomène car l'alternance des types fait que trois octets de bourrage sont systématiquement insérés après chaque char, ce qui conduit à une structure occupant globalement beaucoup plus d'octets que nécessaire.
Le commentaire à la fin de l'exemple précédent propose une représentation symbolique de l'organisation en mémoire de ces trois structures déduite des mesures effectuées.

Remarquez que la structure S3 occupe ici trente-deux octets (voir l'exemple précédent), comme si chaque char consommait l'espace d'un int, alors que le dernier membre est un char (donc suivi d'aucun autre membre de type int).
Les trois derniers octets de bourrage semblent superflus : vingt-neuf octets en tout n'auraient-ils pas été suffisants ?
Le compilateur décide cependant de terminer la structure par du bourrage car de telles structures peuvent être placées dans des tableaux : les membres de chacune d'elles doivent être correctement alignés.
Puisque chaque élément du tableau occupe la taille d'une structure, il faut arrondir cette taille de telle façon que les éléments successifs conservent leur alignement.

Nous retiendrons que la seule chose que nous connaissions sur la disposition des membres d'une structure est leur ordre, mais nous ne pouvons faire aucune supposition quant à l'écart en octet qui les sépare.
Toutefois, nous savons que la taille d'une structure est supérieure ou égale à la somme de la taille de ses membres.
Il est cependant important de chercher à minimiser cette taille, en particulier si nous utilisons des tableaux contenant de nombreuses structures.
En effet, l'accès aux données par le processeur est le facteur le plus limitant en performance pour un programme.
Sur notre exemple, la structure S3 est bien plus volumineuse que la structure S1 alors qu'elle n'apporte aucune information utile supplémentaire : la disposition des membres de la structure S1 est donc la meilleure dans le cas présent✍.
Une règle qui est suivie par beaucoup de programmeurs pour optimiser ce placement sans dépendre des spécificités d'une plateforme particulière consiste à regrouper les membres par type selon l'ordre supposé de leurs tailles (voir cette section).
Par exemple : tous les double, puis les int, puis les char.

Un prétexte très courant pour l'usage d'une structure consiste à définir un type légèrement plus élaboré que les types de base, pour lequel nous fournissons un jeu d'opérations bien spécifiées dans son contexte d'utilisation✍.
Nous reprenons ici le vecteur tridimensionnel déjà abordé.
Les déclarations et définitions de cette structure et de quelques fonctions associées, ainsi qu'un exemple simple d'utilisation sont donnés par ces trois fichiers : L'inclusion du fichier d'en-tête standard

<math.h>

et la modification du fichier GNUmakefile sont nécessaires dans cet exemple car nous utilisons la fonction mathématique standard sqrt() qui calcule la racine carrée d'un réel (ceci sera étudié dans cette section).
Le type réalisé ici peut être vu comme un type numérique étendu (à trois composantes).
Les fonctions associées nous évitent d'avoir à répéter les détails de ces calculs usuels à chaque fois qu'ils sont nécessaires dans l'application.
Puisque ce type a une taille raisonnable, nous n'hésitons pas à en recopier les valeurs et à en produire de nouvelles (comme pour les types de base).
Avec les compilateurs modernes, qui optimisent le code de manière très agressive, cette solution est en effet plus efficace que la manipulation de structures simples par pointeurs✍ ; ce point sera à nouveau discuté plus bas.

Un autre prétexte très courant pour l'usage d'une structure consiste à lui confier la gestion d'une ressource.
À titre d'exemple simpliste, nous utilisons ici un type dédié à la mémorisation d'un nombre variable d'entiers.
Les déclarations et définitions de cette structure et de quelques fonctions associées, ainsi qu'un exemple simple d'utilisation sont donnés par ces trois fichiers. Les fonctions réalisées assurent un invariant (ici le lien entre l'allocation et le nombre d'éléments mémorisés) qui garantit que si la structure est uniquement manipulée par ces fonctions elle restera dans un état cohérent.
L'initialisation préalable et la libération finale sont indispensables au bon fonctionnement.
Il est très important, lors de l'usage d'un tel type de donnée élaboré, de respecter scrupuleusement l'interface de programmation qui lui est associée.
Tout autre intervention non prévue, faisant un usage direct du contenu de la structure, risque de compromettre son intégrité en commettant une infraction à l'invariant.

Voici un programme incorrect qui ne respecte pas l'interface de programmation de ce type. En effet, nous recopions trivialement m1 vers m2 ce qui a pour effet de recopier à l'identique chacun des deux membres✍.
L'un d'eux est un pointeur vers un bloc de données alloué dynamiquement ; nous nous retrouvons donc avec les deux structures dont les pointeurs désignent ce même bloc.
Quand l'un parcourt son contenu pour le modifier, l'autre qui accède aux mêmes données voit alors son contenu également modifié, ce qui n'est absolument pas l'effet voulu.
Lors de la libération des ressources de m1, le bloc mémoire qu'il désigne est rendu au système d'exploitation.
Puisque m2 le désigne également, toutes ses futures opérations manipulent des données qui ne devraient plus lui être accessibles.
À partir de cet instant le comportement du programme devient indéterminé, c'est-à-dire que la moindre opération peut provoquer un effet totalement imprévisible (des calculs incorrects, un plantage...).

C'est pour cette raison que, lorsque nous réalisons une structure qui gère des ressources (mémoire, fichiers...) nous nous interdisons de la transmettre par recopie : nous nous imposons l'usage systématique de pointeurs.
La maîtrise précise des conséquences d'une copie est trop délicate pour prendre le moindre risque (ce problème ne se pose pas avec de simples données numériques).
La plupart des fonctions qui manipulent la structure Mem de notre exemple ont une bonne raison de le faire par l'intermédiaire d'un pointeur puisqu'elles visent à modifier une variable située dans le contexte appelant (voir cette section).
En revanche, pour quelques autres (Mem_count(), Mem_get() et Mem_show()) aucune modification de la structure n'est envisagée ; nous nous interdisons malgré tout d'avoir recours à une recopie.
Au lieu de cela, nous ajoutons le qualificatif const au pointeur passé en paramètre pour signifier au compilateur (et au lecteur du prototype) qu'aucune modification n'est autorisée sur la structure pointée.

S'imposer l'utilisation systématique des fonctions constituant l'interface de programmation associée à une structure présente un intérêt certain en terme de maintenance du code.
Même si les exemples choisis ici sont volontairement très simples, il n'est pas du tout rare que beaucoup de fonctions servant à manipuler des structures ne consistent qu'en très peu d'opérations.
Les invocations de fonctions ont un coût en temps d'exécution et empêchent le compilateur d'optimiser très efficacement le code ; dans ce cas, l'appel d'une fonction peut se révéler très pénalisant devant le temps nécessaire aux quelques opérations réellement utiles qu'elle doit accomplir.

Pour faire l'économie de ces invocations de fonctions très simples nous pourrions être tentés de recopier leur code à chaque endroit où nous en avons besoin dans l'application.
Ce serait une très mauvaise solution, contraire au principe d'encapsulation, puisque la moindre modification dans la logique de fonctionnement de la structure nécessiterait de multiples interventions dans le code source de l'application pour l'adapter en conséquence.
Toutefois, elle apporterait deux avantages en terme de performances.

Comme vous le verrez dans les matières S5-MIP et S6-MIP de l'ENIB, l'appel à une fonction consiste en la recopie des paramètres effectifs vers les paramètres formels, en un branchement vers la fonction, et en la sauvegarde de quelques registres du processeur.
De manière complémentaire, la sortie d'une fonction consiste en la recopie de son résultat vers le contexte appelant, la restauration des registres sauvegardés et un branchement pour poursuivre l'exécution dans le contexte appelant.
Si nous nous débarrassions de ces deux longues phases pour ne conserver que les quelques opérations utiles qu'elles encadrent nous diminuerions sensiblement le nombre d'instructions exécutées par le processeur, ce qui se traduirait par un gain en temps d'exécution.

De manière encore plus significative, il faut savoir que le compilateur optimise le code exécutable en éliminant et en remaniant les opérations et les précautions dont il est capable de prouver la redondance ou l'inutilité.
Plus nous lui exposons d'informations sur le contexte d'un traitement plus il est capable de prendre des décisions pertinentes et efficaces.
La recopie des seules instructions utiles à notre traitement sur la structure parmi toutes celles du contexte appelant exposerait au compilateur une vision plus large de l'ensemble des traitements sur ces données.
Dans ces conditions il aurait bien plus d'éléments de décision que ce qui lui est perceptible depuis l'intérieur de la fonction, ce qui conduirait à une meilleure optimisation du code exécutable produit.

Depuis sa version C99, le langage C propose le mot-clef inline qui sert à qualifier une fonction afin que le compilateur remplace les appels à celle-ci par une insertion de son code à l'endroit de l'invocation✍.
Dans ces conditions, les deux avantages précédemment exposés deviennent effectifs tout en conservant le principe d'encapsulation qui assure une bonne maintenabilité du code.
Pour que cela soit possible, il ne suffit plus au compilateur de connaître la déclaration de la fonction à l'endroit de l'appel, mais il doit également connaître sa définition complète afin d'en réutiliser le code.
Il s'agit d'un changement de stratégie radical vis-à-vis de la démarche de programmation modulaire dans laquelle seules les déclarations des fonctions sont exposées dans les fichiers d'en-tête (voir ce chapitre).

Désormais, dans un module de code, nous déplacerons vers le fichier d'en-tête la définition des fonctions qui sont qualifiées avec le mot-clef inline.
Seulement, puisqu'un tel fichier d'en-tête peut être inclus depuis plusieurs unités de compilation, une même fonction inline risque de se trouver définie plusieurs fois, dans des modules distincts, au moment de l'édition de liens.
Nous lui ajoutons alors le mot-clef static (dont l'usage sur une fonction a déjà été rencontré dans cette section) pour signifier que cette fonction ne doit pas être visible à l'extérieur de l'unité de compilation ; ses multiples définitions deviennent ainsi indépendantes du point de vue de l'édition de liens.

Le choix entre les fonctions qui méritent d'être qualifiées avec inline static et celles qui garderont leur définition habituelle est une affaire de compromis.
Il ne faut pas abuser de cette possibilité car elle risque d'accroître considérablement la taille du code exécutable généré, ce qui peut aboutir à un ralentissement de l'exécution✍.
Ce choix est très pertinent pour les fonctions très courtes qui ne sont constituées que de quelques instructions très simples.
Celles qui au contraire sont longues ou qui contiennent d'autres appels coûteux ne tireraient aucun bénéfice de cette possibilité qui alourdirait alors inutilement le code exécutable généré.

Voici une nouvelle formulation du fichier d'en-tête dédié aux vecteurs tridimensionnels qui a été présenté plus haut. Dans ce cas simpliste, toutes les fonctions sont qualifiées de inline static puisqu'elles ne contiennent que quelques opérations élémentaires✍.
Cela confirme le fait que le type inventé ici n'est guère plus qu'un type arithmétique.
L'usage des fonctions évite simplement une recopie fastidieuse et source d'erreurs de ce jeu d'opérations usuelles.
Le module en question ne contient donc aucun autre code source que ce fichier d'en-tête.

De la même façon, voici une nouvelle formulation du fichier d'en-tête dédié à la mémorisation d'entiers qui a été présenté plus haut. Ici, seules les fonctions dont le code ne contient que peu d'instructions simples ont été qualifiées de inline static.
Bien que nous ne fassions dans l'immédiat aucun appel aux fonctions déclarées dans le fichier d'en-tête standard

<stdlib.h>

(nous le ferons dans les autres fonctions), nous l'incluons pour rendre la macro NULL accessible.
Le fichier de définition, quant à lui, se retrouve soulagé des fonctions que nous avons précédemment déplacées. Il ne reste ici que les fonctions qui font usage des fonctionnalités standards d'allocation dynamique de mémoire et d'affichage ; elles sont effectivement réputées coûteuses en temps d'exécution.

L'utilisation qui peut être faite de la nouvelle formulation de ces trois fichiers est strictement identique à celle que nous faisions de leur version précédente.
Dans cette section et celle-ci, nous discutions également des critères pour décider de transmettre les structures par valeur ou par adresse aux fonctions.
Au delà de ce que ces choix impliquent en terme d'expressivité (possibilité de modifier ou non une variable du contexte appelant), nous nous interrogions sur le coût des recopies par rapport à celui des indirections.
Dans le cas des fonctions inline ce problème de coût est complètement évacué puisqu'il n'y aura aucun appel donc aucun passage de paramètre.
Le compilateur aura directement connaissance du paramètre effectif : il provoquera sa modification directe si c'était l'effet attendu d'un passage par adresse et s'en gardera dans le cas d'un passage par valeur.