Discussion:C (langage)

Petits articles sur les instructions

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)

Opérateurs d'incrémentation et PDP-11

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)

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)

Vous connaissez ce langage assez vieux fortement typé compatible avec toutes les architectures que GCC prend en charge et qui à permis le développement d'OS comme Windows ou, mieux l'interface graphique KDE. Comment c'est déjà ? Ah oui C++ !

Au fait l'objet ça existe en C : (cf:http://sourceforge.net/projects/oooac/). Si EADS est intéressé je suis au chaumage actuellement.Ppignol (d) 10 mars 2010 à 18:36 (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

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)

J'aimerais que l'on arrête avec la mythologie "le C ne permet pas la programmation orienté objet" sous entendue par le discourt "tout ce fait par fonctions". Je ne suis pas d'accord c'est juste une question de politique. On peut programmer en objet si on s'en donne la peine. Le seul problème c'est que sur le cour terme cela demande plus de temps si l'on veut sortir un programme en temps record. Du coups les entreprises ne veulent pas le faire parce que sur le cour terme ce n'est (d'après elles) pas rentable. Même si sur le long terme il est plus intéressent de développer en objet pour tout ce qui vas être maintenances, réutilisation de code, extensions, segmentation des responsabilités opérationnelles du code, etc.... bref tout ce qui fait la suprématie du développement objet depuis 1990. (cf:http://sourceforge.net/projects/oooac/)10 mars 2010 à 18:55 (CET)

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)

La norme garanti que char < ou = short < ou = int < ou = long < ou = longlong. Elle garanti aussi que long = taille du bus d'adresse au moins pour les ordinateur < ou = 64 bits. Dans les architectures 32 bit char = 8 short = 16 et long = 32 d'ou un problème de choix de compilation. Selon le compilateur int = long ou int = short.Ppignol (d) 10 mars 2010 à 17:16 (CET)

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)

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)

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)

navré de contredire Alveric CHAR_BIT = au nombre de bit contenu dans un byte processeur. Certaines architectures on un byte processeur de 7 bits (à l'époque une bascule JK coutait cher). En francais Byte à été traduit à tord par octet avec l'avenement du pc architecturé sur 8 bits. La véritable traduction est "bits" en effets Byte se raproche plus de ensemble de bits que de octets.Ppignol (d) 10 mars 2010 à 17:47 (CET)

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)

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)

---

Retour à la charge 15 mois plus tard. Quel est le propos de ce paragraphe, par ailleurs long (>15%)  ? Beaucoup de ce qui y est dit n'est en rien spécifique au langage C. Une bonne partie (préprocesseur distinct, phase d'assemblage, pour ne citer que cela) n'est plus vrai, parfois depuis de nombreuses années. Une partie non négligeable explique que les principes généraux exposés deux lignes plus haut sont parfois inexacts. Et par ailleurs, cette section s'attarde sur le cas anecdotique des compilateurs pour les langages intermédiaires des machines virtuelles, particulièrement peu à leur place ici du fait des objectifs de la plupart des compilateurs C : rapidité, possibilité de portage d'autres logiciels (au rang desquels on va trouver... les modules d'exécution des machines virtuelles).

Éléments (actuellement exposés) exacts mais indépendants de C :

