Discuter:C (langage)

Un article de Wikipédia, l'encyclopédie libre.

	C (langage) fait partie du projet Informatique, qui a pour but d'enrichir le contenu de Wikipédia sur les sujets liés à l'informatique. Si vous voulez participer, vous pouvez modifier cet article ou visiter la page du projet où vous pourrez vous joindre au projet et consulter la liste des tâches et des objectifs. Le portail informatique pourrait aussi vous intéresser.
B	Cet article a été classé comme d'Avancement B selon le Tableau d'évaluation du projet.
Maximum	Cet article a été classé comme d'Importance maximum selon le Tableau d'évaluation du projet. (Contester?)

	Tâches à accomplir pour C (langage)	modifier • suivre • rafraîchir • aide
	Cliquez sur ce lien rouge pour créer la liste des tâches à accomplir pour cet article ; utilisez une liste à puces, par exemple, puis sauvegardez. Voir aussi la page d'aide.

Est-ce que vous pense que ca vaux le coup de faire des petits articles sur les instructions du language C ? Aoineko

---

a mon avis,non. pour deux raisons 1/ y a plein d'autres vides plus importants dans l'etat actuel du wikipedia français, 2/ plutôt que de s'intéresser aux instructions particulières d'un langage, si populaire et repandu soit-il, il serait peut-etre préférable de développer les concepts algorithmiques sous-jacents, qui concernent les langages procéduraux en général.

... mais ce n'est que mon avis :-) yacc

---

Pareil pour moi : non. Eventuellement des articles sur des types d'instructions que l'on retrouve dans beaucoup de langages (les choix, les branchements,...)

Mokona

---

Selon moi, c'est intéressant, mais pas dans l'article Langage C. Plutôt dans Langage C/Syntaxe. C'est pas mal les sous-articles, qui permettent de faire des articles liés à un article principal, sans encombrer l'article principal de considérations un peu plus pointues. Ensuite, tu fais un lien vers Langage C/Syntaxe dans l'article Langage C, section Voir aussi.
Raph 10:16 fév 27, 2003 (CET)

---

Contrairement à ce que suggère cet article, Dennis M. Ritchie (important développeur des langage B et C), affirme que les opérateurs de préincrémentation et de postincrémentation du langage ne sont pas reliées au PDP-11.

Dans son texte The Development of the C Language il fait le commentaire suivant:

Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1.

Il semble donc que cette phrase de l'article soit basée sur une idée fausse. R4p70r

Effectivement, il faudrait notamment décrire cette idée et sa réfutation par Ritchie dans l'article. Marc Mongenet 10 jan 2005 à 03:24 (CET)

Sommaire 1 Typé 2 Charabia 3 Taille des int avec GCC 4 Suppression des exemples sur les variables et les initialisations 5 Article de qualité? 6 Taille des char 7 Hello world 8 Des sources à l'exécutable 9 Plage d'un short 10 Extremums codable

[modifier] Typé

Quelqu'un peut-il m'expliquer cette phrase ? : "Le langage C est faiblement typé. En conséquence, des entreprises comme EADS/Airbus doivent faire faire le travail de vérification de type par des êtres humains, ce qui coûte relativement cher."

Je m'y connais un peu en C et C++ mais là j'ai rien compris lol. YolanC 15 avr 2005 à 02:24 (CEST)

C est statiquement et faiblement typé. Statiquement : les déclarations de type sont obligatoires pour toutes les variables, Faiblement : C admet des conversions (coercitions de type) implicites dans certains cas (par ex. opérateurs arithmétiques travaillant sur des ints et floats ...). C'est une source potentielle d'erreurs. Cela dit si EADS/Airbus est assez con pour développer en C ça les regarde :)) Aurélien

Que suggères-tu à la place ? (Grand sourire.) David.Monniaux 8 décembre 2005 à 11:39 (CET)

