Wikipédia est un projet d'encyclopédie gratuite, écrite
coopérativement et dont le contenu est librement réutilisable sous la
licence de documentation libre GNU.
Le principe de Wikipédia est de permettre à chaque lecteur
d'intervenir sur le texte d'un article, que ce soit pour corriger une
virgule, ajouter une phrase, rectifier des erreurs ou rédiger
plusieurs pages.
Le Wikipédia francophone comporte plus de 28 000 articles et le
Wikipédia anglophone plus de 215 000 articles, tous rédigés et
corrigés par des volontaires.
Ce message a pour objet d'inviter des contributeurs volontaires à
améliorer l'article de Wikipédia consacré au langage C :
http://fr.wikipedia.org/wiki/Langage_C
Par comparaison, voici l'article correspondant dans le Wikipédia
anglophone :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Lefevre
Dans l'article , Spicalioth écrit:
http://fr.wikipedia.org/wiki/Langage_C
Je proposerais bien les modifications suivantes:
"le code assembleur généré par les compilateurs étant relativement prévisible et très souvent optimal"
-> "et très souvent optimal" probablement à enlever, car ça ce veut pas dire grand chose, et il y a des cas simples où une traduction pas trop bête en assembleur est plus rapide. Par exemple, avec une boucle du style while (--i >= 0), gcc n'est pas capable de générer la soustraction et la comparaison à 0 en une seule instruction sur les processeurs qui supportent cela (e.g. ARM et Sparc).
Instructions de compilation
* if * else * for * while * do * switch * break * continue * goto * sizeof * return
-> Je n'appellerais pas ça des instructions de compilation.
* types entiers 8 bits : char, signed char, unsigned char * types entiers 16 bits : short, signed short, unsigned short * types entiers 32 bits : long, signed long, unsigned long * types entiers 16/32 bits (selon la plate-forme) : int, signed int, unsigned int
C'est faux. -> Ne pas préciser la taille. C'est une liste non exhaustive, évidemment.
* types à virgule flottante : float, double
Ajouter long double?
* types élaborés : enum, struct, typedef
Enlever typedef? typedef ne sert qu'à définir un alias d'un type existant.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <9o04405maqnre2absu8rh6gfcrt1m6ghar@4ax.com>,
Spicalioth <spicaliothPASDEPOURRIEL@free.fr> écrit:
http://fr.wikipedia.org/wiki/Langage_C
Je proposerais bien les modifications suivantes:
"le code assembleur généré par les compilateurs étant relativement
prévisible et très souvent optimal"
-> "et très souvent optimal" probablement à enlever, car ça ce veut
pas dire grand chose, et il y a des cas simples où une traduction
pas trop bête en assembleur est plus rapide. Par exemple, avec une
boucle du style while (--i >= 0), gcc n'est pas capable de générer
la soustraction et la comparaison à 0 en une seule instruction sur
les processeurs qui supportent cela (e.g. ARM et Sparc).
Instructions de compilation
* if
* else
* for
* while
* do
* switch
* break
* continue
* goto
* sizeof
* return
-> Je n'appellerais pas ça des instructions de compilation.
* types entiers 8 bits : char, signed char, unsigned char
* types entiers 16 bits : short, signed short, unsigned short
* types entiers 32 bits : long, signed long, unsigned long
* types entiers 16/32 bits (selon la plate-forme) : int, signed int,
unsigned int
C'est faux. -> Ne pas préciser la taille.
C'est une liste non exhaustive, évidemment.
* types à virgule flottante : float, double
Ajouter long double?
* types élaborés : enum, struct, typedef
Enlever typedef? typedef ne sert qu'à définir un alias d'un type existant.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
"le code assembleur généré par les compilateurs étant relativement prévisible et très souvent optimal"
-> "et très souvent optimal" probablement à enlever, car ça ce veut pas dire grand chose, et il y a des cas simples où une traduction pas trop bête en assembleur est plus rapide. Par exemple, avec une boucle du style while (--i >= 0), gcc n'est pas capable de générer la soustraction et la comparaison à 0 en une seule instruction sur les processeurs qui supportent cela (e.g. ARM et Sparc).
Instructions de compilation
* if * else * for * while * do * switch * break * continue * goto * sizeof * return
-> Je n'appellerais pas ça des instructions de compilation.
* types entiers 8 bits : char, signed char, unsigned char * types entiers 16 bits : short, signed short, unsigned short * types entiers 32 bits : long, signed long, unsigned long * types entiers 16/32 bits (selon la plate-forme) : int, signed int, unsigned int
C'est faux. -> Ne pas préciser la taille. C'est une liste non exhaustive, évidemment.
* types à virgule flottante : float, double
Ajouter long double?
* types élaborés : enum, struct, typedef
Enlever typedef? typedef ne sert qu'à définir un alias d'un type existant.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Richard Delorme
Dans l'article , Spicalioth écrit:
http://fr.wikipedia.org/wiki/Langage_C
Je proposerais bien les modifications suivantes:
Il me semble qu'il faut faire les modifications directement sur le site.
"le code assembleur généré par les compilateurs étant relativement prévisible et très souvent optimal"
-> "et très souvent optimal" probablement à enlever, car ça ce veut pas dire grand chose, et il y a des cas simples où une traduction pas trop bête en assembleur est plus rapide. Par exemple, avec une boucle du style while (--i >= 0), gcc n'est pas capable de générer la soustraction et la comparaison à 0 en une seule instruction sur les processeurs qui supportent cela (e.g. ARM et Sparc).
Il serait dommage de ne pas signaler que le langage C produit un code assembleur efficace ou performant ou optimal, peu importe l'adjectif. Pour ma part, c'est la raison principale pour laquelle j'utilise le C et non l'assembleur. D'ailleurs, le « très souvent » indique qu'il y a des cas peu fréquent ou le code générer n'est pas optimal. Et puis je ne sais pas si ton exemple est très bon ; on m'a dit que gcc n'est pas très performant en dehors des plateformes Intel. Quel instruction génère le compilateur de Sun sur ton exemple ?
-- Richard
Dans l'article <9o04405maqnre2absu8rh6gfcrt1m6ghar@4ax.com>,
Spicalioth <spicaliothPASDEPOURRIEL@free.fr> écrit:
http://fr.wikipedia.org/wiki/Langage_C
Je proposerais bien les modifications suivantes:
Il me semble qu'il faut faire les modifications directement sur le site.
"le code assembleur généré par les compilateurs étant relativement
prévisible et très souvent optimal"
-> "et très souvent optimal" probablement à enlever, car ça ce veut
pas dire grand chose, et il y a des cas simples où une traduction
pas trop bête en assembleur est plus rapide. Par exemple, avec une
boucle du style while (--i >= 0), gcc n'est pas capable de générer
la soustraction et la comparaison à 0 en une seule instruction sur
les processeurs qui supportent cela (e.g. ARM et Sparc).
Il serait dommage de ne pas signaler que le langage C produit un code
assembleur efficace ou performant ou optimal, peu importe l'adjectif.
Pour ma part, c'est la raison principale pour laquelle j'utilise le C et
non l'assembleur.
D'ailleurs, le « très souvent » indique qu'il y a des cas peu fréquent
ou le code générer n'est pas optimal. Et puis je ne sais pas si ton
exemple est très bon ; on m'a dit que gcc n'est pas très performant en
dehors des plateformes Intel. Quel instruction génère le compilateur de
Sun sur ton exemple ?
Il me semble qu'il faut faire les modifications directement sur le site.
"le code assembleur généré par les compilateurs étant relativement prévisible et très souvent optimal"
-> "et très souvent optimal" probablement à enlever, car ça ce veut pas dire grand chose, et il y a des cas simples où une traduction pas trop bête en assembleur est plus rapide. Par exemple, avec une boucle du style while (--i >= 0), gcc n'est pas capable de générer la soustraction et la comparaison à 0 en une seule instruction sur les processeurs qui supportent cela (e.g. ARM et Sparc).
Il serait dommage de ne pas signaler que le langage C produit un code assembleur efficace ou performant ou optimal, peu importe l'adjectif. Pour ma part, c'est la raison principale pour laquelle j'utilise le C et non l'assembleur. D'ailleurs, le « très souvent » indique qu'il y a des cas peu fréquent ou le code générer n'est pas optimal. Et puis je ne sais pas si ton exemple est très bon ; on m'a dit que gcc n'est pas très performant en dehors des plateformes Intel. Quel instruction génère le compilateur de Sun sur ton exemple ?
-- Richard
Régis Troadec
Salut,
"Vincent Lefevre" <vincent+ a écrit dans le message de news: 20040229154836$
Dans l'article , Spicalioth écrit:
* types élaborés : enum, struct, typedef
Enlever typedef? typedef ne sert qu'à définir un alias d'un type existant.
Et ajouter union par exemple ? :-)
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Thierry Boudet
On 2004-02-29, Vincent Lefevre <vincent+ wrote:
http://fr.wikipedia.org/wiki/Langage_C
"le code assembleur généré par les compilateurs étant relativement prévisible et très souvent optimal"
Arf!!! pas toujours...
As tu fréquenté les crosscomilateur de Intermetrics (Whitesmith) pour 68000 de la fin des années 80 ?
Pour prévoir le code généré, le mieux c'était cat /proc/urandom | grep --madame-soleil > le_binaire
J'en ris encore :)
-- David Lightman: What is the primary goal? Joshua: You should know, Professor. You programmed me. David Lightman: C'mon. What is the primary goal? Joshua: To win the game.
On 2004-02-29, Vincent Lefevre <vincent+news@vinc17.org> wrote:
http://fr.wikipedia.org/wiki/Langage_C
"le code assembleur généré par les compilateurs étant relativement
prévisible et très souvent optimal"
Arf!!! pas toujours...
As tu fréquenté les crosscomilateur de Intermetrics (Whitesmith)
pour 68000 de la fin des années 80 ?
Pour prévoir le code généré, le mieux c'était
cat /proc/urandom | grep --madame-soleil > le_binaire
J'en ris encore :)
--
David Lightman: What is the primary goal?
Joshua: You should know, Professor. You programmed me.
David Lightman: C'mon. What is the primary goal?
Joshua: To win the game.
"le code assembleur généré par les compilateurs étant relativement prévisible et très souvent optimal"
Arf!!! pas toujours...
As tu fréquenté les crosscomilateur de Intermetrics (Whitesmith) pour 68000 de la fin des années 80 ?
Pour prévoir le code généré, le mieux c'était cat /proc/urandom | grep --madame-soleil > le_binaire
J'en ris encore :)
-- David Lightman: What is the primary goal? Joshua: You should know, Professor. You programmed me. David Lightman: C'mon. What is the primary goal? Joshua: To win the game.
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Spicalioth écrit: | | > http://fr.wikipedia.org/wiki/Langage_C | | Je proposerais bien les modifications suivantes: | | "le code assembleur généré par les compilateurs étant relativement | prévisible et très souvent optimal"
C'est une blague.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <9o04405maqnre2absu8rh6gfcrt1m6ghar@4ax.com>,
| Spicalioth <spicaliothPASDEPOURRIEL@free.fr> écrit:
|
| > http://fr.wikipedia.org/wiki/Langage_C
|
| Je proposerais bien les modifications suivantes:
|
| "le code assembleur généré par les compilateurs étant relativement
| prévisible et très souvent optimal"
| Dans l'article , | Spicalioth écrit: | | > http://fr.wikipedia.org/wiki/Langage_C | | Je proposerais bien les modifications suivantes: | | "le code assembleur généré par les compilateurs étant relativement | prévisible et très souvent optimal"
C'est une blague.
-- Gaby
Vincent Lefevre
Dans l'article <4042146d$0$5910$, Richard Delorme écrit:
Il serait dommage de ne pas signaler que le langage C produit un code assembleur efficace ou performant ou optimal, peu importe l'adjectif.
"performant" est préférable.
D'ailleurs, le « très souvent » indique qu'il y a des cas peu fréquent ou le code générer n'est pas optimal.
Personnellement, je n'ai jamais vu de code assembleur optimal. Et j'ai souvent vu du code assembleur généré non optimal.
Et puis je ne sais pas si ton exemple est très bon ; on m'a dit que gcc n'est pas très performant en dehors des plateformes Intel.
Il n'y a pas souvent d'autres compilo disponibles.
Quel instruction génère le compilateur de Sun sur ton exemple ?
Si je me souviens bien, j'avais testé et il donnait la même chose que gcc.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <4042146d$0$5910$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> écrit:
Il serait dommage de ne pas signaler que le langage C produit un code
assembleur efficace ou performant ou optimal, peu importe l'adjectif.
"performant" est préférable.
D'ailleurs, le « très souvent » indique qu'il y a des cas peu fréquent
ou le code générer n'est pas optimal.
Personnellement, je n'ai jamais vu de code assembleur optimal. Et j'ai
souvent vu du code assembleur généré non optimal.
Et puis je ne sais pas si ton exemple est très bon ; on m'a dit que
gcc n'est pas très performant en dehors des plateformes Intel.
Il n'y a pas souvent d'autres compilo disponibles.
Quel instruction génère le compilateur de Sun sur ton exemple ?
Si je me souviens bien, j'avais testé et il donnait la même chose que
gcc.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <4042146d$0$5910$, Richard Delorme écrit:
Il serait dommage de ne pas signaler que le langage C produit un code assembleur efficace ou performant ou optimal, peu importe l'adjectif.
"performant" est préférable.
D'ailleurs, le « très souvent » indique qu'il y a des cas peu fréquent ou le code générer n'est pas optimal.
Personnellement, je n'ai jamais vu de code assembleur optimal. Et j'ai souvent vu du code assembleur généré non optimal.
Et puis je ne sais pas si ton exemple est très bon ; on m'a dit que gcc n'est pas très performant en dehors des plateformes Intel.
Il n'y a pas souvent d'autres compilo disponibles.
Quel instruction génère le compilateur de Sun sur ton exemple ?
Si je me souviens bien, j'avais testé et il donnait la même chose que gcc.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Bertrand Mollinier Toublet
Vincent Lefevre wrote:
Dans l'article <4042146d$0$5910$, Richard Delorme écrit:
Il serait dommage de ne pas signaler que le langage C produit un code assembleur efficace ou performant ou optimal, peu importe l'adjectif.
"performant" est préférable.
Tu peux indiquer la regle du pouce (si tant est que tu sois d'accord
avec) qui indique qu'une bonne optimisation a la mano peut gagner environ 10% de perf par rapport au code compile, ce qui est bien mais pas top vu le boulot a fournir pour obtenir l'optimisation a la mano. -- Bertrand Mollinier Toublet "Reality exists" - Richard Heathfield, 1 July 2003
Vincent Lefevre wrote:
Dans l'article <4042146d$0$5910$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> écrit:
Il serait dommage de ne pas signaler que le langage C produit un code
assembleur efficace ou performant ou optimal, peu importe l'adjectif.
"performant" est préférable.
Tu peux indiquer la regle du pouce (si tant est que tu sois d'accord
avec) qui indique qu'une bonne optimisation a la mano peut gagner
environ 10% de perf par rapport au code compile, ce qui est bien mais
pas top vu le boulot a fournir pour obtenir l'optimisation a la mano.
--
Bertrand Mollinier Toublet
"Reality exists" - Richard Heathfield, 1 July 2003
Dans l'article <4042146d$0$5910$, Richard Delorme écrit:
Il serait dommage de ne pas signaler que le langage C produit un code assembleur efficace ou performant ou optimal, peu importe l'adjectif.
"performant" est préférable.
Tu peux indiquer la regle du pouce (si tant est que tu sois d'accord
avec) qui indique qu'une bonne optimisation a la mano peut gagner environ 10% de perf par rapport au code compile, ce qui est bien mais pas top vu le boulot a fournir pour obtenir l'optimisation a la mano. -- Bertrand Mollinier Toublet "Reality exists" - Richard Heathfield, 1 July 2003
Moi
Dans l'article <4042146d$0$5910$ écrivait :
Il me semble qu'il faut faire les modifications directement sur le site.
Comme sur tous les Wikis, non ?
Dans l'article <4042146d$0$5910$7a628cd7@news.club-internet.fr>
abulmo@nospam.fr écrivait :
Il me semble qu'il faut faire les modifications directement sur le site.