• génération souvent automatisée ;
• compilation divisée en analyse lexicale, analyse syntaxique et (génération de code) ;
• certains compilateurs fonctionnent en deux phases, machine virtuelle idéale puis conversion dépendant du processeur cible ;
• la dissertion sur .o/.obj (qui loupe le fait que sur le vrai Unix, l'assembleur crée normalement a.out, assembler output) ;
• fonctionnement d'un assembleur ;
• description de l'édition de lien ;
• les diverses dissertions sur les machines virtuelles.

Éléments pas toujours vrais (certains sont explicitement désavoués quelques lignes plus bas) :

• préprocesseur indépendant ;
• le préprocesseur produit des fichiers intermédiaires (faux en pratique dès les années 1977-78, argument -pipe passé à cc et surtout pcc) ;
• génération de code assembleur ;
• assembleur indépendant ;
• le code assembleur est « lisible par un être humain » (comme les informations de debug ? ou les machines VLIW ou similaire, genre IA-64 ?) ;
• le code issu de l'assemblage dépend du processeur, ou encore est en langage machine (contre-exemple: Plan9, en dehors du développement déjà présent sur les langages intermédiaires) ;
• nécessité d'édition des liens séparée (c'était surtout faux au début et sous Unix, lorsque les formats de code objet et de d'exécutable étaient identiques) ;
• l'édition de liens [au sens appel de ld sous Unix] est une seule et dernière étape (faux avec les bibliothèques dynamiques, qui datent quand même de 1987).

Si on enlève tous ces éléments, il ne reste guère que :

• l'existence d'un préprocesseur ;
• la présence d'une dichotomie marquée au niveau de l'utilisation du compilateur (interface "cc") entre compilation et édition des liens (à rapprocher d'Ada, et s'opposant à l'approche Fortran/Pascal : en C le programme principal n'est qu'une fonction parmi tant d'autres, avec juste un nom particulier) ; pour ma part, je rapprocherais ce point du caractère « bas niveau » du langage C, sujet amplement abordé par ailleurs ;
• la présentation de l'architecture « classique » d'un compilateur C, cpp+ccem[+opt]+as+ld ou encore les options classiques -Wp, -W0, [-W2,] -Wa et -Wl ;
• la variété de l'architecture interne des compilateurs C ;
• la variété des architectures cibles, sujet déjà abordé par ailleurs.

Je propose donc de passer la section C_(langage)#Préprocesseur vers le chapitre suivant (avec les sections C_(langage)#Instructions_du_pré-compilateur et #Constantes_du_pré-compilateur) pour faire ressortir cette particularité importante. Le reste, les aspects relevant de l'architecture des compilateurs, pourrait être présenté plus loin (par exemple près de la partie Optimiseurs). Ou élagué, ou déplacé dans d'autres articles plus adaptés, comme pourraient l'être assembleur, édition_de_liens ou bytecode. AntoineL 26 septembre 2007 à 17:14 (CEST)

Je t'encourage humblement à modifier l'article. Je suis aussi gêné par ce paragraphe. Marc Mongenet 26 septembre 2007 à 17:43 (CEST)

Plage d'un short

Pourtant cela ne fait pas les 65536 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)

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)

1)Un char n'est pas forcément sur 8 bits il existe des architecture à 7 bits. Byte ne veut pas dire octet mais "Bits".

2)Intervale [127;-128] est correct : 0 à 127(128 valeurs) et -128 à -1(127 valeurs), soit 255 valeurs sur une architecture 8 bits.Ppignol (d) 10 mars 2010 à 17:59 (CET)

K&R C

J'ai révoqué un exemple de K&R C dans un chapitre qui n'est pas consacré à cela. En outre, pour une si faible différence syntaxique, l'exemple prend trop de place. Marc Mongenet 16 août 2007 à 16:57 (CEST)

Commentaires de compilation

Je n'avais jamais rien vu de similaire. C'est dans la norme ? Ça sert à quoi ? - Eusebius ^[causons] 28 août 2007 à 17:01 (CEST)

Ça ne me dit rien non plus, j'ai supprimé. Si c'est propre à un compilateur, à ne pas remettre. Marc Mongenet 29 août 2007 à 00:58 (CEST)

Fonctionnalités de C99 présentes auparavant dans GCC

1.1 Normalisation dit entre autres :

[...]certaines de ces fonctionnalités étaient déjà présentes dans certains compilateurs comme gcc.

Quel est l'intérêt (en 2007) de ce commentaire ? Faire le fier ? AntoineL 26 septembre 2007 à 13:04 (CEST)

C'est de l'entrisme pour GCC, à virer dans l'article sur GCC, ou à supprimer. Marc Mongenet 26 septembre 2007 à 16:22 (CEST)

C'est bien ce que je pense, j'ai donc déplacé l'information vers l'article GCC, dans un nouveau paragraphe. AntoineL 28 septembre 2007 à 18:08 (CEST)

Division entière

2.2 Comportements mal définis explique en détail que la version originale de C ainsi que la norme de 1990 ne définissaient pas précisement le signe du reste en cas de division avec des nombres négatifs. Cependant, la norme C99 demande explicitement que le comportement soit celui décrit pour Ada. AntoineL 26 septembre 2007 à 14:18 (CEST)

Mise à jour : j'ai pris le partie de rajouter une note précisant ce point, lors d'une reprise du paragraphe correspondant. Vos améliorations sont les bienvenues. AntoineL 26 septembre 2007 à 14:38 (CEST)

Je ne savais pas que C99 avait défini ce comportement lorsque j'ai choisi cet exemple. Du coup, un autre exemple serait peut-être préférable ? (le décalage de bits à droite de valeur signée ?) Marc Mongenet 26 septembre 2007 à 16:25 (CEST)

Le résultat du décalage à droite d'un nombre négatif (le seul cas « intéressant ») est indéfini selon la norme, ce n'est donc pas vraiment la même chose qu'une division entière ; un autre domaine comparable est celui des nombres en virgule flottante, mais là les concurrents font souvent la même chose que C.