Merci, en plus simple on pourrait dire que les temps de développement sont assez longs car des erreurs pernicieuses peuvent survenir. Non ? Si j'ai bien compris bien sur :P Ou alors simplement remplacer "des êtres humains" par "des programmeurs" YolanC 15 avr 2005 à 14:46 (CEST)

Il me semble que statiquement typé veut dire que les types sont vérifiés à la compilation (ce que fait C) et non à l'exécution. On peut avoir un langage statiquement typé sans déclarer les types des variables. Exemple : Ocaml dont le compilateur déduit les types des variables. CommeCeci 26 jun 2005 à 18:59 (CEST)

Oui. Cf typage statique. Aurélien

[modifier] Charabia

Quelqu'un peut m'expliquer ça :

"L’absence d’ordres spécifiques d’entrée-sortie ou de traitement de chaînes (tout se fait par fonctions) rend le langage très facilement évolutif, mais au détriment de son ergonomie pour le programmeur : multiples parenthèses qui nuisent à la lisibilité."  ????

Si personne ne le fait avant longtemps, je le vire. Aurélien

Je vois très bien ce que ça signifie. J'ai essayé de l'améliorer, mais j'ai pas vraiment réussi. Il faudra ressayer. Marc Mongenet 2 jun 2005 à 16:49 (CEST)

Ahem, tu peux expliquer point par point alors ? 1. "absence d'ordre spécifique d'entrée-sortie" ? 2. "(absence de) traitement de chaînes (tout se fait par fonctions)" ? 3. "... rend le langage très facilement évolutif" ??? 4. "... mais au détriment ... : multiples parenthèse qui nuisent ..." ?????????? Pour 1, je croyais que le C avait, avec la stdio, des opérateurs basiques d'E/S, pour le 2, C n'a pas de vraies chaînes de caractères, seulement des séquences terminées par le car. de val 0, 1 et 2 ne rendent pas C spécialement évolutif à mon avis et effectivement pas trop ergonomique, mais je vois pas du tout le pb. avec les parenthèses ni la remarque "tout se fait par fonctions" ... Aurélien

Pour le 1, C n'a pas d'opérateurs d'entrée-sortie (pourtant C ne manque pas d'opérateurs). Idem pour les chaînes : pas d'opérateurs (quoiqu'on peut utiliser les opérateurs valables sur les pointeurs, mais écrire un truc du genre 3["toto"] hors d'un concours d'obsfucated C, c'est très mal©). Le 3 est subtil : en Pascal (par exemple) il existe des fonctions impossibles à écrire en Pascal (println si ma mémoire ne failli pas). Pas en C. Si printf ne te plaît pas, tu peux très bien écrire un mon_printf et l'utiliser à la place. Cela dit, je me trompe peut-être, mais j'ai l'impression que tu ne connais pas la différence entre opérateur et fonction. Si c'est le cas, il est normal que certains passages d'un article sur un langage de programmation t'apparaissent comme du charabia. Marc Mongenet 28 jun 2005 à 00:31 (CEST)

Si tout ce que tu as a dire concerne la différence entre opérateur et fonctions, il faut le dire. Je constate que tu as modifié dans le bon sens le passage incriminé. Par ailleurs je connait parfaitement la différence *stupide* entre op/fun en C, et l'absence de différence par ailleurs entre opérateurs spéciaux et fonctions en Common Lisp par exemple, qui en fait un très joli langage. Le charabia venait de ta formulation en définitive.

la différence *stupide* entre op/fun en C Cela dit, les parenthèses post-fixées sont l'opérateur C d'appel de fonction (opérateur évidemment surchargeable en C++ :-). Marc Mongenet 28 jun 2005 à 21:39 (CEST)

---

Ne faudrait-il pas rajouter defined() dans la liste des instructions du préprocesseur ? Epeios 8 décembre 2005 à 13:41 (CET)

[modifier] Taille des int avec GCC

Dans l'article on peut lire :

Les variables entières signées de type short int sur 2 octets et long int sur 4 octets, selon votre compilateur les variables int sans le descriptif de taille, prennent soit 2 (Gcc) ou 4 octets (Visual C++, Turbo C++).

