FAQ CConsultez toutes les FAQ

Nombre d'auteurs : 27, nombre de questions : 175, dernière mise à jour : 17 décembre 2010  Ajouter une question

 

Cette FAQ a été réalisée à partir des questions fréquemment posées sur les forums de www.developpez.com et de l'expérience personnelle des auteurs.

Je tiens à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes ; les auteurs font le maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez devenir rédacteur, lisez ceci .

Sur ce, je vous souhaite une bonne lecture.


SommaireDivers bisDivers (5)
précédent sommaire
 

Le langage C exige une grande rigueur lors de l'écriture du code. Il peut être fastidieux de vérifier que toutes les variables sont correctement initialisées, ou encore détecter les erreurs tel que la confusion entre le opérateur = et ==. Heureusement, le compilateur gcc est capable de détecter ce genre d'erreur, il suffit pour cela de lui passer un certain nombre d'arguments. Voici la ligne de commande type qui permet de faire du code conforme à la norme ANSI (C89) et de corriger un grand nombre de comportements indéfinis :

Code C : Sélectionner tout
-O2 -Wall -W -Werror -ansi -pedantic
Cependant ces options peuvent être trop contraignantes : par exemple, avec GTK+ les prototypes des fonctions callback sont imposés, mais il se peut que tous les arguments ne vous servent pas dans la fonction, dans ce cas gcc refusera de compiler votre code. Pour pallier ce problème, utilisez plutôt les options :

Code C : Sélectionner tout
-O2 -Wall -Werror -ansi -pedantic
Notons que ces options forcent le compilateur à passer en mode "C89 strict", pour pouvoir utiliser le mode « C99 », il faut remplacer -ansi par -std=c99, la ligne d'option devient donc :

Code C : Sélectionner tout
-O2 -Wall -Werror -std=c99 -pedantic
Contrairement à ce que son nom peut laisser penser, -Wall n'active pas tous les warning mais tous ceux jugés importants par l'équipe de gcc.

Mis à jour le 11 septembre 2006 Anomaly gege2061 gl

GCC Home Page

Il signifie la plupart du temps que la fonction ou la macro en question n'est pas standard (donc pas très portable…). Plus précisément, qu'elle fait partie de la version de la bibliothèque standard proposée par l'environnement que vous utilisez mais qu'elle n'est pourtant pas reconnue par la norme. Par exemple, les fonctions et macros DOS/Windows _getch, _kbhit, _spawn*, _P_WAIT, etc. font partie de la bibliothèque du C (appelée CRT sous Windows pour C Run-Time Library) alors qu'elles ne sont pas standard, d'où l'underscore. Cette règle de l'underscore ne s'applique toutefois bien évidemment pas aux fonctions des bibliothèques tierces qui accompagnent le compilateur (APIs du système et autres bibliothèques spécifiques). Par exemple, sous les systèmes supportant POSIX (c'est-à-dire UNIX et tous ses clones), les fonctions read, write, exec* font partie de l'API POSIX (on les appelle souvent « appels systèmes » car se sont la plupart du temps des fonctions du système) et non de la bibliothèque du C donc pas besoin d'underscore. L'API POSIX est cependant proposée en tant qu'extension de CRT sous Windows (et elle n'est pas supportée à 100 %…) d'où l'apparition des noms avec underscore (_read, _write, _exec*, etc.).

Cette convention de nommage fut adoptée pour la première fois par le langage C++ et est utilisée aujourd'hui par tous les compilateurs respectant la norme de ce langage (la première version de cette norme date de 1998). Elle n'est pas obligatoire en C, mais beaucoup de compilateurs C (ou C++…) sont en fait des compilateurs C/C++ (c'est-à-dire qu'ils savent compiler aussi bien du code C que du code C++, même si ce sont des langages différents) donc ils appliquent ce système aux deux langages, ce qui n'est pas incompatible avec la norme du C.

Pour les mot-clés non standard, on met deux underscores en avant au lieu d'un seul. Par exemple : __declspec, __stdcall, __asm, __int32, __int64, etc.

Mis à jour le 15 juin 2009 Melem

Cette erreur est due à l'absence de la fonction WinMain(). Cette fonction remplace le main d'un programme C standard dans le cas d'un programme spécifiquement conçu pour Windows. Pour supprimer cette erreur, modifiez le type de votre projet en projet d'application console.

Mis à jour le 7 novembre 2005 gege2061

La norme stipule qu'une ligne complète doit être terminée par un saut de ligne. Ce warning signale que la dernière ligne du fichier n'est pas complète. Pour supprimer ce warning, il suffit de la compléter.

Mis à jour le 7 novembre 2005 gl

Sous Windows, lorsqu'on lance une application console depuis l'interface graphique (c'est-à-dire en double-cliquant), une console se crée pour faire tourner le programme et se détruit aussitôt que ce dernier ait terminé. Pour maintenir la console jusqu'à ce que l'utilisateur tape une touche pour la fermer, il suffit d'ajouter une instruction bloquante juste avant de quitter la fonction main, par exemple à l'aide de system("pause");.

Code C : Sélectionner tout
1
2
3
4
5
6
7
8
9
#include <stdio.h> 
#include <stdlib.h> 
  
int main(void) 
{ 
    printf("Hello World !\n"); 
    system("PAUSE"); 
    return 0; 
}
N.B : Dans certains EDI (Code::Blocks, Visual C++, etc.), la commande 'Lancer' ('Run') qui permet de tester un programme sans quitter l'EDI ne lance pas directement le programme, surtout quand ce dernier est une application console, mais lance un programme qui va à son tour lancer le vôtre puis après que ce dernier ait terminé, affiche un message vous invitant à appuyer sur une touche pour fermer la console. Ce message ne fait donc pas du tout partie de votre programme.

Mis à jour le 30 octobre 2005 Aurelien.Regat-Barrel gl

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2016 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

 
Contacter le responsable de la rubrique C