In article <hs9172$jkd$,
Antoine Leca wrote:JKB écrivit :une en-tête moisie de Solaris demande C99 dès que _POSIX_C_SOURCE
est défini avec une valeur supérieure ou égale à 200112L,
Cela paraît sain, si tu donnes cette valeur c'est que tu prétends
utiliser la norme Posix de 2001, qui sous-entend l'utilisation d'un
compilo C99...
Ces defines, ca a toujours ete la merde.
le principal objectif de ces defines, c'est de dedouaner ton vendeur
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Du coup, on se retrouve a dire qu'on est posix, mais pas xdg-chose, et
tutti-quanti, et generalement ca foire dans des gros projets sur des entetes
qui ne sont pas compatibles avec eux-memes (ou presque).
Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
In article <hs9172$jkd$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
JKB écrivit :
une en-tête moisie de Solaris demande C99 dès que _POSIX_C_SOURCE
est défini avec une valeur supérieure ou égale à 200112L,
Cela paraît sain, si tu donnes cette valeur c'est que tu prétends
utiliser la norme Posix de 2001, qui sous-entend l'utilisation d'un
compilo C99...
Ces defines, ca a toujours ete la merde.
le principal objectif de ces defines, c'est de dedouaner ton vendeur
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Du coup, on se retrouve a dire qu'on est posix, mais pas xdg-chose, et
tutti-quanti, et generalement ca foire dans des gros projets sur des entetes
qui ne sont pas compatibles avec eux-memes (ou presque).
Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
In article <hs9172$jkd$,
Antoine Leca wrote:JKB écrivit :une en-tête moisie de Solaris demande C99 dès que _POSIX_C_SOURCE
est défini avec une valeur supérieure ou égale à 200112L,
Cela paraît sain, si tu donnes cette valeur c'est que tu prétends
utiliser la norme Posix de 2001, qui sous-entend l'utilisation d'un
compilo C99...
Ces defines, ca a toujours ete la merde.
le principal objectif de ces defines, c'est de dedouaner ton vendeur
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Du coup, on se retrouve a dire qu'on est posix, mais pas xdg-chose, et
tutti-quanti, et generalement ca foire dans des gros projets sur des entetes
qui ne sont pas compatibles avec eux-memes (ou presque).
Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
Marc Espie écrivit :In article <hs9172$jkd$,
Antoine Leca wrote:JKB écrivit :une en-tête moisie de Solaris demande C99 dès que _POSIX_C_SOURCE
est défini avec une valeur supérieure ou égale à 200112L,
Cela paraît sain, si tu donnes cette valeur c'est que tu prétends
utiliser la norme Posix de 2001, qui sous-entend l'utilisation d'un
compilo C99...
Ces defines, ca a toujours ete la merde.
C'est pas faux, cela.le principal objectif de ces defines, c'est de dedouaner ton vendeur
Possible. Mais à mon sens, c'est encore plus <censuré> : j'ai bien
l'impression que l'objectif est double : d'un côté dédouaner de
l'utilisation des anciens outils (« c'est plus supporté ») et d'un autre
côté de forcer la migration vers les nouveaux outils : à défaut
d'argument techniques reconnus, l'obsolescence imposée par les comités,
c'est d'un pratique ! (Et si la migration peut être payante ce serait le
top; mais bon, on dirait que l'environnement déteint sur les idées...)
Cependant, la position de JKB qui utilise -D_POSIX_C_SOURCE 0112 et se
plaint subséquemment de devoir utiliser C99 est ÀMHA intenable : soit tu
mets-à-jour en augmentant la constante, et le comité POSIX (pas C, qui a
vu cela d'un mauvais œil) t'obliges à passer à C99 ; soit tu ne veux pas
faire la migration, mais alors on ne peut pas réclamer le beurre et
l'argent du beurre, c'est-à-dire que le résultat est bancal, et va
probablement réclamer de la micro-chirurgie de portabilité...
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Oui. Cependant, il faut comparer par rapport à ce qu'il y avait avant ;
et les normes C et POSIX représentent quand même de gros progrès, il y a
un gros pan des bases qui sont maintenant communes à tout le monde.
Du coup, on se retrouve a dire qu'on est posix, mais pas xdg-chose, et
tutti-quanti, et generalement ca foire dans des gros projets sur des entetes
qui ne sont pas compatibles avec eux-memes (ou presque).
Oui. Avant, cela foirait _aussi_ sur les petits projets !
Et sur le long terme, les projets qui font leurs nids, ce sont ceux qui
soit imposent leur norme, soit s'alignent sur le moins-disant (ANSI ou
POSIX:96); je n'arrive pas à décider si POSIX:2001 (donc y compris mmap,
sockets et pas mal d'autres trucs) prend du poids et donc domine XPG>4 ?Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
D'abord, cela n'a pas grand chose à voir : ils étaient aussi très seuls
avec bien peu de gens qui voulaient mettre la main à la pâte (tous les
vendeurs s'intéressant à C++ et surtout, à l'époque, à Java) ; ensuite,
le résultat est évident, C99 n'a pas, et de très loin, le poids de C90
(et le comité souhaite que C1x corrige le tir, mais c'est un souhait) :
en conséquence, la bonne attitude, c'est de l'ignorer (dans la mesure du
possible); ce qui, si on revient au problème de JKB, revient à ne pas
utiliser POSIX:2001... et je n'ai pas l'impression d'être le seul avec
cette idée-là en tête.
Par ailleurs, à propos des fameux problèmes de compatibilité C++ :
je sais qu'il y a un binz avec inline (que je n'ai pas compris dans la
pratique; l'argument qui dit « tu peux écrire en C légal du code qui est
stupide _et_ qui ne respecte pas la norme C++ » est aussi intelligent
que de vouloir à tout prix utiliser class comme nom de type global...)
Mais au-delà je n'ai toujours pas compris où était le(s) problème(s) ?
Qui a des pointeurs (raisonnables) ?
Quant à dire que les ajouts de C99 pèsent sur la compatibilité, c'est
aussi une tautologie : chaque modification qui précise un point d'une
norme quelle qu'elle soit, constitue pour une partie des précédents
utilisateurs une régression : l'idée étant que cette partie soit la plus
petite possible, et que dans l'autre plateau de la balance la
contrepartie soit la plus grande possible : il en est ainsi de l'idée
comme quoi long dev[r]ait désigner le plus grand type entier, qui
découle de la rédaction de K&R puis de C89 (sans que ce soit l'intention
initiale) et que certains ont mis en avant pour réfuter C99, alors même
que dans la pratique long joue dans la migration 32/64 bits le même rôle
que jouait int dans la migration 16/32... Et si long ne vaut pas 64 bits
sur (toutes) les machines 64 bits, cela ne vient pas de l'empressement
du comité C mais au contraire, ils furent mis devant le fait accompli.
Marc Espie écrivit :
In article <hs9172$jkd$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
JKB écrivit :
une en-tête moisie de Solaris demande C99 dès que _POSIX_C_SOURCE
est défini avec une valeur supérieure ou égale à 200112L,
Cela paraît sain, si tu donnes cette valeur c'est que tu prétends
utiliser la norme Posix de 2001, qui sous-entend l'utilisation d'un
compilo C99...
Ces defines, ca a toujours ete la merde.
C'est pas faux, cela.
le principal objectif de ces defines, c'est de dedouaner ton vendeur
Possible. Mais à mon sens, c'est encore plus <censuré> : j'ai bien
l'impression que l'objectif est double : d'un côté dédouaner de
l'utilisation des anciens outils (« c'est plus supporté ») et d'un autre
côté de forcer la migration vers les nouveaux outils : à défaut
d'argument techniques reconnus, l'obsolescence imposée par les comités,
c'est d'un pratique ! (Et si la migration peut être payante ce serait le
top; mais bon, on dirait que l'environnement déteint sur les idées...)
Cependant, la position de JKB qui utilise -D_POSIX_C_SOURCE 0112 et se
plaint subséquemment de devoir utiliser C99 est ÀMHA intenable : soit tu
mets-à-jour en augmentant la constante, et le comité POSIX (pas C, qui a
vu cela d'un mauvais œil) t'obliges à passer à C99 ; soit tu ne veux pas
faire la migration, mais alors on ne peut pas réclamer le beurre et
l'argent du beurre, c'est-à-dire que le résultat est bancal, et va
probablement réclamer de la micro-chirurgie de portabilité...
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Oui. Cependant, il faut comparer par rapport à ce qu'il y avait avant ;
et les normes C et POSIX représentent quand même de gros progrès, il y a
un gros pan des bases qui sont maintenant communes à tout le monde.
Du coup, on se retrouve a dire qu'on est posix, mais pas xdg-chose, et
tutti-quanti, et generalement ca foire dans des gros projets sur des entetes
qui ne sont pas compatibles avec eux-memes (ou presque).
Oui. Avant, cela foirait _aussi_ sur les petits projets !
Et sur le long terme, les projets qui font leurs nids, ce sont ceux qui
soit imposent leur norme, soit s'alignent sur le moins-disant (ANSI ou
POSIX:96); je n'arrive pas à décider si POSIX:2001 (donc y compris mmap,
sockets et pas mal d'autres trucs) prend du poids et donc domine XPG>4 ?
Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
D'abord, cela n'a pas grand chose à voir : ils étaient aussi très seuls
avec bien peu de gens qui voulaient mettre la main à la pâte (tous les
vendeurs s'intéressant à C++ et surtout, à l'époque, à Java) ; ensuite,
le résultat est évident, C99 n'a pas, et de très loin, le poids de C90
(et le comité souhaite que C1x corrige le tir, mais c'est un souhait) :
en conséquence, la bonne attitude, c'est de l'ignorer (dans la mesure du
possible); ce qui, si on revient au problème de JKB, revient à ne pas
utiliser POSIX:2001... et je n'ai pas l'impression d'être le seul avec
cette idée-là en tête.
Par ailleurs, à propos des fameux problèmes de compatibilité C++ :
je sais qu'il y a un binz avec inline (que je n'ai pas compris dans la
pratique; l'argument qui dit « tu peux écrire en C légal du code qui est
stupide _et_ qui ne respecte pas la norme C++ » est aussi intelligent
que de vouloir à tout prix utiliser class comme nom de type global...)
Mais au-delà je n'ai toujours pas compris où était le(s) problème(s) ?
Qui a des pointeurs (raisonnables) ?
Quant à dire que les ajouts de C99 pèsent sur la compatibilité, c'est
aussi une tautologie : chaque modification qui précise un point d'une
norme quelle qu'elle soit, constitue pour une partie des précédents
utilisateurs une régression : l'idée étant que cette partie soit la plus
petite possible, et que dans l'autre plateau de la balance la
contrepartie soit la plus grande possible : il en est ainsi de l'idée
comme quoi long dev[r]ait désigner le plus grand type entier, qui
découle de la rédaction de K&R puis de C89 (sans que ce soit l'intention
initiale) et que certains ont mis en avant pour réfuter C99, alors même
que dans la pratique long joue dans la migration 32/64 bits le même rôle
que jouait int dans la migration 16/32... Et si long ne vaut pas 64 bits
sur (toutes) les machines 64 bits, cela ne vient pas de l'empressement
du comité C mais au contraire, ils furent mis devant le fait accompli.
Marc Espie écrivit :In article <hs9172$jkd$,
Antoine Leca wrote:JKB écrivit :une en-tête moisie de Solaris demande C99 dès que _POSIX_C_SOURCE
est défini avec une valeur supérieure ou égale à 200112L,
Cela paraît sain, si tu donnes cette valeur c'est que tu prétends
utiliser la norme Posix de 2001, qui sous-entend l'utilisation d'un
compilo C99...
Ces defines, ca a toujours ete la merde.
C'est pas faux, cela.le principal objectif de ces defines, c'est de dedouaner ton vendeur
Possible. Mais à mon sens, c'est encore plus <censuré> : j'ai bien
l'impression que l'objectif est double : d'un côté dédouaner de
l'utilisation des anciens outils (« c'est plus supporté ») et d'un autre
côté de forcer la migration vers les nouveaux outils : à défaut
d'argument techniques reconnus, l'obsolescence imposée par les comités,
c'est d'un pratique ! (Et si la migration peut être payante ce serait le
top; mais bon, on dirait que l'environnement déteint sur les idées...)
Cependant, la position de JKB qui utilise -D_POSIX_C_SOURCE 0112 et se
plaint subséquemment de devoir utiliser C99 est ÀMHA intenable : soit tu
mets-à-jour en augmentant la constante, et le comité POSIX (pas C, qui a
vu cela d'un mauvais œil) t'obliges à passer à C99 ; soit tu ne veux pas
faire la migration, mais alors on ne peut pas réclamer le beurre et
l'argent du beurre, c'est-à-dire que le résultat est bancal, et va
probablement réclamer de la micro-chirurgie de portabilité...
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Oui. Cependant, il faut comparer par rapport à ce qu'il y avait avant ;
et les normes C et POSIX représentent quand même de gros progrès, il y a
un gros pan des bases qui sont maintenant communes à tout le monde.
Du coup, on se retrouve a dire qu'on est posix, mais pas xdg-chose, et
tutti-quanti, et generalement ca foire dans des gros projets sur des entetes
qui ne sont pas compatibles avec eux-memes (ou presque).
Oui. Avant, cela foirait _aussi_ sur les petits projets !
Et sur le long terme, les projets qui font leurs nids, ce sont ceux qui
soit imposent leur norme, soit s'alignent sur le moins-disant (ANSI ou
POSIX:96); je n'arrive pas à décider si POSIX:2001 (donc y compris mmap,
sockets et pas mal d'autres trucs) prend du poids et donc domine XPG>4 ?Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
D'abord, cela n'a pas grand chose à voir : ils étaient aussi très seuls
avec bien peu de gens qui voulaient mettre la main à la pâte (tous les
vendeurs s'intéressant à C++ et surtout, à l'époque, à Java) ; ensuite,
le résultat est évident, C99 n'a pas, et de très loin, le poids de C90
(et le comité souhaite que C1x corrige le tir, mais c'est un souhait) :
en conséquence, la bonne attitude, c'est de l'ignorer (dans la mesure du
possible); ce qui, si on revient au problème de JKB, revient à ne pas
utiliser POSIX:2001... et je n'ai pas l'impression d'être le seul avec
cette idée-là en tête.
Par ailleurs, à propos des fameux problèmes de compatibilité C++ :
je sais qu'il y a un binz avec inline (que je n'ai pas compris dans la
pratique; l'argument qui dit « tu peux écrire en C légal du code qui est
stupide _et_ qui ne respecte pas la norme C++ » est aussi intelligent
que de vouloir à tout prix utiliser class comme nom de type global...)
Mais au-delà je n'ai toujours pas compris où était le(s) problème(s) ?
Qui a des pointeurs (raisonnables) ?
Quant à dire que les ajouts de C99 pèsent sur la compatibilité, c'est
aussi une tautologie : chaque modification qui précise un point d'une
norme quelle qu'elle soit, constitue pour une partie des précédents
utilisateurs une régression : l'idée étant que cette partie soit la plus
petite possible, et que dans l'autre plateau de la balance la
contrepartie soit la plus grande possible : il en est ainsi de l'idée
comme quoi long dev[r]ait désigner le plus grand type entier, qui
découle de la rédaction de K&R puis de C89 (sans que ce soit l'intention
initiale) et que certains ont mis en avant pour réfuter C99, alors même
que dans la pratique long joue dans la migration 32/64 bits le même rôle
que jouait int dans la migration 16/32... Et si long ne vaut pas 64 bits
sur (toutes) les machines 64 bits, cela ne vient pas de l'empressement
du comité C mais au contraire, ils furent mis devant le fait accompli.
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Oui. Cependant, il faut comparer par rapport à ce qu'il y avait avant ;
et les normes C et POSIX représentent quand même de gros progrès, il y a
un gros pan des bases qui sont maintenant communes à tout le monde.
Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
D'abord, cela n'a pas grand chose à voir : ils étaient aussi très seuls
avec bien peu de gens qui voulaient mettre la main à la pâte (tous les
vendeurs s'intéressant à C++ et surtout, à l'époque, à Java) ; ensuite,
le résultat est évident, C99 n'a pas, et de très loin, le poids de C90
(et le comité souhaite que C1x corrige le tir, mais c'est un souhait) :
en conséquence, la bonne attitude, c'est de l'ignorer (dans la mesure du
possible); ce qui, si on revient au problème de JKB, revient à ne pas
utiliser POSIX:2001... et je n'ai pas l'impression d'être le seul avec
cette idée-là en tête.
Par ailleurs, à propos des fameux problèmes de compatibilité C++ :
je sais qu'il y a un binz avec inline (que je n'ai pas compris dans la
pratique; l'argument qui dit « tu peux écrire en C légal du code qui est
stupide _et_ qui ne respecte pas la norme C++ » est aussi intelligent
que de vouloir à tout prix utiliser class comme nom de type global...)
Mais au-delà je n'ai toujours pas compris où était le(s) problème(s) ?
Qui a des pointeurs (raisonnables) ?
Quant à dire que les ajouts de C99 pèsent sur la compatibilité, c'est
aussi une tautologie : chaque modification qui précise un point d'une
norme quelle qu'elle soit, constitue pour une partie des précédents
utilisateurs une régression : l'idée étant que cette partie soit la plus
petite possible, et que dans l'autre plateau de la balance la
contrepartie soit la plus grande possible : il en est ainsi de l'idée
comme quoi long dev[r]ait désigner le plus grand type entier, qui
découle de la rédaction de K&R puis de C89 (sans que ce soit l'intention
initiale) et que certains ont mis en avant pour réfuter C99, alors même
que dans la pratique long joue dans la migration 32/64 bits le même rôle
que jouait int dans la migration 16/32... Et si long ne vaut pas 64 bits
sur (toutes) les machines 64 bits, cela ne vient pas de l'empressement
du comité C mais au contraire, ils furent mis devant le fait accompli.
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Oui. Cependant, il faut comparer par rapport à ce qu'il y avait avant ;
et les normes C et POSIX représentent quand même de gros progrès, il y a
un gros pan des bases qui sont maintenant communes à tout le monde.
Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
D'abord, cela n'a pas grand chose à voir : ils étaient aussi très seuls
avec bien peu de gens qui voulaient mettre la main à la pâte (tous les
vendeurs s'intéressant à C++ et surtout, à l'époque, à Java) ; ensuite,
le résultat est évident, C99 n'a pas, et de très loin, le poids de C90
(et le comité souhaite que C1x corrige le tir, mais c'est un souhait) :
en conséquence, la bonne attitude, c'est de l'ignorer (dans la mesure du
possible); ce qui, si on revient au problème de JKB, revient à ne pas
utiliser POSIX:2001... et je n'ai pas l'impression d'être le seul avec
cette idée-là en tête.
Par ailleurs, à propos des fameux problèmes de compatibilité C++ :
je sais qu'il y a un binz avec inline (que je n'ai pas compris dans la
pratique; l'argument qui dit « tu peux écrire en C légal du code qui est
stupide _et_ qui ne respecte pas la norme C++ » est aussi intelligent
que de vouloir à tout prix utiliser class comme nom de type global...)
Mais au-delà je n'ai toujours pas compris où était le(s) problème(s) ?
Qui a des pointeurs (raisonnables) ?
Quant à dire que les ajouts de C99 pèsent sur la compatibilité, c'est
aussi une tautologie : chaque modification qui précise un point d'une
norme quelle qu'elle soit, constitue pour une partie des précédents
utilisateurs une régression : l'idée étant que cette partie soit la plus
petite possible, et que dans l'autre plateau de la balance la
contrepartie soit la plus grande possible : il en est ainsi de l'idée
comme quoi long dev[r]ait désigner le plus grand type entier, qui
découle de la rédaction de K&R puis de C89 (sans que ce soit l'intention
initiale) et que certains ont mis en avant pour réfuter C99, alors même
que dans la pratique long joue dans la migration 32/64 bits le même rôle
que jouait int dans la migration 16/32... Et si long ne vaut pas 64 bits
sur (toutes) les machines 64 bits, cela ne vient pas de l'empressement
du comité C mais au contraire, ils furent mis devant le fait accompli.
Pratiquement personne ne programme
avec une norme precise, et les divers systemes ont toujorus des petites
differences d'interpretation de l'un a l'autre.
Oui. Cependant, il faut comparer par rapport à ce qu'il y avait avant ;
et les normes C et POSIX représentent quand même de gros progrès, il y a
un gros pan des bases qui sont maintenant communes à tout le monde.
Et je pourrais un peu raler aussi sur le comite de normalisation C qui a
fait C99 (et sa future suite) un peu tout seul dans son coin, en ignorant
superbement les magnifiques problemes de compatibilite que ca allait poser
avec C++...
D'abord, cela n'a pas grand chose à voir : ils étaient aussi très seuls
avec bien peu de gens qui voulaient mettre la main à la pâte (tous les
vendeurs s'intéressant à C++ et surtout, à l'époque, à Java) ; ensuite,
le résultat est évident, C99 n'a pas, et de très loin, le poids de C90
(et le comité souhaite que C1x corrige le tir, mais c'est un souhait) :
en conséquence, la bonne attitude, c'est de l'ignorer (dans la mesure du
possible); ce qui, si on revient au problème de JKB, revient à ne pas
utiliser POSIX:2001... et je n'ai pas l'impression d'être le seul avec
cette idée-là en tête.
Par ailleurs, à propos des fameux problèmes de compatibilité C++ :
je sais qu'il y a un binz avec inline (que je n'ai pas compris dans la
pratique; l'argument qui dit « tu peux écrire en C légal du code qui est
stupide _et_ qui ne respecte pas la norme C++ » est aussi intelligent
que de vouloir à tout prix utiliser class comme nom de type global...)
Mais au-delà je n'ai toujours pas compris où était le(s) problème(s) ?
Qui a des pointeurs (raisonnables) ?
Quant à dire que les ajouts de C99 pèsent sur la compatibilité, c'est
aussi une tautologie : chaque modification qui précise un point d'une
norme quelle qu'elle soit, constitue pour une partie des précédents
utilisateurs une régression : l'idée étant que cette partie soit la plus
petite possible, et que dans l'autre plateau de la balance la
contrepartie soit la plus grande possible : il en est ainsi de l'idée
comme quoi long dev[r]ait désigner le plus grand type entier, qui
découle de la rédaction de K&R puis de C89 (sans que ce soit l'intention
initiale) et que certains ont mis en avant pour réfuter C99, alors même
que dans la pratique long joue dans la migration 32/64 bits le même rôle
que jouait int dans la migration 16/32... Et si long ne vaut pas 64 bits
sur (toutes) les machines 64 bits, cela ne vient pas de l'empressement
du comité C mais au contraire, ils furent mis devant le fait accompli.
Qu'on soit clair, il y a des bouts tres bons dans C99. stdint et cie, c'est
indispensable, et je pense que tout le monde s'en sert aujourd'hui.
Non, c'est plus les aneries de fonctions mathematiques polymorphes mal
foutues qui ont tendance a foutre le bazar.
Le inline "simple" (code dans le fichier d'entetes fonctionne sans
gros souci). c'est plus les extensions gcc a la extern inline et
static inline qui foutent le bazar
La on est en train de nettoyer du code openbsd pour un eventuel passage a
gcc4, et ca implique entre autres d'annoter plein de trucs avec __used
pour dire au compilo "non, ca tu me laisses dans mon fichier objet, si
je l'ai mis, c'est pour que ca serve".
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90, ils n'ont apparemment meme
pas demande leur avis aux gens du comite C++98, et il y a deux/trois bouts
qui ont ete refaits differemment ET de facon incompatible pour redonner
certaines fonctionnalites du C++.
Enfin bon, c'est vrai que ceux-ci n'ont pas trop reagi correctement depuis,
et du coup on ne sait pas trop si les fonctions maths de C99 doivent
vivre dans std::, tr1:: ou ailleurs en C++ (alors que ca aurait ete assez
simple de faire un espace de nom genre stdc99:: ou assimile...)
Qu'on soit clair, il y a des bouts tres bons dans C99. stdint et cie, c'est
indispensable, et je pense que tout le monde s'en sert aujourd'hui.
Non, c'est plus les aneries de fonctions mathematiques polymorphes mal
foutues qui ont tendance a foutre le bazar.
Le inline "simple" (code dans le fichier d'entetes fonctionne sans
gros souci). c'est plus les extensions gcc a la extern inline et
static inline qui foutent le bazar
La on est en train de nettoyer du code openbsd pour un eventuel passage a
gcc4, et ca implique entre autres d'annoter plein de trucs avec __used
pour dire au compilo "non, ca tu me laisses dans mon fichier objet, si
je l'ai mis, c'est pour que ca serve".
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90, ils n'ont apparemment meme
pas demande leur avis aux gens du comite C++98, et il y a deux/trois bouts
qui ont ete refaits differemment ET de facon incompatible pour redonner
certaines fonctionnalites du C++.
Enfin bon, c'est vrai que ceux-ci n'ont pas trop reagi correctement depuis,
et du coup on ne sait pas trop si les fonctions maths de C99 doivent
vivre dans std::, tr1:: ou ailleurs en C++ (alors que ca aurait ete assez
simple de faire un espace de nom genre stdc99:: ou assimile...)
Qu'on soit clair, il y a des bouts tres bons dans C99. stdint et cie, c'est
indispensable, et je pense que tout le monde s'en sert aujourd'hui.
Non, c'est plus les aneries de fonctions mathematiques polymorphes mal
foutues qui ont tendance a foutre le bazar.
Le inline "simple" (code dans le fichier d'entetes fonctionne sans
gros souci). c'est plus les extensions gcc a la extern inline et
static inline qui foutent le bazar
La on est en train de nettoyer du code openbsd pour un eventuel passage a
gcc4, et ca implique entre autres d'annoter plein de trucs avec __used
pour dire au compilo "non, ca tu me laisses dans mon fichier objet, si
je l'ai mis, c'est pour que ca serve".
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90, ils n'ont apparemment meme
pas demande leur avis aux gens du comite C++98, et il y a deux/trois bouts
qui ont ete refaits differemment ET de facon incompatible pour redonner
certaines fonctionnalites du C++.
Enfin bon, c'est vrai que ceux-ci n'ont pas trop reagi correctement depuis,
et du coup on ne sait pas trop si les fonctions maths de C99 doivent
vivre dans std::, tr1:: ou ailleurs en C++ (alors que ca aurait ete assez
simple de faire un espace de nom genre stdc99:: ou assimile...)
Marc Espie wrote:Qu'on soit clair, il y a des bouts tres bons dans C99. stdint et cie, c'est
indispensable, et je pense que tout le monde s'en sert aujourd'hui.
Enfin sauf que sous windows stdint n'est apparu qu'il y a un mois...
Non, c'est plus les aneries de fonctions mathematiques polymorphes mal
foutues qui ont tendance a foutre le bazar.
C'est quoi le problème ?
La on est en train de nettoyer du code openbsd pour un eventuel passage a
gcc4, et ca implique entre autres d'annoter plein de trucs avec __used
pour dire au compilo "non, ca tu me laisses dans mon fichier objet, si
je l'ai mis, c'est pour que ca serve".
Ça me semble raisonnable qu'il faille dire quelque chose de spécial au
compilateur dans ce genre de cas, que ce soit une option globale qui
supprime toute optimisation,
ou des indications locales comme __used.
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90,
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90, ils n'ont apparemment meme
pas demande leur avis aux gens du comite C++98, et il y a deux/trois bouts
qui ont ete refaits differemment ET de facon incompatible pour redonner
certaines fonctionnalites du C++.
Ça, le comité du C ne semble pas toujours très copain avec le C++...
(J'aime bien en particulier un passage de C++0X qui dit explicitement
d'ignorer une note de C99 qui se mêle de la façon dont les programmes C++
doivent interpréter telle fonctionnalité.)
Marc Espie wrote:
Qu'on soit clair, il y a des bouts tres bons dans C99. stdint et cie, c'est
indispensable, et je pense que tout le monde s'en sert aujourd'hui.
Enfin sauf que sous windows stdint n'est apparu qu'il y a un mois...
Non, c'est plus les aneries de fonctions mathematiques polymorphes mal
foutues qui ont tendance a foutre le bazar.
C'est quoi le problème ?
La on est en train de nettoyer du code openbsd pour un eventuel passage a
gcc4, et ca implique entre autres d'annoter plein de trucs avec __used
pour dire au compilo "non, ca tu me laisses dans mon fichier objet, si
je l'ai mis, c'est pour que ca serve".
Ça me semble raisonnable qu'il faille dire quelque chose de spécial au
compilateur dans ce genre de cas, que ce soit une option globale qui
supprime toute optimisation,
ou des indications locales comme __used.
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90,
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90, ils n'ont apparemment meme
pas demande leur avis aux gens du comite C++98, et il y a deux/trois bouts
qui ont ete refaits differemment ET de facon incompatible pour redonner
certaines fonctionnalites du C++.
Ça, le comité du C ne semble pas toujours très copain avec le C++...
(J'aime bien en particulier un passage de C++0X qui dit explicitement
d'ignorer une note de C99 qui se mêle de la façon dont les programmes C++
doivent interpréter telle fonctionnalité.)
Marc Espie wrote:Qu'on soit clair, il y a des bouts tres bons dans C99. stdint et cie, c'est
indispensable, et je pense que tout le monde s'en sert aujourd'hui.
Enfin sauf que sous windows stdint n'est apparu qu'il y a un mois...
Non, c'est plus les aneries de fonctions mathematiques polymorphes mal
foutues qui ont tendance a foutre le bazar.
C'est quoi le problème ?
La on est en train de nettoyer du code openbsd pour un eventuel passage a
gcc4, et ca implique entre autres d'annoter plein de trucs avec __used
pour dire au compilo "non, ca tu me laisses dans mon fichier objet, si
je l'ai mis, c'est pour que ca serve".
Ça me semble raisonnable qu'il faille dire quelque chose de spécial au
compilateur dans ce genre de cas, que ce soit une option globale qui
supprime toute optimisation,
ou des indications locales comme __used.
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90,
ce que je reproche a C99, c'est qu'en etant sorti apres C++98, qui essayait
d'etre "le plus" compatible possible avec C90, ils n'ont apparemment meme
pas demande leur avis aux gens du comite C++98, et il y a deux/trois bouts
qui ont ete refaits differemment ET de facon incompatible pour redonner
certaines fonctionnalites du C++.
Ça, le comité du C ne semble pas toujours très copain avec le C++...
(J'aime bien en particulier un passage de C++0X qui dit explicitement
d'ignorer une note de C99 qui se mêle de la façon dont les programmes C++
doivent interpréter telle fonctionnalité.)
Au moins ils ont changé la version majeure de GCC quand ils se sont mis
à œuvrer avec force vers les optimisations, ce qui donne un point de
repère clair ; ce que je ne comprend pas, c'est pourquoi gcc3 s'est
arrêté au même moment : d'habitude cela provoque une scission, certains
passent sur le nouveau projet (souvent pour l'attrait technique), tandis
que d'autres restent sur l'ancien, pour peaufiner ce qui existe et
donner de ce fait un chemin d'évolution ascendante plus facile à gérer
pour les usagers, qui devraient être la priorité ; ici rien de tel...
ce qui est préoccupant, car cela pourrait affecter la crédibilité du
projet GCC tout entier (c'est une loi d'airain du marketing : si tu ne
te préoccupes pas de tes clients, à terme tu es mort ; quoi qu'en pense
Dilbert, c'est vrai aussi en TIC, et aussi pour le logiciel libre.)
Au moins ils ont changé la version majeure de GCC quand ils se sont mis
à œuvrer avec force vers les optimisations, ce qui donne un point de
repère clair ; ce que je ne comprend pas, c'est pourquoi gcc3 s'est
arrêté au même moment : d'habitude cela provoque une scission, certains
passent sur le nouveau projet (souvent pour l'attrait technique), tandis
que d'autres restent sur l'ancien, pour peaufiner ce qui existe et
donner de ce fait un chemin d'évolution ascendante plus facile à gérer
pour les usagers, qui devraient être la priorité ; ici rien de tel...
ce qui est préoccupant, car cela pourrait affecter la crédibilité du
projet GCC tout entier (c'est une loi d'airain du marketing : si tu ne
te préoccupes pas de tes clients, à terme tu es mort ; quoi qu'en pense
Dilbert, c'est vrai aussi en TIC, et aussi pour le logiciel libre.)
Au moins ils ont changé la version majeure de GCC quand ils se sont mis
à œuvrer avec force vers les optimisations, ce qui donne un point de
repère clair ; ce que je ne comprend pas, c'est pourquoi gcc3 s'est
arrêté au même moment : d'habitude cela provoque une scission, certains
passent sur le nouveau projet (souvent pour l'attrait technique), tandis
que d'autres restent sur l'ancien, pour peaufiner ce qui existe et
donner de ce fait un chemin d'évolution ascendante plus facile à gérer
pour les usagers, qui devraient être la priorité ; ici rien de tel...
ce qui est préoccupant, car cela pourrait affecter la crédibilité du
projet GCC tout entier (c'est une loi d'airain du marketing : si tu ne
te préoccupes pas de tes clients, à terme tu es mort ; quoi qu'en pense
Dilbert, c'est vrai aussi en TIC, et aussi pour le logiciel libre.)
plus gmp, mpfr, et quelques autres gros trucs vachement
indispensables pour un compilo C :(
plus gmp, mpfr, et quelques autres gros trucs vachement
indispensables pour un compilo C :(
plus gmp, mpfr, et quelques autres gros trucs vachement
indispensables pour un compilo C :(
Marc écrivit:
Enfin sauf que sous windows stdint n'est apparu qu'il y a un mois...
Donc si sur *ton* Windows il n'est apparu qu'il y a un mois, c'est
peut-être le fruit d'une certaine volonté de ne PAS l'utiliser...
Que <tgmath.h> implique l'utilisation de magie au niveau du compilateur
Ça me semble raisonnable qu'il faille dire quelque chose de spécial au
compilateur dans ce genre de cas, que ce soit une option globale qui
supprime toute optimisation,
Mauvaise solution (mais trop souvent proposée par les services de
dépannage) : puisque la nouvelle fonctionnalité puissante mais un peu
difficile à maîtriser pose problème, on efface et on enlève *tout*.
Cela s'appelle aussi jeter le bébé avec l'eau du bain.
Oui, et c'est bien ce que sous-entend Marc Espie. Il n'en reste pas
moins qu'il s'agit d'un problème de compatibilité ascendante mal
maîtrisée (par les développeurs de GCC), en l'occurrence incapables
d'avoir annoncer à l'avance dans quel sens ils allaient évoluer (ce qui
aurait permis de poser les __used avant ; ou de standardiser ARGSUSED ou
que sais-je),
et qui en plus avancent à marches forcées au niveau des
fonctionnalités de ce genre (bref, ils n'ont pas donné de temps au temps.)
Le seul souci mais il est de taille, ce
sont (encore une fois) les usagers, qui « persistent » en nombre à
vouloir continuer à utiliser le langage C... et cela inclut des gros,
des énormes projets comme Windows. Bref, il faut faire avec.
Marc écrivit:
Enfin sauf que sous windows stdint n'est apparu qu'il y a un mois...
Donc si sur *ton* Windows il n'est apparu qu'il y a un mois, c'est
peut-être le fruit d'une certaine volonté de ne PAS l'utiliser...
Que <tgmath.h> implique l'utilisation de magie au niveau du compilateur
Ça me semble raisonnable qu'il faille dire quelque chose de spécial au
compilateur dans ce genre de cas, que ce soit une option globale qui
supprime toute optimisation,
Mauvaise solution (mais trop souvent proposée par les services de
dépannage) : puisque la nouvelle fonctionnalité puissante mais un peu
difficile à maîtriser pose problème, on efface et on enlève *tout*.
Cela s'appelle aussi jeter le bébé avec l'eau du bain.
Oui, et c'est bien ce que sous-entend Marc Espie. Il n'en reste pas
moins qu'il s'agit d'un problème de compatibilité ascendante mal
maîtrisée (par les développeurs de GCC), en l'occurrence incapables
d'avoir annoncer à l'avance dans quel sens ils allaient évoluer (ce qui
aurait permis de poser les __used avant ; ou de standardiser ARGSUSED ou
que sais-je),
et qui en plus avancent à marches forcées au niveau des
fonctionnalités de ce genre (bref, ils n'ont pas donné de temps au temps.)
Le seul souci mais il est de taille, ce
sont (encore une fois) les usagers, qui « persistent » en nombre à
vouloir continuer à utiliser le langage C... et cela inclut des gros,
des énormes projets comme Windows. Bref, il faut faire avec.
Marc écrivit:
Enfin sauf que sous windows stdint n'est apparu qu'il y a un mois...
Donc si sur *ton* Windows il n'est apparu qu'il y a un mois, c'est
peut-être le fruit d'une certaine volonté de ne PAS l'utiliser...
Que <tgmath.h> implique l'utilisation de magie au niveau du compilateur
Ça me semble raisonnable qu'il faille dire quelque chose de spécial au
compilateur dans ce genre de cas, que ce soit une option globale qui
supprime toute optimisation,
Mauvaise solution (mais trop souvent proposée par les services de
dépannage) : puisque la nouvelle fonctionnalité puissante mais un peu
difficile à maîtriser pose problème, on efface et on enlève *tout*.
Cela s'appelle aussi jeter le bébé avec l'eau du bain.
Oui, et c'est bien ce que sous-entend Marc Espie. Il n'en reste pas
moins qu'il s'agit d'un problème de compatibilité ascendante mal
maîtrisée (par les développeurs de GCC), en l'occurrence incapables
d'avoir annoncer à l'avance dans quel sens ils allaient évoluer (ce qui
aurait permis de poser les __used avant ; ou de standardiser ARGSUSED ou
que sais-je),
et qui en plus avancent à marches forcées au niveau des
fonctionnalités de ce genre (bref, ils n'ont pas donné de temps au temps.)
Le seul souci mais il est de taille, ce
sont (encore une fois) les usagers, qui « persistent » en nombre à
vouloir continuer à utiliser le langage C... et cela inclut des gros,
des énormes projets comme Windows. Bref, il faut faire avec.
Antoine Leca wrote:et qui en plus avancent à marches forcées au niveau des
fonctionnalités de ce genre (bref, ils n'ont pas donné de temps au temps.)
Personne n'est obligé d'utiliser la dernière version du compilateur, je
ne vois pas bien comment ils étaient censés faire...
Antoine Leca wrote:
et qui en plus avancent à marches forcées au niveau des
fonctionnalités de ce genre (bref, ils n'ont pas donné de temps au temps.)
Personne n'est obligé d'utiliser la dernière version du compilateur, je
ne vois pas bien comment ils étaient censés faire...
Antoine Leca wrote:et qui en plus avancent à marches forcées au niveau des
fonctionnalités de ce genre (bref, ils n'ont pas donné de temps au temps.)
Personne n'est obligé d'utiliser la dernière version du compilateur, je
ne vois pas bien comment ils étaient censés faire...
- celui-ci est surtout finance par quelques boites tres specifiques, qui
paient des gens a plein temps pour bosser dessus.
La ou ca devient carrement chiant, c'est quand tu bosses sur quelque chose
d'un peu specifique qui interesse peu de monde dans les developperus de la
core-team (en gros, pas linux-i386 ou linux-amd64... je suis un peu mauvaise
langue, mais a peine).
Ca te fait souvent des delais d'un ou deux mois.
Comme en plus tu travailles sur une plateforme non mainstream, dans
l'interim, le bootstrap sur ta machine a casse, ce qui te donne encore
2 mois de plus, le temps que les gens de la core-team daignent
s'occuper de ton cas
Pas encore degoute ? Alors on en ajoute encore. La politique de gcc,
en plus, depuis pas mal d'annees, c'est de ne jamais accepter de patchs
pour la version stable: il faut que tu fasses ton developpement en
-current, fasse accepter le patch en -current... pour apres pouvoir
dire que ton patch est critique, refaire un 2e patch en stable
Apres, tu t'etonnes moins qu'il y ait des patchs non committes pour gcc sur
a peu pres toutes les archis un peu obscures: il y a tellement de red tape
au niveau de la FSF qu'une grosse partie des developpeurs opensource ont
totalement laisse tomber (rappel: on fait ca pour le fun, si on doit se
taper un process qui est encore plus chiant que celui de la SSII moyenne...)
de plus en plus dependant d'autres outils gnu (par exemple, il reclame
gmake pour bootstrapper... tous les bsd ont du reverse-engineerer ca pour
faire un systeme de build sans gmake. Et on s'est vu opposer une fin de
non-recevoir a chaque fois qu'on a essaye d'enlever des gnu-makeries du
makefile officiel)...
plus gmp, mpfr, et quelques autres gros trucs vachement
indispensables pour un compilo C :(
Il faut quand meme que je rajoute une note finale sur le passage de GPLv2
a GPLv3, qui n'a pas fait que des amis. C'est pas un hasard si dans Open,
on va peut-etre passer a gcc 4.2.1 (c'est la derniere version sous GPLv2),
et il est fort possible qu'il y ait a terme un fork officiel de gcc base
sur cette version (les gens de l'embarque ne sont pas du tout chaud pour faire
du GPLv3...)
- celui-ci est surtout finance par quelques boites tres specifiques, qui
paient des gens a plein temps pour bosser dessus.
La ou ca devient carrement chiant, c'est quand tu bosses sur quelque chose
d'un peu specifique qui interesse peu de monde dans les developperus de la
core-team (en gros, pas linux-i386 ou linux-amd64... je suis un peu mauvaise
langue, mais a peine).
Ca te fait souvent des delais d'un ou deux mois.
Comme en plus tu travailles sur une plateforme non mainstream, dans
l'interim, le bootstrap sur ta machine a casse, ce qui te donne encore
2 mois de plus, le temps que les gens de la core-team daignent
s'occuper de ton cas
Pas encore degoute ? Alors on en ajoute encore. La politique de gcc,
en plus, depuis pas mal d'annees, c'est de ne jamais accepter de patchs
pour la version stable: il faut que tu fasses ton developpement en
-current, fasse accepter le patch en -current... pour apres pouvoir
dire que ton patch est critique, refaire un 2e patch en stable
Apres, tu t'etonnes moins qu'il y ait des patchs non committes pour gcc sur
a peu pres toutes les archis un peu obscures: il y a tellement de red tape
au niveau de la FSF qu'une grosse partie des developpeurs opensource ont
totalement laisse tomber (rappel: on fait ca pour le fun, si on doit se
taper un process qui est encore plus chiant que celui de la SSII moyenne...)
de plus en plus dependant d'autres outils gnu (par exemple, il reclame
gmake pour bootstrapper... tous les bsd ont du reverse-engineerer ca pour
faire un systeme de build sans gmake. Et on s'est vu opposer une fin de
non-recevoir a chaque fois qu'on a essaye d'enlever des gnu-makeries du
makefile officiel)...
plus gmp, mpfr, et quelques autres gros trucs vachement
indispensables pour un compilo C :(
Il faut quand meme que je rajoute une note finale sur le passage de GPLv2
a GPLv3, qui n'a pas fait que des amis. C'est pas un hasard si dans Open,
on va peut-etre passer a gcc 4.2.1 (c'est la derniere version sous GPLv2),
et il est fort possible qu'il y ait a terme un fork officiel de gcc base
sur cette version (les gens de l'embarque ne sont pas du tout chaud pour faire
du GPLv3...)
- celui-ci est surtout finance par quelques boites tres specifiques, qui
paient des gens a plein temps pour bosser dessus.
La ou ca devient carrement chiant, c'est quand tu bosses sur quelque chose
d'un peu specifique qui interesse peu de monde dans les developperus de la
core-team (en gros, pas linux-i386 ou linux-amd64... je suis un peu mauvaise
langue, mais a peine).
Ca te fait souvent des delais d'un ou deux mois.
Comme en plus tu travailles sur une plateforme non mainstream, dans
l'interim, le bootstrap sur ta machine a casse, ce qui te donne encore
2 mois de plus, le temps que les gens de la core-team daignent
s'occuper de ton cas
Pas encore degoute ? Alors on en ajoute encore. La politique de gcc,
en plus, depuis pas mal d'annees, c'est de ne jamais accepter de patchs
pour la version stable: il faut que tu fasses ton developpement en
-current, fasse accepter le patch en -current... pour apres pouvoir
dire que ton patch est critique, refaire un 2e patch en stable
Apres, tu t'etonnes moins qu'il y ait des patchs non committes pour gcc sur
a peu pres toutes les archis un peu obscures: il y a tellement de red tape
au niveau de la FSF qu'une grosse partie des developpeurs opensource ont
totalement laisse tomber (rappel: on fait ca pour le fun, si on doit se
taper un process qui est encore plus chiant que celui de la SSII moyenne...)
de plus en plus dependant d'autres outils gnu (par exemple, il reclame
gmake pour bootstrapper... tous les bsd ont du reverse-engineerer ca pour
faire un systeme de build sans gmake. Et on s'est vu opposer une fin de
non-recevoir a chaque fois qu'on a essaye d'enlever des gnu-makeries du
makefile officiel)...
plus gmp, mpfr, et quelques autres gros trucs vachement
indispensables pour un compilo C :(
Il faut quand meme que je rajoute une note finale sur le passage de GPLv2
a GPLv3, qui n'a pas fait que des amis. C'est pas un hasard si dans Open,
on va peut-etre passer a gcc 4.2.1 (c'est la derniere version sous GPLv2),
et il est fort possible qu'il y ait a terme un fork officiel de gcc base
sur cette version (les gens de l'embarque ne sont pas du tout chaud pour faire
du GPLv3...)