J'en doute. Pour tester :

#include <stdio.h>

int main(void)
{
       printf("sizeof(int) : %d\n",sizeof(int));
       printf("sizeof(long) : %d\n",sizeof(long));
       printf("sizeof(short) : %d\n",sizeof(short));
       return 0;
}

Et ça me donne :

gcc -Wall sizeof_int.c -o sizeof_int && ./sizeof_int 
sizeof(int) : 4
sizeof(long) : 4
sizeof(short) : 2

Il me semble plutôt que les int codés sur 2 octets sur les systèmes 16 bits et que c'est passé à 4 octets sur les systèmes 32 bits. D'ailleurs tout peut être sur 32 bits de char à double (cf http://www-s.ti.com/sc/psheets/spru034h/spru034h.pdf page 101, seul long double est en 64bits).

theo 16 janvier 2006 à 20:50 (CET)

En effet, d'après ce que j'ai compris, la norme garantie une taille minimale (mais pas maximale) pour les types. Mais je me trompe peut-être. C'est un peu confu cette histoire...

Concernant la taille d'un int sur une machine 64-bits, il me semble que int vaut toujours 32-bits. A tester. Sanao 16 février 2006 à 16:04 (CET)

La norme garantit un domaine de valeurs minimales pour tous les types "de base" (char, short, int, long, long long et leurs variantes unsigned), cf. 5.2.4.2.1 du document n1124. Toute implémentation est libre de fournir des domaines de valeurs plus larges que les bornes imposées par la norme. Cela permet à un programmeur de savoir que, par exemple, quelque soit la machine, le système d'exploitation, ou le compilateur, il pourra toujours compter sur le type int pour traiter des valeurs comprises entre -32767 et +32678.

La norme ne dit rien sur le résultat de sizeof appliqué à un de ces types, si ce n'est que sizeof(char) doit renvoyer 1, et que le résultat est entier de type size_t. sizeof(long) peut aussi bien valoir 4, 5, 8 ou 100... (ok, 100 est largement impensable sur une machine réelle, mais la norme ne l'interdit pas à ma connaissance)

Par ailleurs, un byte au sens de la norme C n'est pas un octet ! Le byte doit faire au moins 8 bits, mais peut en faire plus. Donc (sizeof(X) == 2) ne signifie pas (forcément) que X fait 16 bits, mais qu'il en fait 2 * CHAR_BIT. (Des DSP ont couremment des bytes de 16 bits, et il me semble avoir lu sur comp.lang.c qu'un Cray a des char de 32 bits).

La norme C99 a aussi introduit le principe des padding bits (6.2.6.2 du n1124) dans les types entiers, qui permet d'avoir des bits inutilises; ce qui veut dire qu'on peut avoir CHAR_BIT == 8, sizeof(int) == 3, et l'int n'occuper que 16 bits...

Par contre, C99 a introduit des types (optionels) qui font exactement N bits, ou N est défini par l'implémentation (7.81.1 du n1124), et sans padding bits. Le résultat de sizeof() appliqué à ces types n'est pas défini dans la norme.

C'est ce genre de choses, mal connues d'un certain nombre de programmeurs C, qui fait que des programmes C sont difficilement portables: ils reposent sur des hypothèses que le langage n'impose pas. --Alveric 1 juin 2006 à 17:21 (CEST)

C'est assez bien vu dans l'ensemble, juste quelques détails (vers la fin) qui me gênent...

Les padding bits n'ont pas été introduits par C99, bien au contraire : la norme C99 limite les possibilités offertes aux implémenteurs dans ce domaine (ainsi, il plus possible d'avoir un nombre baroque de valeurs signées, et la plus grande valeur positive d'un type signé est forcément le prédécesseur d'une puissance de 2); ton exemple avec int de 24 bits dont 16 de significatifs ne me rappelle rien de connu, par contre je connais des DSP avec des long stockés dans 64 bits mais seulement 40 bits significatifs... et il existe des compilateurs C89 pour ces bestiaux-là !

