hors sujet, inintéressant et idiot, l'important n'est pas [*] qui a dit quoi mais plutôt quels arguments sont proposés; non Gabriel je n'attribue pas à Marc en laissant son nom, je cite seulement la dernière intervention; comprendre autre chose est se fixer sur des détails nombrilistes sans intérêt.
Ca n'est pas comme ca que les traditions fonctionnent, va relire la netiquette, tu n'es pas cense laisser des attributions sans nom d'auteur, encore moins quand ce que tu supprimes peut donner a croire que quelqu'un d'autre a ecrit ce qui est cite (ce qui est le cas dans ce thread, ce qui m'a amene a raler).
[*] hors argumentaire dont on citerait auteur et contexte.
ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui n'etait pas attribue. []
tu couines quand on laisse ton nom, tu zappes quand on l'enlève ?! puérile attitude.
Ca n'a rien de pueril, j'ai meme donne les raisons. Il y a peu de choses qui m'enervent plus que de retrouver les propos de quelqu'un d'autre dans ma bouche (ou le contraire), ce qui s'est produit ici.
Je pensais betement pouvoir le faire vite sans que le thread degenere completement, mais comme tu as decide de te comporter en gros lourd, visiblement, j'ai eu tort. Followup positionne en consequence.
In article <4a119ad0$0$17738$ba4acef3@news.orange.fr>,
Sylvain SF <sylvain@boiteaspam.info> wrote:
Marc Espie a écrit :
ca demande de garder des attributions correctes.
hors sujet, inintéressant et idiot, l'important n'est pas [*] qui
a dit quoi mais plutôt quels arguments sont proposés; non Gabriel
je n'attribue pas à Marc en laissant son nom, je cite seulement
la dernière intervention; comprendre autre chose est se fixer sur
des détails nombrilistes sans intérêt.
Ca n'est pas comme ca que les traditions fonctionnent, va relire la
netiquette, tu n'es pas cense laisser des attributions sans nom d'auteur,
encore moins quand ce que tu supprimes peut donner a croire que quelqu'un
d'autre a ecrit ce qui est cite (ce qui est le cas dans ce thread, ce qui
m'a amene a raler).
[*] hors argumentaire dont on citerait auteur et contexte.
ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui
n'etait pas attribue. []
tu couines quand on laisse ton nom, tu zappes quand on l'enlève ?!
puérile attitude.
Ca n'a rien de pueril, j'ai meme donne les raisons. Il y a peu de choses qui
m'enervent plus que de retrouver les propos de quelqu'un d'autre dans ma bouche
(ou le contraire), ce qui s'est produit ici.
Je pensais betement pouvoir le faire vite sans que le thread degenere
completement, mais comme tu as decide de te comporter en gros lourd,
visiblement, j'ai eu tort. Followup positionne en consequence.
hors sujet, inintéressant et idiot, l'important n'est pas [*] qui a dit quoi mais plutôt quels arguments sont proposés; non Gabriel je n'attribue pas à Marc en laissant son nom, je cite seulement la dernière intervention; comprendre autre chose est se fixer sur des détails nombrilistes sans intérêt.
Ca n'est pas comme ca que les traditions fonctionnent, va relire la netiquette, tu n'es pas cense laisser des attributions sans nom d'auteur, encore moins quand ce que tu supprimes peut donner a croire que quelqu'un d'autre a ecrit ce qui est cite (ce qui est le cas dans ce thread, ce qui m'a amene a raler).
[*] hors argumentaire dont on citerait auteur et contexte.
ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui n'etait pas attribue. []
tu couines quand on laisse ton nom, tu zappes quand on l'enlève ?! puérile attitude.
Ca n'a rien de pueril, j'ai meme donne les raisons. Il y a peu de choses qui m'enervent plus que de retrouver les propos de quelqu'un d'autre dans ma bouche (ou le contraire), ce qui s'est produit ici.
Je pensais betement pouvoir le faire vite sans que le thread degenere completement, mais comme tu as decide de te comporter en gros lourd, visiblement, j'ai eu tort. Followup positionne en consequence.
Gabriel Dos Reis
Antoine Leca writes:
| Le 18/05/2009 05:35Z, Gabriel Dos Regis écrivit :
Marc Espie writes:
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, | ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme | vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à ce qu'on tombe sur zéro ?
| Mmmm... La seule chose, c'est que si tu supprimes les pointeurs (parce | que c'est dangereux),
Je ne pensais pas avoir suggéré de supprimer les pointeurs. Les pointeurs sont utiles pour des tâches assez fondamentales.
| les char* (parce que c'est flou) et aussi malloc | (parce que cela peut rater, ou parce qu'il faut s'occuper de libérer, | cela donne trop de boulot), tu peux probablement arrêter de faire du C | et passer tout de go à n'importe lequel de ces langages « bien faits », | qui incorpore ramasse-miettes, type String et références...
C'est une conclusion possible si on ajoute des hypothèses extrêmes à ce que j'ai suggéré.
| ... pour t'apercevoir que le résultat n'est plus aussi portable. | | | strlcpy est une rustine, qui permet à peu de frais de continuer à faire | du C, et donc de capitaliser sur l'existant : ce n'est peut-être pas la | panacée ou la voie du futur, mais franchement, je ne suis pas sûr que C | soit sur cette voie.
Je ne suis pas certain que le C se définit (au sens du « C spirit ») comme emmpiler des rustines sur rustines :-)
| A contrario, il me semble que *_s() (les fonctions « de sûreté », qui | semblent être une partie importante de C1X) soient plutôt un emplâtre, | dont je ne suis pas sûr qu'il prenne.
Tout à fait d'accord.
-- Gaby
Antoine Leca <root@localhost.invalid> writes:
| Le 18/05/2009 05:35Z, Gabriel Dos Regis écrivit :
Marc Espie writes:
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy,
| ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme
| vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au
lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à
ce qu'on tombe sur zéro ?
| Mmmm... La seule chose, c'est que si tu supprimes les pointeurs (parce
| que c'est dangereux),
Je ne pensais pas avoir suggéré de supprimer les pointeurs. Les
pointeurs sont utiles pour des tâches assez fondamentales.
| les char* (parce que c'est flou) et aussi malloc
| (parce que cela peut rater, ou parce qu'il faut s'occuper de libérer,
| cela donne trop de boulot), tu peux probablement arrêter de faire du C
| et passer tout de go à n'importe lequel de ces langages « bien faits »,
| qui incorpore ramasse-miettes, type String et références...
C'est une conclusion possible si on ajoute des hypothèses extrêmes à ce
que j'ai suggéré.
| ... pour t'apercevoir que le résultat n'est plus aussi portable.
|
|
| strlcpy est une rustine, qui permet à peu de frais de continuer à faire
| du C, et donc de capitaliser sur l'existant : ce n'est peut-être pas la
| panacée ou la voie du futur, mais franchement, je ne suis pas sûr que C
| soit sur cette voie.
Je ne suis pas certain que le C se définit (au sens du « C spirit »)
comme emmpiler des rustines sur rustines :-)
| A contrario, il me semble que *_s() (les fonctions « de sûreté », qui
| semblent être une partie importante de C1X) soient plutôt un emplâtre,
| dont je ne suis pas sûr qu'il prenne.
| Le 18/05/2009 05:35Z, Gabriel Dos Regis écrivit :
Marc Espie writes:
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, | ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme | vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à ce qu'on tombe sur zéro ?
| Mmmm... La seule chose, c'est que si tu supprimes les pointeurs (parce | que c'est dangereux),
Je ne pensais pas avoir suggéré de supprimer les pointeurs. Les pointeurs sont utiles pour des tâches assez fondamentales.
| les char* (parce que c'est flou) et aussi malloc | (parce que cela peut rater, ou parce qu'il faut s'occuper de libérer, | cela donne trop de boulot), tu peux probablement arrêter de faire du C | et passer tout de go à n'importe lequel de ces langages « bien faits », | qui incorpore ramasse-miettes, type String et références...
C'est une conclusion possible si on ajoute des hypothèses extrêmes à ce que j'ai suggéré.
| ... pour t'apercevoir que le résultat n'est plus aussi portable. | | | strlcpy est une rustine, qui permet à peu de frais de continuer à faire | du C, et donc de capitaliser sur l'existant : ce n'est peut-être pas la | panacée ou la voie du futur, mais franchement, je ne suis pas sûr que C | soit sur cette voie.
Je ne suis pas certain que le C se définit (au sens du « C spirit ») comme emmpiler des rustines sur rustines :-)
| A contrario, il me semble que *_s() (les fonctions « de sûreté », qui | semblent être une partie importante de C1X) soient plutôt un emplâtre, | dont je ne suis pas sûr qu'il prenne.
Tout à fait d'accord.
-- Gaby
Gabriel Dos Reis
(Marc Espie) writes:
| In article <4a112c43$0$17080$, | Richard Delorme wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
| C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se défendre dans ce forum, on peut exclure cet attribut de la discussion.
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <4a112c43$0$17080$ba4acef3@news.orange.fr>,
| Richard Delorme <abulmo@nospam.fr> wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui
interdit l'addition de ces fonctions dans la glibc). Il dit à propos
de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).
Beside, those who are using strcat or variants deserved to be punished.
| C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se
défendre dans ce forum, on peut exclure cet attribut de la discussion.
| In article <4a112c43$0$17080$, | Richard Delorme wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
| C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se défendre dans ce forum, on peut exclure cet attribut de la discussion.
-- Gaby
Gabriel Dos Reis
Sylvain SF writes:
| Marc Espie a écrit :
ca demande de garder des attributions correctes.
| hors sujet, inintéressant et idiot, l'important n'est pas [*] qui | a dit quoi mais plutôt quels arguments sont proposés; non Gabriel | je n'attribue pas à Marc en laissant son nom, je cite seulement | la dernière intervention;
Il y a des règles simples d'attribution sur Usenet et ton message laissait croire sans ambiguité que tu faisais une attribution non meritée à Marc. Cela ne coûte rien de le reconnaître et passer à autre chose.
| comprendre autre chose est se fixer sur | des détails nombrilistes sans intérêt.
À ta place, je me garderais bien de faire une description narcissique.
-- Gaby
Sylvain SF <sylvain@boiteaspam.info> writes:
| Marc Espie a écrit :
ca demande de garder des attributions correctes.
| hors sujet, inintéressant et idiot, l'important n'est pas [*] qui
| a dit quoi mais plutôt quels arguments sont proposés; non Gabriel
| je n'attribue pas à Marc en laissant son nom, je cite seulement
| la dernière intervention;
Il y a des règles simples d'attribution sur Usenet et ton
message laissait croire sans ambiguité que tu faisais une attribution
non meritée à Marc. Cela ne coûte rien de le reconnaître et passer à
autre chose.
| comprendre autre chose est se fixer sur
| des détails nombrilistes sans intérêt.
À ta place, je me garderais bien de faire une description narcissique.
| hors sujet, inintéressant et idiot, l'important n'est pas [*] qui | a dit quoi mais plutôt quels arguments sont proposés; non Gabriel | je n'attribue pas à Marc en laissant son nom, je cite seulement | la dernière intervention;
Il y a des règles simples d'attribution sur Usenet et ton message laissait croire sans ambiguité que tu faisais une attribution non meritée à Marc. Cela ne coûte rien de le reconnaître et passer à autre chose.
| comprendre autre chose est se fixer sur | des détails nombrilistes sans intérêt.
À ta place, je me garderais bien de faire une description narcissique.
-- Gaby
espie
In article , Gabriel Dos Reis wrote:
(Marc Espie) writes: | C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se défendre dans ce forum, on peut exclure cet attribut de la discussion.
C'est pas comme si ca faisait pas quelques annees que je le disais, y compris dans une discussion avec lui dans une langue qu'il parle...
In article <87skj2dx4f.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
espie@lain.home (Marc Espie) writes:
| C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se
défendre dans ce forum, on peut exclure cet attribut de la discussion.
C'est pas comme si ca faisait pas quelques annees que je le disais, y
compris dans une discussion avec lui dans une langue qu'il parle...
(Marc Espie) writes: | C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se défendre dans ce forum, on peut exclure cet attribut de la discussion.
C'est pas comme si ca faisait pas quelques annees que je le disais, y compris dans une discussion avec lui dans une langue qu'il parle...
JKB
Le 18-05-2009, ? propos de Re: passer une chaîne d'un char [] à un autre char [], Marc Espie ?crivait dans fr.comp.lang.c :
In article , Gabriel Dos Reis wrote:
(Marc Espie) writes: | C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se défendre dans ce forum, on peut exclure cet attribut de la discussion.
C'est pas comme si ca faisait pas quelques annees que je le disais, y compris dans une discussion avec lui dans une langue qu'il parle...
+1 (et dans des discussions privées dans sa langue maternelle et portant sur l'interprétation des specs POSIX et d'une sombre histoire de mélangeage de pinceaux entre le futur et le conditionnel...).
JKB
Le 18-05-2009, ? propos de
Re: passer une chaîne d'un char [] à un autre char [],
Marc Espie ?crivait dans fr.comp.lang.c :
In article <87skj2dx4f.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
espie@lain.home (Marc Espie) writes:
| C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se
défendre dans ce forum, on peut exclure cet attribut de la discussion.
C'est pas comme si ca faisait pas quelques annees que je le disais, y
compris dans une discussion avec lui dans une langue qu'il parle...
+1 (et dans des discussions privées dans sa langue maternelle et
portant sur l'interprétation des specs POSIX et d'une sombre histoire de
mélangeage de pinceaux entre le futur et le conditionnel...).
Le 18-05-2009, ? propos de Re: passer une chaîne d'un char [] à un autre char [], Marc Espie ?crivait dans fr.comp.lang.c :
In article , Gabriel Dos Reis wrote:
(Marc Espie) writes: | C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
M'enfin, je crois que jusqu'à ce qu'on lui donne une chance de se défendre dans ce forum, on peut exclure cet attribut de la discussion.
C'est pas comme si ca faisait pas quelques annees que je le disais, y compris dans une discussion avec lui dans une langue qu'il parle...
+1 (et dans des discussions privées dans sa langue maternelle et portant sur l'interprétation des specs POSIX et d'une sombre histoire de mélangeage de pinceaux entre le futur et le conditionnel...).
JKB
Antoine Leca
Le 18/05/2009 19:32Z, Gabriel Dos Reis écrivit :
Antoine Leca writes:
| [...] tu peux probablement arrêter de faire du C | et passer tout de go à n'importe lequel de ces langages « bien faits », | qui incorpore ramasse-miettes, type String et références...
C'est une conclusion possible si on ajoute des hypothèses extrêmes à ce que j'ai suggéré.
Content de voir que tu as compris la substantifique moelle de mon propos.
[...]
Je ne suis pas certain que le C se définit (au sens du « C spirit ») comme emmpiler des rustines sur rustines :-)
Ce n'est peut-être pas l'esprit, mais c'est bien la manière qui a prévalue ! DMR a pondu un certain nombre de versions, en empilant des rustines, jusqu'à obtenir quelque chose qui tienne la route _dans la pratique_; puis est venue une première phase de théorisation avec le K&R, qui alors a permis au langage de se répandre, et donc à tout plein de nouvelles rustines de voir le jour... Ensuite est venue une deuxième couche de normalisation, avec un tri important dans le stock de rustines (et la mise en place de quelques nouvelles, comme <stdlib.h> ou wchar_t). Le débit s'est ensuite un peu tari, mais la source existe encore : long long est une nouvelle rustine (qui a fait circuler pas mal d'octets).
Au final, les rustines sont surtout le signal que les améliorations se font petit à petit, ce qui est un gage de pérennité de l'existant, et que l'on peut aussi voir comme un refus de changements importants. Et cela caractérise bien le langage C (du moins au XXIe siècle).
Antoine
Le 18/05/2009 19:32Z, Gabriel Dos Reis écrivit :
Antoine Leca writes:
| [...] tu peux probablement arrêter de faire du C
| et passer tout de go à n'importe lequel de ces langages « bien faits »,
| qui incorpore ramasse-miettes, type String et références...
C'est une conclusion possible si on ajoute des hypothèses extrêmes à ce
que j'ai suggéré.
Content de voir que tu as compris la substantifique moelle de mon propos.
[...]
Je ne suis pas certain que le C se définit (au sens du « C spirit »)
comme emmpiler des rustines sur rustines :-)
Ce n'est peut-être pas l'esprit, mais c'est bien la manière qui a
prévalue ! DMR a pondu un certain nombre de versions, en empilant des
rustines, jusqu'à obtenir quelque chose qui tienne la route _dans la
pratique_; puis est venue une première phase de théorisation avec le
K&R, qui alors a permis au langage de se répandre, et donc à tout plein
de nouvelles rustines de voir le jour...
Ensuite est venue une deuxième couche de normalisation, avec un tri
important dans le stock de rustines (et la mise en place de quelques
nouvelles, comme <stdlib.h> ou wchar_t).
Le débit s'est ensuite un peu tari, mais la source existe encore : long
long est une nouvelle rustine (qui a fait circuler pas mal d'octets).
Au final, les rustines sont surtout le signal que les améliorations se
font petit à petit, ce qui est un gage de pérennité de l'existant, et
que l'on peut aussi voir comme un refus de changements importants.
Et cela caractérise bien le langage C (du moins au XXIe siècle).
| [...] tu peux probablement arrêter de faire du C | et passer tout de go à n'importe lequel de ces langages « bien faits », | qui incorpore ramasse-miettes, type String et références...
C'est une conclusion possible si on ajoute des hypothèses extrêmes à ce que j'ai suggéré.
Content de voir que tu as compris la substantifique moelle de mon propos.
[...]
Je ne suis pas certain que le C se définit (au sens du « C spirit ») comme emmpiler des rustines sur rustines :-)
Ce n'est peut-être pas l'esprit, mais c'est bien la manière qui a prévalue ! DMR a pondu un certain nombre de versions, en empilant des rustines, jusqu'à obtenir quelque chose qui tienne la route _dans la pratique_; puis est venue une première phase de théorisation avec le K&R, qui alors a permis au langage de se répandre, et donc à tout plein de nouvelles rustines de voir le jour... Ensuite est venue une deuxième couche de normalisation, avec un tri important dans le stock de rustines (et la mise en place de quelques nouvelles, comme <stdlib.h> ou wchar_t). Le débit s'est ensuite un peu tari, mais la source existe encore : long long est une nouvelle rustine (qui a fait circuler pas mal d'octets).
Au final, les rustines sont surtout le signal que les améliorations se font petit à petit, ce qui est un gage de pérennité de l'existant, et que l'on peut aussi voir comme un refus de changements importants. Et cela caractérise bien le langage C (du moins au XXIe siècle).
Antoine
Gabriel Dos Reis
Antoine Leca writes:
[...]
| > Je ne suis pas certain que le C se définit (au sens du « C spirit ») | > comme emmpiler des rustines sur rustines :-) | | Ce n'est peut-être pas l'esprit, mais c'est bien la manière qui a | prévalue ! DMR a pondu un certain nombre de versions, en empilant des | rustines, jusqu'à obtenir quelque chose qui tienne la route _dans la | pratique_; puis est venue une première phase de théorisation avec le | K&R, qui alors a permis au langage de se répandre, et donc à tout plein | de nouvelles rustines de voir le jour... | Ensuite est venue une deuxième couche de normalisation, avec un tri | important dans le stock de rustines (et la mise en place de quelques | nouvelles, comme <stdlib.h> ou wchar_t). | Le débit s'est ensuite un peu tari, mais la source existe encore : long | long est une nouvelle rustine (qui a fait circuler pas mal d'octets).
Horreur, ne me parle pas de long long :-( Mais c'est bien une rustine moins nocive « restrict » (alias « noalias »), « variably modified types », « type generic macros », « auto prototyping », « const » qui ne désigne pas une constante, « inline », j'en passe et des meilleurs.
Mon impression est que notre cher bien aimé Comité (que Dieu le protège) est la source principale et l'amplificateur de rustines.
| Au final, les rustines sont surtout le signal que les améliorations se | font petit à petit, ce qui est un gage de pérennité de l'existant, et
Une gage de pérénnité de l'existant, je suis d'accord; mais quelles améliorations ?
| que l'on peut aussi voir comme un refus de changements importants.
« implicit int » a pratiquement disparu :-)
| Et cela caractérise bien le langage C (du moins au XXIe siècle).
notre cher Comité, tu voulais dire ? :-)
-- Gaby
Antoine Leca <root@localhost.invalid> writes:
[...]
| > Je ne suis pas certain que le C se définit (au sens du « C spirit »)
| > comme emmpiler des rustines sur rustines :-)
|
| Ce n'est peut-être pas l'esprit, mais c'est bien la manière qui a
| prévalue ! DMR a pondu un certain nombre de versions, en empilant des
| rustines, jusqu'à obtenir quelque chose qui tienne la route _dans la
| pratique_; puis est venue une première phase de théorisation avec le
| K&R, qui alors a permis au langage de se répandre, et donc à tout plein
| de nouvelles rustines de voir le jour...
| Ensuite est venue une deuxième couche de normalisation, avec un tri
| important dans le stock de rustines (et la mise en place de quelques
| nouvelles, comme <stdlib.h> ou wchar_t).
| Le débit s'est ensuite un peu tari, mais la source existe encore : long
| long est une nouvelle rustine (qui a fait circuler pas mal d'octets).
Horreur, ne me parle pas de long long :-(
Mais c'est bien une rustine moins nocive « restrict » (alias « noalias »),
« variably modified types », « type generic macros », « auto prototyping »,
« const » qui ne désigne pas une constante, « inline », j'en passe et des
meilleurs.
Mon impression est que notre cher bien aimé Comité (que Dieu le protège)
est la source principale et l'amplificateur de rustines.
| Au final, les rustines sont surtout le signal que les améliorations se
| font petit à petit, ce qui est un gage de pérennité de l'existant, et
Une gage de pérénnité de l'existant, je suis d'accord; mais quelles
améliorations ?
| que l'on peut aussi voir comme un refus de changements importants.
« implicit int » a pratiquement disparu :-)
| Et cela caractérise bien le langage C (du moins au XXIe siècle).
| > Je ne suis pas certain que le C se définit (au sens du « C spirit ») | > comme emmpiler des rustines sur rustines :-) | | Ce n'est peut-être pas l'esprit, mais c'est bien la manière qui a | prévalue ! DMR a pondu un certain nombre de versions, en empilant des | rustines, jusqu'à obtenir quelque chose qui tienne la route _dans la | pratique_; puis est venue une première phase de théorisation avec le | K&R, qui alors a permis au langage de se répandre, et donc à tout plein | de nouvelles rustines de voir le jour... | Ensuite est venue une deuxième couche de normalisation, avec un tri | important dans le stock de rustines (et la mise en place de quelques | nouvelles, comme <stdlib.h> ou wchar_t). | Le débit s'est ensuite un peu tari, mais la source existe encore : long | long est une nouvelle rustine (qui a fait circuler pas mal d'octets).
Horreur, ne me parle pas de long long :-( Mais c'est bien une rustine moins nocive « restrict » (alias « noalias »), « variably modified types », « type generic macros », « auto prototyping », « const » qui ne désigne pas une constante, « inline », j'en passe et des meilleurs.
Mon impression est que notre cher bien aimé Comité (que Dieu le protège) est la source principale et l'amplificateur de rustines.
| Au final, les rustines sont surtout le signal que les améliorations se | font petit à petit, ce qui est un gage de pérennité de l'existant, et
Une gage de pérénnité de l'existant, je suis d'accord; mais quelles améliorations ?
| que l'on peut aussi voir comme un refus de changements importants.
« implicit int » a pratiquement disparu :-)
| Et cela caractérise bien le langage C (du moins au XXIe siècle).
notre cher Comité, tu voulais dire ? :-)
-- Gaby
espie
In article , Gabriel Dos Reis wrote:
Horreur, ne me parle pas de long long :-( Mais c'est bien une rustine moins nocive « restrict » (alias « noalias »), « variably modified types », « type generic macros », « auto prototyping », « const » qui ne désigne pas une constante, « inline », j'en passe et des meilleurs.
Mon impression est que notre cher bien aimé Comité (que Dieu le protège) est la source principale et l'amplificateur de rustines.
Mouais, bof, autant pour C89, j'etais heureux, autant pour C99, il y a des tonnes de trucs dont je ne suis pas fan. Et j'ai bien l'impression que c'est parti pour etre bien pire pour la prochaine mouture... la derniere fois que j'avais vu l'extension "safe string handling", c'etait tellement lourd que j'ai cru que c'etait un poisson d'avril. (pour ne parler de l'arithmetique en base 10).
Il y a stdint.h et ca c'est bel et bon.
C'est a croire que certaine grosse boite aurait envie de casser les efforts de normalisation pour que les gens utilisent a la place leur version proprietaire d'un langage similaire...
In article <87r5yli2f9.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
Horreur, ne me parle pas de long long :-(
Mais c'est bien une rustine moins nocive « restrict » (alias « noalias »),
« variably modified types », « type generic macros », « auto prototyping »,
« const » qui ne désigne pas une constante, « inline », j'en passe et des
meilleurs.
Mon impression est que notre cher bien aimé Comité (que Dieu le protège)
est la source principale et l'amplificateur de rustines.
Mouais, bof, autant pour C89, j'etais heureux, autant pour C99, il y a des
tonnes de trucs dont je ne suis pas fan. Et j'ai bien l'impression que c'est
parti pour etre bien pire pour la prochaine mouture... la derniere fois que
j'avais vu l'extension "safe string handling", c'etait tellement lourd que
j'ai cru que c'etait un poisson d'avril. (pour ne parler de l'arithmetique
en base 10).
Il y a stdint.h et ca c'est bel et bon.
C'est a croire que certaine grosse boite aurait envie de casser les efforts
de normalisation pour que les gens utilisent a la place leur version
proprietaire d'un langage similaire...
Horreur, ne me parle pas de long long :-( Mais c'est bien une rustine moins nocive « restrict » (alias « noalias »), « variably modified types », « type generic macros », « auto prototyping », « const » qui ne désigne pas une constante, « inline », j'en passe et des meilleurs.
Mon impression est que notre cher bien aimé Comité (que Dieu le protège) est la source principale et l'amplificateur de rustines.
Mouais, bof, autant pour C89, j'etais heureux, autant pour C99, il y a des tonnes de trucs dont je ne suis pas fan. Et j'ai bien l'impression que c'est parti pour etre bien pire pour la prochaine mouture... la derniere fois que j'avais vu l'extension "safe string handling", c'etait tellement lourd que j'ai cru que c'etait un poisson d'avril. (pour ne parler de l'arithmetique en base 10).
Il y a stdint.h et ca c'est bel et bon.
C'est a croire que certaine grosse boite aurait envie de casser les efforts de normalisation pour que les gens utilisent a la place leur version proprietaire d'un langage similaire...
Gabriel Dos Reis
(Marc Espie) writes:
[...]
| Il y a stdint.h et ca c'est bel et bon.
D'accord.
| C'est a croire que certaine grosse boite aurait envie de casser les efforts | de normalisation pour que les gens utilisent a la place leur version | proprietaire d'un langage similaire...
Je ne suis pas certain que les vilaines « mythiques grosses boîttes » soient la source principale des échecs de notre cher Comité (combien de gens ont vraiment embracés les inventions de C99 ?). Notre cher Comité se débrouille tout seul comme un grand sans l'aide d'imaginaires grosses vilaines boîtes.
-- Gaby
espie@lain.home (Marc Espie) writes:
[...]
| Il y a stdint.h et ca c'est bel et bon.
D'accord.
| C'est a croire que certaine grosse boite aurait envie de casser les efforts
| de normalisation pour que les gens utilisent a la place leur version
| proprietaire d'un langage similaire...
Je ne suis pas certain que les vilaines « mythiques grosses boîttes »
soient la source principale des échecs de notre cher Comité (combien
de gens ont vraiment embracés les inventions de C99 ?). Notre cher
Comité se débrouille tout seul comme un grand sans l'aide
d'imaginaires grosses vilaines boîtes.
| C'est a croire que certaine grosse boite aurait envie de casser les efforts | de normalisation pour que les gens utilisent a la place leur version | proprietaire d'un langage similaire...
Je ne suis pas certain que les vilaines « mythiques grosses boîttes » soient la source principale des échecs de notre cher Comité (combien de gens ont vraiment embracés les inventions de C99 ?). Notre cher Comité se débrouille tout seul comme un grand sans l'aide d'imaginaires grosses vilaines boîtes.
