Discussion :

[Malick]

Mise à jour de la FAQ C
Avec désormais une sélection des cent quatre-vingt-une (181) meilleures réponses à vos questions

Chers membres du club,

j'ai l'immense plaisir de vous annoncer la mise à jour de la FAQ C avec une sélection des cent quatre-vingt-une meilleures réponses à vos questions pour apprendre la programmation avec ce langage.

Les nouveaux Q/R portent essentiellement sur les nouveautés de C11 par rapport à C99.

• Qu’est-ce que le C11 ?
• Quel est l'état du support de la norme C11 par les compilateurs ?
• Quelles sont les nouveautés de C11 ?
• Qu’est-ce que l’alignement mémoire ?
• Qu’est-ce que le multithreading ?

Le chargement des données d'un fichier texte dans une structure

• Comment charger les données d'un fichier texte dans une structure ?

Ce nombre est appelé à évoluer avec vos différentes contributions.

Nous remercions LittleWhite, Matt_Houston et Winjerome pour leur engagement dans la rédaction et la relecture technique. Nos reconnaissances également à Claude LELOUP pour les corrections orthographiques.

Vous pouvez aussi contacter l'équipe de rédaction

.

[picodev]

Bonjour,
concernant les «implémentations» complètes de C11 il faut citer les couples compilateurs/bibliothèque standard.
Le couple gcc/musl est une implémentation de C11, au même titre que gcc/glibc (aux threads près si je ne me trompe pas).

En tout cas bravo pour la mise à jour qui était nécessaire

[sambia39]

Bonsoir
Dans la section FAQ C Comment charger les données d'un fichier texte dans une structure ? pourquoi utiliser un assert ?
Enfin (rien ne vous oblige), mais personnellement, je trouve qu’il n’est pas correct d’utiliser assert dans le cas présent surtout si l’objectif du FAQ est de fournir une réponse correspondant la questions récurrentes posées.

Je suis d’avis à connaître la raison d’un échec d’appel d’une fonction, mais de là a utilisé une fonction qui a pour rôle ou un des rôles la détection d’erreur de programmation lors de débogage et interrompre le programme en renvoyant une terminaison anormale du programme en question; est excessive.

Je pense qu’il est préférable d’utiliser un retour d’erreur que assert. Je m’explique : le retour d’erreur met en évidence une mauvaise utilisation de la fonction à cause d’un paramètre erroné (Exemple à cause d’une ouverture de fichier qui a échoué, ou autres, etc..), ce qui permet alors de prendre les mesures nécessaires pour traiter l’erreur et terminer le programme proprement.
"assert" est utilisé (dans mon cas) quand on se rend compte de l’instabilité du programme ou lorsque l’on fait du débogage en clair "assert" doit être utilisé que pour des circonstances ne devant jamais ce produire durant l’exécution normale d’un programme c’est un outil de débogage et non une méthode, routine ou fonction de sortie d’erreur de plus la gestion d’erreur doivent impérativement être faites uniquement par le programme Dans l’exemple fournir il ne s’agit strictement pas d’un bogue..
Admettant que l’on compile avec -DNDEBUG pensez-vous que le programme final soit correct (et portable) ?.

Ceci dit la mise à jour de la FAQ était essentielle
à bientôt

[picodev]

@sambia39: tout à fait. assert = à utiliser uniquement lors du développement pour traquer les erreurs d'utilisations de l'API par exemple, à ne jamais utiliser en version release pour traquer les erreurs runtime.
Un exemple plus correct remplacera l'assertion

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

assert(f != NULL);

par un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (f==NULL) {
  perror("fopen");
  exit(EXIT_FAILURE);
}

Comme on est en C11 on peut aussi utiliser les designated init :

au lieu de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

t_capteur c = { 0, "", 0.0f };

on pourra préférer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

t_capteur c = { .id=0, .nom="", .valeur=0.0f };

Dans compte = fscanf(f, "%d-%[^:s]:%f\n", &(c.id), c.nom, &(c.valeur)); le parenthésage n'est pas nécessaire la priorité de l'opérateur . étant supérieure à celle de l'opérateur & unaire. Mais bon ce n'est qu'un détail.

[sambia39]

@picodev: Proposition d'exemple plus correct est correcte
à bientôt

[Matt_Houston]

Effectivement l'assert ne devrait pas être utilisé pour traiter un échec de fopen, bien vu sambia.

Je ne suis pas totalement d'accord - c'est mineur, mais la FAQ C est précisément l'endroit pour chipoter ! - avec la solution de remplacement proposée par picodev :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (f==NULL) {
  perror("fopen");
  exit(EXIT_FAILURE);
}

Ce qui me chiffonne c'est l'usage d'exit : il n'y a pas de raison de « paniquer » ici, de plus nous sommes dans main où l'on peut lui préférer un simple et élégant return. On voit déjà cet appel utilisé à tort et à travers dans les programmes de débutants, autant ne pas encourager cette pratique.

Comme on est en C11 on peut aussi utiliser les designated init :

au lieu de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

t_capteur c = { 0, "", 0.0f };

on pourra préférer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

t_capteur c = { .id=0, .nom="", .valeur=0.0f };

Ça c'est plus une préférence personnelle mais je ne suis pas non plus d'avis d'user et abuser de cette syntaxe, certes souvent pratique mais inutilement grevante lorsqu'il n'y a pas d'ambiguïté comme ici.

[picodev]

Ce qui me chiffonne c'est l'usage d'exit : il n'y a pas de raison de « paniquer » ici, de plus nous sommes dans main où l'on peut lui préférer un simple et élégant return. On voit déjà cet appel utilisé à tort et à travers dans les programmes de débutants, autant ne pas encourager cette pratique.
...

Oui c'est vrai ... un if else c'est mieux. L'important étant sans doute l'utilisation de perror.

Ça c'est plus une préférence personnelle mais je ne suis pas non plus d'avis d'user et abuser de cette syntaxe, certes souvent pratique mais inutilement grevante lorsqu'il n'y a pas d'ambiguïté comme ici.

C'est effectivement surtout utile dans la phase de développement où la composition de structures peut être modifiée, cela permet entre autre d'avoir des warnings pour des structures non complètement initialisée, et d'être certain que «la bonne partie» sera initialisée. Cela permet d'augmenter la lisibilité aussi dans certains cas : un truc = {20,1000,0}; est moins clair qu'un truc = { .temperature=20, .pression=1000, .echantillon=0}; ; pas la peine de retourner voir la définition pour savoir quoi correspond à quoi.
C'est vrai que c'est verbeux pour un programme de 15 lignes, mais dès qu'on doit chercher loin pour avoir la définition c'est mieux.

[sambia39]

Ce qui me chiffonne c'est l'usage d'exit : il n'y a pas de raison de « paniquer » ici, de plus nous sommes dans main où l'on peut lui préférer un simple et élégant return. On voit déjà cet appel utilisé à tort et à travers dans les programmes de débutants, autant ne pas encourager cette pratique.

Disant que le choix entre return et exit est plutôt d’ordre préférentiel, mais je l’admets tout de même qu’on l’utilise à tort. Personnellement, j’utilise la fonction exit uniquement dans le cas où j’ai une erreur irrécupérable qui s’est produite où quand un return de l’information de cette erreur excède plus de 3 niveaux de profondeur de fonction.

à bientôt