Un aspect parfois gênant est l'ordre d'évaluation des opérations, particulièrement lors des appels de fonctions; ainsi récemment, les développeurs de GCC ont décidé d'inverser l'ordre d'évaluation des sous-expressions pour certains opérateurs binaires, avec par conséquence une avalanche de dysfonctionnements. Mais là non plus je ne sais pas ce que précisent les normes des autres langages.

On peut envisager la gestion des débordements d'arithmétique entière signée (permise en C mais pas souvent implémentée, requise en Ada, j'ai pas été regardé pour Pascal), mais je pense qu'un éventuel exemple dans ce domaine n'aurait pas la même force de démonstration que l'actuel, car on sent bien intuitivement que la vérification des débordements a un coût notable à l'exécution. AntoineL 28 septembre 2007 à 17:56 (CEST)

Surcharge d'opérateurs

Je ne suis pas sûr qu'il soit pertinent d'indiquer que C n'a pas la surcharge d'opérateurs. Mais surtout, je ne comprends pas bien la logique de la phrase : elle semble dire que le fait de ne pas avoir la surcharge d'opérateur rend aisé le remplacement des fonctions standards, ce qui n'a pas de rapport. Que voulais-tu dire au juste Stefp? Marc Mongenet 5 octobre 2007 à 14:21 (CEST)

Proposition de sélection de cet article pour Portail:Informatique

Cet article est proposé pour faire partie de la sélection Wikipédia:Sélection/Informatique. Cette page permet d'afficher aléatoirement un article parmis la sélection sur Portail:Informatique. Les articles sélectionnés représentent la vitrine du projet.

Vous êtes invités à vous exprimer sur la page suivante : Wikipédia:Sélection/Informatique/C (langage). Toutes les remarques d'amélioration sont les bienvenues, mais notez que puisque c'est un vote interne au projet, seuls les votes des participants déjà inscrits sur le projet informatique seront pris en compte. --T (d) 11 décembre 2007 à 13:26 (CET)

Infobox langages de programmation

Ça commence à devenir vraiment gavant ces ajouts/revert, est-ce qu'il faut faire appel aux wikipompiers pour prendre une décision définitive ?? - Eusebius ^[causons] 4 janvier 2008 à 17:15 (CET)

