Discussion:C (langage)

message: 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)
thread_title:  Opérateurs d'incrémentation et PDP-11 

message: 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)
thread_title:  Suppression des exemples sur les variables et les initialisations 

message: 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)
replies: text: À 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)
thread_title:  Article de qualité? 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
thread_title:  Taille des char 

message: : #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)
thread_title:  Hello world 

message: 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)
thread_title:  K&R C 

message: 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)
replies: text: Ç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)
thread_title:  Commentaires de compilation 

message: 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)
replies: text: C'est de l'entrisme pour GCC, à virer dans l'article sur GCC, ou à supprimer. Marc Mongenet 26 septembre 2007 à 16:22 (CEST)
replies: text:  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)
thread_title:  Fonctionnalités de C99 présentes auparavant dans GCC 

message: 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)
thread_title:  Surcharge d'opérateurs 

message: 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)
thread_title:  Proposition de sélection de cet article pour [[Portail:Informatique]] 

message: Ç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)
replies: text: 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  à la suppression. Marc Mongenet (d) 5 janvier 2008 à 11:36 (CET)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Infobox langages de programmation 

message: 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)
replies: text: Tout à fait, c'est corrigé. Marc Mongenet (d) 22 août 2008 à 11:50 (CEST)
thread_title:  Exemple Chaîne de caractères 

message: "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)
replies: text: Pas tellement, effectivement. J'ai supprimé tout le paragraphe, car il est assez discutable. Marc Mongenet (d) 29 décembre 2011 à 15:20 (CET)
thread_title:  Languages vus comme levant des limitations de C 

message: 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)
thread_title:  C vs Pascal 

message: 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)
thread_title:  Révision C99 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Comportement ambigu : paragraphe ambigu