Le résultat de sizeof(intN_t) n'est pas défini explicitement, mais est parfaitement prévisible (N/CHAR_BIT).

La difficulté de porter des programmes C devrait être comparée... à celle du portage avec d'autres langages ! C est réputé au contraire pour être très facile à porter, voire trop. Les incohérences sur les domaines de définitions des types (entre ce que pensait le programmeur initial et la vision qu'en a le compilateur cible) sont parmi les choses les plus faciles à régler, en général par la création d'une floppée de typedef.AntoineL 7 novembre 2006 à 11:02 (CET)

[modifier] Suppression des exemples sur les variables et les initialisations

Bonjour,

J'ai supprimé cette partie car je trouve qu'elle est vraiment trop spécifique et s'attache trop à un point de détail. Des exemples plus précis sur des points essentiels du C sont bien plus pertinents je trouve. J'ai d'ailleurs fait un plan sur les exemples à ajouter :

• les E/S : on présente un peu les affectations de variables avec affichage avec printf() et utilisation des adresses pour scanf()
• les chaînes de caractères : on voit concrêtement les adresses mémoires être utilisées avec un peu d'arithmétique des pointeurs pour se ballader dans la chaînes
• gestion de la mémoire avec malloc() et free() : on touche pour de bon aux pointeurs

Ces trois parties devraient en plus de couvrir quelques opérations de bases que permet la bibliothèque standard, montrer en plus l'utilisation concrète des pointeurs (le point qui fait peur à tout nouveau programmeur C!). Et après, le lecteur n'a plus qu'à faire un tour sur Wikilivres pour en savoir plus.

Si cette suppression dérange quelqu'un, il peut la remettre dans la section Exemples. Mais je n'en vois pas l'utilité. Sanao 28 janvier 2006 à 01:06 (CET)

[modifier] Article de qualité?

Est-ce que vous considérez que l'article est de qualité et que l'on peut le soumettre?

Sinon quelles parties sont à améliorées ou manquantes? Sanao 16 février 2006 à 16:12 (CET)

À voir, j'ai l'impression que cet article est confus, mais en fait il faudrait que je relise le tout. Marc Mongenet 16 février 2006 à 17:09 (CET)

[modifier] Taille des char

J'ai entendu dire qu'une norme (est-ce C89 ou C99, ou bien C++98 ?) impose que sizeof(char) soit strictement égal à 1 (octet). Je n'ai pas réussi à trouver une source qui permette de trancher. Qu'en est-il réellement ? --Acetate 11 mai 2006 à 13:33 (CEST)

Autant que je sache, c'est vrai dans tous ces standards. Une bonne source serait les standards eux-mêmes. Les versions officielles doivent être achetées, mais les versions en préparation sont souvent disponibles sur le Web. Par exemple on peut lire dans le ISO/IEC 9899:TC2 : When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1. Autrement, les FAQ contiennent certainement cette information. Marc Mongenet 12 mai 2006 à 00:58 (CEST)

sizeof(char) doit renvoyer 1 par la norme. Par contre, cela signifie qu'un char tient sur un byte, pas sur un octet. Comme je l'ai dit plus haut, un byte vaut CHAR_BIT bits, qui vaut au moins 8, mais peut-être plus.--Alveric 1 juin 2006 à 17:52 (CEST)

[modifier] Hello world

#include <stdio.h> inclut le fichier d'en-tête stdio.h, contenant les déclarations des fonctions d'entrée-sortie de la bibliothèque standard du C.

Les en-têtes standard ne sont pas forcément des fichiers ! 7.1.2 du n1124:

A header is not necessarily a source file, nor are the < and > delimited sequences in header names necessarily valid source file names.

De plus:

main est le nom de la fonction principale (la première appelée) du programme.

C'est vrai pour les hosted implementations, par forcément pour les freestanding implementations.