Une IP tient à mettre deux boîtes l'une à côté de l'autre (ce qui n'est pas bien), et l'une des boîtes n'est qu'une espèce de bandeau portail géant (qui encombre donc les articles sans apporter d'informations pertinentes). J'hésite à proposer {{Langages de programmation}} à la suppression. Marc Mongenet (d) 5 janvier 2008 à 11:36 (CET)

Je suis d'accord, cette boite de navigation n'apporte rien aux articles. Ça fait penser à un bandeau de pub pour les langages les plus connus. En plus le contenu de cette liste est sujet à controverse (critères de sélection inconnus, classification difficile, ...). Si quelqu'un veut connaître les principaux langages de programmation, il devrait trouver cette information dans l'article Langage de programmation, pas dans une liste succincte sur tous articles de langage. --Piglop (d) 5 janvier 2008 à 14:02 (CET)

Alors proposez l'infobox à la suppression, qu'on règle le problème, plutôt que d'encombrer l'historique avec des reverts... - Eusebius ^[causons] 5 janvier 2008 à 14:18 (CET)

Je propose de faire un (sous-)portail de la programmation, et de remplacer cette encombrante palette par un classique lien portail. Voir Discussion Projet:Informatique pour les détails. Marc Mongenet (d) 7 janvier 2008 à 18:34 (CET)

\n VS \r\n

J'ai fortement envie de remplacer les \n par des \r\n. Pour des questions de politesse et de respect des minorités opprimés. Noky (d) 18 février 2008 à 22:30 (CET)

Un peu plus d'explications ne seraient pas de trop. -- Chico (blabla) 19 février 2008 à 00:19 (CET)

Un fichier texte qui ne contiendrait que des \n et fait sous windows, ne présenterait aucun saut de ligne sous un Mac (c'était ainsi dans le passé quand j'étais jeune je devais transformer tous les fichiers textes, car le \n sous windows est le 13, le \r le 10 alors que sous mac le \n était le 10 et le 13 un caractère bizarre). De même parfois les sauts de ligne n'apparaissent pas sous notepad et apparaissent sous wordpad et cela est du à ce problème. C'est pour cela que mettre partout \r\n assure que les sauts de ligne seront corrects sur presque toutes les machines du monde. De plus quand il s'agit d'une communication réseau le standard veut que les sauts de ligne se fasse avec \r\n, \n étant considéré comme une faute. Plus précis : le \n est normalement le aller à la ligne (sans retour au début) et le \r le retour au début (et l'on fait d'abord retour au début puis saut), c'est un héritage des vielles machines à écrire en fait. Noky (d) 19 février 2008 à 08:10 (CET)

En C, un fichier texte est présenté sour formes de lignes délimitées par des caractères \n. La représentation de ce fichier par le système est une question annexe qui n'a pas grand chose à voir, et n'a pas de contraintes figées. (Par exemple, sur une de mes machines, les lignes sont des zones de 132 caractères, et on a des caractères de bourrage si on écrit moins de 132 caractères ; et il n'y a pas normalement de caractère CR, ni LF, ni NL ; et oui en plus c'est de l'EBCDIC et il y a trois caractères différents pour la fin de ligne... Vous pouvez aussi consulter cet article en anglais)

Si on veut contrôler réellement la forme (par exemple, pour l'utilisation des protocoles de l'internet, comme pour [1]), il faut alors utiliser un fichier binaire ; et alors, si la machine est en ASCII, on peut effectivement coder une fin de ligne avec "\r\n", ou mieux "\x0D\x0A". Mais cet usage doit avoir un motif réel, il n'y a aucune raison de le faire partout.

Sur Windows (et DOS, et CP/M, et DEC, etc.), la grande majorité des bibliothèques C convertissent (pour les fichiers texte, donc ouvert sans "?b") le caractère \n (codé 10) écrit par le programme en séquence CRLF ; en entrée dans la séquence CRLF est convertie en \n (mais un CR isolé est normalement gardé). Les seules exceptions sont les environnements « genre POSIX », comme Cygwin ou en:Interix, qui sont spécifiquement conçus pour mieux coller aux principes de fonctionnement des systèmes d'exploitation unixoïdes ; les fichiers produits par ces systèmes ne sont pas très compatibles (par exemple, la lecture avec Notepad est difficile, comme vous le notez). Mettre \r\n dans un fichier texte est une mauvaise idée, car certaines bibliothèques vont émettre CRCRLF, donc des lignes avec interligne double.

Sur Mac, et aussi avec le langage Basic tel qu'implémenté par la société Microsoft, une fin de ligne est représentée par le caractère 13. La manière la plus directe d'implémenter le langage C est donc de donner au caractère \n le code 13 (et \r obtient le code 10; exemple: en:Metrowerks) ; une autre méthode, inspirée du grand frère Unix, est d'utiliser le même codage \n=10, et de transposer les 13 des fichiers machine non-binaires en \n pour le programme, dans les deux sens; par compatibilité avec Posix et Windows, en lecture les combinaisons CRLF et LF sont elles aussi converties en \n. On voit bien qu'utiliser la forme \r\n va avoir des comportements imprévisibles, comme obtenir 10+13 (LFCR), ou 13+13 (double interligne). AntoineL (d) 20 février 2008 à 15:36 (CET)

Plus précis : le \n est normalement le aller à la ligne (sans retour au début) et le \r le retour au début (et l'on fait d'abord retour au début puis saut), c'est un héritage des vielles machines à écrire en fait.

Non. \n signifie très exactement « aller au début de la ligne suivante », et \r « aller au début de la ligne en cours. » Norme ISO/CÉI 9899, paragraphe 5.2.2.

Quant aux héritages, il s'agit en fait de ceux des systèmes Multics et GCos (pour la convention \n=NL) et de la norme ASCII originale (pour LF=avance papier). AntoineL (d) 20 février 2008 à 15:36 (CET)

Il serait bien dommage de perdre les explications de ces intéressants détails, qui n'ont pas leur place dans un article encyclopédique (donc synthétique). Le livre de programmation sur C serait un bon endroit pour les conserver, et ça réhausserait son niveau ! Marc Mongenet (d) 20 février 2008 à 18:09 (CET)

Exemple Chaîne de caractères

Dans le commentaire du code il est écrit que le pointeur n'est pas incrémenté à l'arrivée sur le caractère de fin 0. Il est incrémenté après le renvoi de la valeur pointée en effet, mais avant l'évaluation de ce dernier par while. Lorsque qu'on arrive sur le caractère de fin, le pointeur est incrémenté une dernière fois, et c'est pourquoi on soustrait 1 à la différence str - start. Quelqu'un peut-il confirmer ? --Nestor Fish (d) 22 août 2008 à 01:07 (CEST)

Tout à fait, c'est corrigé. Marc Mongenet (d) 22 août 2008 à 11:50 (CEST)

Environnements non libres ?

Bonjour,

Pourquoi seulement des environnement de développements libres sont cités ? Ne faudrait-il pas privilégier la neutralité de point de vue ? —Shiningfm (d) 8 avril 2009 à 00:06 (CEST)

Tout simplement parce que ce sont ceux que l'on maitrise le mieux.

Quand M$crosoft décide de ne pas faire comme les autres parce que c'est M$crosoft et qu'il ne veux pas fournir les sources, et qu'il s'aperçoit qu'il à fait une merde et qu'il la règle à moitié en douce dans la version suivante ou avec un patch c'est pas facile de savoir ce que le compilo M$crosoft fait ! Et donc on ferme les yeux et on croise les doigts avant de cliquer sur compiler. Du coups on sait pas ce qu'il fait ! Et donc on peux pas en parler de manière fiable. CQFD ! Quand M$crosoft se mettra à faire comme les autre en respectant à la lettre les standards on pourra peut être parler de lui !Ppignol (d) 10 mars 2010 à 18:24 (CET)L

Languages vus comme levant des limitations de C

"Beaucoup de limitations du langage C ont été levées dans d'autres langages de programmation qui ont adopté une syntaxe inspirée de celle de C ; outre C++ qui est à l'origine une extension de C enrichi de la notion d'objet, on peut citer Java, JavaScript, PHP et C#."

Peut-on réellement citer Javascript en exemple ??? --90.36.60.92 (d) 28 septembre 2011 à 20:58 (CEST)

Pas tellement, effectivement. J'ai supprimé tout le paragraphe, car il est assez discutable. Marc Mongenet (d) 29 décembre 2011 à 15:20 (CET)

C vs Pascal

Le code avec des unsigned int n'est pas approprié pour trois raisons :

• il correspond moins bien au code Pascal de l'exemple (qui utilise Integer) ;
• il est inutilement plus complexe à lire (plus de mots clés) ;
• coder en unsigned "parce ça ne peut pas être négatif" est une erreur stylistique de débutant en C.

Marc Mongenet (d) 16 mars 2012 à 11:56 (CET)

Révision C99

Parmi les mots-clés cités, les deux derniers ne satisfont pas à l'affirmation selon laquelle les nouveaux mots-clés commencent par une majuscule précédée par un espace souligné --Pjacquot (discuter) 18 juillet 2014 à 09:06 (CEST)

Comportement ambigu : paragraphe ambigu

Bonjour, j'ai un petit problème avec le paragraphe suivant (le gras est de moi) :

« La norme du langage C laisse la définition exacte du comportement de plusieurs opérations au choix du concepteur du compilateur. Ces comportements sont donc définis par l'implémentation. Cette propriété de C permet au compilateur d'utiliser directement les instructions proposées par le processeur, donc de compiler des programmes exécutables courts et efficaces. En contrepartie, c'est parfois la cause de bugs de portabilité des codes source écrits en C. Prenons pour exemple la division entière d'un nombre négatif : -5 / 3. Alors que Fortran, Pascal et Ada spécifient un résultat de -1, et que Modula-3 spécifie un résultat de -2, C garantit simplement que la valeur absolue du reste est strictement inférieure à la valeur absolue du diviseur. La seule garantie dans cet exemple est donc que le résultat sera -2 ou -1. »

C'est faux, depuis 15 ans. La norme du C, c'est-à-dire l'ISO 9899, est plus explicite depuis 1999. Et la norme de 1999 abroge les normes précédentes. Bref, ce paragraphe est obsolète et donne une fausse idée du C. C'est un peu comme si on disait qu'en Fortran la norme limite les lignes à 72 caractères, et les noms de variables à 6 (et encore, ce n'était déjà plus vrai en 1999), ou encore si on disait que Windows ne prend pas en charge l'USB (époque Windows 95...).

C'est précisé en note, mais ça ne suffit pas.

kiwipidae (dicuter) 5 août 2015 à 07:08 (CEST)

Je suis assez d'accord. Il existe suffisamment d'exemples possibles pour ne pas entamer par un exemple qui n'est plus valable depuis C99. Je prépare en passant une modification de toute la section "Comportements ambigus" qui, à mon humble avis, ne met pas assez en évidence les différences entre les différents types de comportements ambigus et ne mentionne pas les comportements non spécifiés qui ne sont ni implementation-dependent ni indéfinis. --Modulo17 (discuter) 11 février 2016 à 12:36 (CET)

Voilà, c'est fait. J'espère que ce n'est pas trop long par rapport au reste de l'article. La version anglaise a deux articles séparés pour les comportements indéfinis, et pour les comportements dépendant de l'implémentation/non spécifiés, en C et en C++. --Modulo17 (discuter) 11 février 2016 à 14:58 (CET)