La norme ISO exige qu'un code retour soit explicitement renvoyé, ce qui est fait avec le mot clé return qui retournera la valeur 0 (ce qui par convention signifie « aucune erreur »).

La norme ne l'exige pas tout à fait: elle précise que si la valeur de retour d'une fonction qui est déclarée renvoyer quelque chose (autre que void) est utilisée alors qu'elle n'a pas fait de return, alors le comportement est indéfini (6.9.1-12). Par ailleurs, la fonction main est une exception à cette règle, car si elle se termine par l'absence de return, alors un return 0; est implicite (5.1.2.2.3).--Alveric 1 juin 2006 à 17:52 (CEST)

[modifier] Des sources à l'exécutable

Les étapes menant des sources au fichier exécutable sont au nombre de quatre :

La norme (au moins pour C99, je n'ai pas regardé pour le C90) spécifie 8 étapes (5.1.1.2 du n1124). Mais j'admets que décrire toutes les étapes de compilation dans un article introductif au langage C serait de trop (certaines étapes comme la 1 ou la 6 ne sont peut-être pas à détailler ici, par exemple)...

Le préprocesseur produit alors des fichiers intermédiaires (qui ont une extension ".i" sous GCC) pour chaque fichier source (qui ont généralement l'extension ".c"), qui seront utilisés dans l'étape suivante.

La norme C n'impose pas que la chaîne de compilation crée des fichiers temporaires, même si cela se fait usuellement. Un compilateur peut très bien faire tout le travail en mémoire... (mais je chipote, j'admets)--Alveric 1 juin 2006 à 17:52 (CEST)

Tu peux tranquillement améliorer l'article. :-) Il ne faut toutefois pas perdre de vue que cet article est sur le langage C en général, pas seulement sur sa dernière norme. Non pas qu'il faille laisser les erreurs que tu as relevées, loin de là ! Mais il ne faudrait pas que l'article occulte les usages anciens ou non normalisés du C. Marc Mongenet 1 juin 2006 à 18:16 (CEST)

Je pensais justement à l'améliorer, mais je voulais le signaler avant... Et aussi avoir une idée de ce qui devrait être cet article: une présentation "rapide", qui n'apprend pas comment programmer en C (d'autres sources le font déjà très bien), ni se focalise sur la dernière version, mais présente ce qu'il est, à quoi il sert, avantages et inconvénients par rapport à d'autres langages...

Je pensais aussi aggrandir le paragraphe "Normalisations" sur l'historique du processus de normalisation, l'existence d'extensions (POSIX ou autres), les problèmes de portabilités induits, et ajouter un paragraphe sur "comportement défini/indéfini" (c'est une idée de titre, hein) qui explique (à la lumière du paragraphe précédent) pourquoi le C est vu comme un langage difficile et plein de "pièges" (qui pourrait se croiser avec le paragraphe "critiques"): la norme laisse un certain nombre de libertés aux implémentations, donc "ça marche chez moi" ne veut pas dire "c'est correct".

Un autre paragraphe possible (pas forcément volumineux, note) est sur l'utilisation du C en embarqué, et sur la cross-compilation, sachant que ces deux concepts sont prévus et détaillés dans la norme elle-même, et sont des caractéristiques importantes de ce langage. J'y réfléchis...--193.194.132.39 2 juin 2006 à 12:31 (CEST)

L'article n'est pas censé apprendre à programmer en C, de même que l'article sur le Boeing 747 n'est pas censé apprendre à piloter l'avion. :) Ça n'empêche pas qu'il existe un chapitre technique fourni, mais ça ne devrait constituer qu'une partie de l'article fini (qui doit aussi parler des ascendants et descendants de C, des compilateur, de la pénétration dans le marché, des inventeurs, des applications, etc.). Pour les cours complets sur C, il existe aussi un (ou des) projets, par exemple b:Programmation C. Marc Mongenet 3 juin 2006 à 02:13 (CEST)

[modifier] Plage d'un short

Pourtant cela ne fait pas les 65636 possibilités offerte par un short (2^16). De plus, on trouve sur la version anglophone de Wikipédia : « Signed: −32,768 to +32,767 ».

Je testerais les débordements ce soir avec gcc pour être sûr. Sanao 28 septembre 2006 à 17:54 (CEST)

Tu te trompes si tu penses que C stipule qu'un short doit être codé sur 16 bits en complément à deux. Le standard est plus souple et il ne requiert pas le complément à deux. Il dit qu'un short doit au moins permettre de représenter les entiers entre -32767 et +32767 et qu'un unsigned short doit au moins permettre de représenter les naturels entre 0 et 65535. Faire un test avec GCC n'est pas pertinent, car cet article est sur le langage C en général, pas sur une implémentation en particulier. L'article en:Integer (computer science) montre simplement le cas courant, qui est effectivement le complément à deux. Marc Mongenet 28 septembre 2006 à 18:17 (CEST)

Si tu n'a pas de livre de référence sur C, je te conseille la FAQ C, qui est excellente, et qui répond à la question présente dès le début : http://c-faq.com/decl/inttypes.html Marc Mongenet 28 septembre 2006 à 18:20 (CEST)

Autant pour moi.

J'ai souvent le réflexe (erroné) de considérer le comportement de GCC comme le reflet du standard. Sanao 29 septembre 2006 à 00:43 (CEST)

GCC respecte le standard (enfin avec -ansi -pedantic), mais le standard est très souple. :-) Ça rend d'ailleurs l'écriture de programmes portables plus difficile. Marc Mongenet 29 septembre 2006 à 00:58 (CEST)

[modifier] Extremums codable

J'ai vu dans l'article que sur 1 octet (donc 8 bits) les extremums codable étaient de 0-255 pour du non-signé est -127,127 pour du signé. C'est une erreur, de 0 à 255 il y'a 256 valeur codable (nb:2^8), ceci est correcte en revanche de -127 à -1 il y'a 127 valeur codable et de 0 à 127 il y'en à 128, hors 127+128=255 et non 256. Les extremum sont donc -128,127.

La démonstration est trivial sur 2bit:

• 00 = 0
• 01 = 1
• 10 =-2
• 11 =-1

On à donc les bornes suivantes -2,1

Malheureusement vous n'avez pas lu, ou du moins pas tenu compte, du paragraphe introduisant le chapitre Types, qui évoque notamment le complément à deux. Lisez également un livre de référence sur C, comme The C Programming Language. Marc Mongenet 26 mars 2007 à 12:37 (CEST)

5.2.4.2.1 Sizes of integer types <limits.h> --- minimum value for an object of type signed char

           SCHAR_MIN                     -127 // -(2^7-1)

Le truc c'est que sont les valeurs minimales comme spécifié dans l'article

• Types entiers ≥ 8 bits, magnitudes minimales de -127 à +127 et de 0 à 255

est correcte mais pas de -128 à +127 - phe 26 mars 2007 à 17:59 (CEST)

Pourtant sur un char il est possible d'aller jusqu'a -128.mon petit test me le confirme:

printf("int min:%d\nint max:%d\n",1<<((sizeof(int)*8)-1),~0^(1<<(sizeof(int)*8)-1));

printf("char min:%d\nchar max:%d\n",(char)(1<<((sizeof(char)*8)-1)),(char)(~0^(1<<(sizeof(char)*8)-1)));

les résultats:

int min:-2147483648

int max:2147483647

char min:-128

char max:127

Azmaeve 26 mars à 20h56

J'ai écris un paragraphe à ce sujet dans l'introduction de l'article : la souplesse de son standard laisse de nombreux détails du résultat de la compilation être dépendants de l'implémentation voire complètement indéfinis, ce qui piège régulièrement les programmeurs ne maîtrisant pas l'intégralité du standard et complique la portabilité. Marc Mongenet 27 mars 2007 à 15:43 (CEST)