« [...] Each comment is replaced by
one space character. [...] ». C'est dans les phases de
traduction, et ça a lieu lors de la tokenisation. « a/**/b » est
l'équivalent de « a b ».
Voilà. C'est équivalent, et c'est bien ce dont il a besoin. Mais c'est
vrai que du coup l'utilisation d'une macro est parfaitement inutile.
« [...] Each comment is replaced by
one space character. [...] ». C'est dans les phases de
traduction, et ça a lieu lors de la tokenisation. « a/**/b » est
l'équivalent de « a b ».
Voilà. C'est équivalent, et c'est bien ce dont il a besoin. Mais c'est
vrai que du coup l'utilisation d'une macro est parfaitement inutile.
« [...] Each comment is replaced by
one space character. [...] ». C'est dans les phases de
traduction, et ça a lieu lors de la tokenisation. « a/**/b » est
l'équivalent de « a b ».
Voilà. C'est équivalent, et c'est bien ce dont il a besoin. Mais c'est
vrai que du coup l'utilisation d'une macro est parfaitement inutile.
Fabien LE LEZ writes:
On Thu, 29 Jun 2006 23:25:22 +0200, (Fabien
Chêne):
(Donc,avec certains préprocesseurs, ton CAT s'écrivait a/**/b ;
Ceci fonctionne
Il me semble qu'en C++, ça ne marche pas, car un commentaire est
considéré comme un séparateur.
ca marche a coup sur dans son cas car il n'a pas besoin de faire un
token a partir de plusieurs.
Que ce soit en C++ ou en C, il me semble me souvenir avoir verifie que
si on respecte la lettre de la norme, ca ne devrait pas pouvoir
remplacer ##. Ca ne m'etonnerait pas que ca le puisse parfois en
pratique.
Fabien LE LEZ <gramster@gramster.com> writes:
On Thu, 29 Jun 2006 23:25:22 +0200, fabien.chene@gmail.com (Fabien
Chêne):
(Donc,
avec certains préprocesseurs, ton CAT s'écrivait a/**/b ;
Ceci fonctionne
Il me semble qu'en C++, ça ne marche pas, car un commentaire est
considéré comme un séparateur.
ca marche a coup sur dans son cas car il n'a pas besoin de faire un
token a partir de plusieurs.
Que ce soit en C++ ou en C, il me semble me souvenir avoir verifie que
si on respecte la lettre de la norme, ca ne devrait pas pouvoir
remplacer ##. Ca ne m'etonnerait pas que ca le puisse parfois en
pratique.
Fabien LE LEZ writes:
On Thu, 29 Jun 2006 23:25:22 +0200, (Fabien
Chêne):
(Donc,avec certains préprocesseurs, ton CAT s'écrivait a/**/b ;
Ceci fonctionne
Il me semble qu'en C++, ça ne marche pas, car un commentaire est
considéré comme un séparateur.
ca marche a coup sur dans son cas car il n'a pas besoin de faire un
token a partir de plusieurs.
Que ce soit en C++ ou en C, il me semble me souvenir avoir verifie que
si on respecte la lettre de la norme, ca ne devrait pas pouvoir
remplacer ##. Ca ne m'etonnerait pas que ca le puisse parfois en
pratique.
"kanze" writes:
[...]
Je crois que cela correspond à la politique de GCC que
j'observe, diagnostiquer les comportements indéfinis comme des
erreurs à la compilation.
Tout à fait, et c'est un but très louable en soi. Le seul
problème, c'est quand en fait, le « comportement indéfini » a
en fait toujours marcher, partout, et de ce fait, se trouver
activement utiliser dans beaucoup de code. Même dans ces cas, en
avertir, c'est bien. Mais tout le monde n'a pas forcément envie
de réécrire tout leur code du jour à lendemain, même si
formellement, c'est incorrect.
Entièrement d'accord. Le compilateur pourrait nous proposer
une option pour accepter le code. Je croyais que c'est ce
qu'il était censé fournir, pour ce qui concerne
-traditional-cpp ...
Un autre cas qui a été évoqué ici, il y a quelques mois :
class A; std::vector<A> v; // A incomplet, comportement indéfini pour
// un composant de la bibliothèque standard
Une option dans GCC/g++ pour accepter ce code serait assez
appréciable.
Le mieux serait que la prochaine norme l'accepte,
est-ce en prévision ?
La première idée que j'ai eu fut d'invoquer g++ -E -P
-traditional-cpp, mais curieusement, sans plus de succès.
Alors là, c'est curieux. Parce que si -traditional-cpp doit
signifier ce que le nom semble, il faudrait bien l'accepter. De
l'autre côté : -traditional-cpp, est-ce le préprocesseur de
Riesser, ou celui de AT&T ? Ni l'un ni l'autre n'exigeait que
le résultat d'une concatenation soit un token. Mais ni l'un ni
l'autre ne connaissait ## non plus : Riesser utiliser a/**/b,
et AT&T a, puis un saut de ligne, et b au début de la ligne
suivant.
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Riesser ou un AT&T ou autre ?
-traditional-cpp
Try to imitate the behavior of old-fashioned C preprocessors, as
opposed to ISO C preprocessors.
Vu le « Try », comment dire que l'option ne repecte pas le
cahier des charges ? :-)
"kanze" <kanze@gabi-soft.fr> writes:
[...]
Je crois que cela correspond à la politique de GCC que
j'observe, diagnostiquer les comportements indéfinis comme des
erreurs à la compilation.
Tout à fait, et c'est un but très louable en soi. Le seul
problème, c'est quand en fait, le « comportement indéfini » a
en fait toujours marcher, partout, et de ce fait, se trouver
activement utiliser dans beaucoup de code. Même dans ces cas, en
avertir, c'est bien. Mais tout le monde n'a pas forcément envie
de réécrire tout leur code du jour à lendemain, même si
formellement, c'est incorrect.
Entièrement d'accord. Le compilateur pourrait nous proposer
une option pour accepter le code. Je croyais que c'est ce
qu'il était censé fournir, pour ce qui concerne
-traditional-cpp ...
Un autre cas qui a été évoqué ici, il y a quelques mois :
class A; std::vector<A> v; // A incomplet, comportement indéfini pour
// un composant de la bibliothèque standard
Une option dans GCC/g++ pour accepter ce code serait assez
appréciable.
Le mieux serait que la prochaine norme l'accepte,
est-ce en prévision ?
La première idée que j'ai eu fut d'invoquer g++ -E -P
-traditional-cpp, mais curieusement, sans plus de succès.
Alors là, c'est curieux. Parce que si -traditional-cpp doit
signifier ce que le nom semble, il faudrait bien l'accepter. De
l'autre côté : -traditional-cpp, est-ce le préprocesseur de
Riesser, ou celui de AT&T ? Ni l'un ni l'autre n'exigeait que
le résultat d'une concatenation soit un token. Mais ni l'un ni
l'autre ne connaissait ## non plus : Riesser utiliser a/**/b,
et AT&T a, puis un saut de ligne, et b au début de la ligne
suivant.
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Riesser ou un AT&T ou autre ?
-traditional-cpp
Try to imitate the behavior of old-fashioned C preprocessors, as
opposed to ISO C preprocessors.
Vu le « Try », comment dire que l'option ne repecte pas le
cahier des charges ? :-)
"kanze" writes:
[...]
Je crois que cela correspond à la politique de GCC que
j'observe, diagnostiquer les comportements indéfinis comme des
erreurs à la compilation.
Tout à fait, et c'est un but très louable en soi. Le seul
problème, c'est quand en fait, le « comportement indéfini » a
en fait toujours marcher, partout, et de ce fait, se trouver
activement utiliser dans beaucoup de code. Même dans ces cas, en
avertir, c'est bien. Mais tout le monde n'a pas forcément envie
de réécrire tout leur code du jour à lendemain, même si
formellement, c'est incorrect.
Entièrement d'accord. Le compilateur pourrait nous proposer
une option pour accepter le code. Je croyais que c'est ce
qu'il était censé fournir, pour ce qui concerne
-traditional-cpp ...
Un autre cas qui a été évoqué ici, il y a quelques mois :
class A; std::vector<A> v; // A incomplet, comportement indéfini pour
// un composant de la bibliothèque standard
Une option dans GCC/g++ pour accepter ce code serait assez
appréciable.
Le mieux serait que la prochaine norme l'accepte,
est-ce en prévision ?
La première idée que j'ai eu fut d'invoquer g++ -E -P
-traditional-cpp, mais curieusement, sans plus de succès.
Alors là, c'est curieux. Parce que si -traditional-cpp doit
signifier ce que le nom semble, il faudrait bien l'accepter. De
l'autre côté : -traditional-cpp, est-ce le préprocesseur de
Riesser, ou celui de AT&T ? Ni l'un ni l'autre n'exigeait que
le résultat d'une concatenation soit un token. Mais ni l'un ni
l'autre ne connaissait ## non plus : Riesser utiliser a/**/b,
et AT&T a, puis un saut de ligne, et b au début de la ligne
suivant.
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Riesser ou un AT&T ou autre ?
-traditional-cpp
Try to imitate the behavior of old-fashioned C preprocessors, as
opposed to ISO C preprocessors.
Vu le « Try », comment dire que l'option ne repecte pas le
cahier des charges ? :-)
La première idée que j'ai eu fut d'invoquer g++ -E -P
-traditional-cpp, mais curieusement, sans plus de succès.
Alors là, c'est curieux. Parce que si -traditional-cpp doit
signifier ce que le nom semble, il faudrait bien l'accepter.
De l'autre côté : -traditional-cpp, est-ce le préprocesseur de
Riesser, ou celui de AT&T ? Ni l'un ni l'autre n'exigeait que le
résultat d'une concatenation soit un token. Mais ni l'un ni
l'autre ne connaissait ## non plus : Riesser utiliser a/**/b, et
AT&T a, puis un saut de ligne, et b au début de la ligne
suivant.
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Riesser ou un AT&T ou autre ?
Envoyer un rapport d'erreur ? Si on a une option, et qu'on ne
sait pas ce qu'il fait, c'est bien un défaut, je crois.
J'ajouterais que, vue que c'est une hack pour supporter quelque
chose qui a changé il y a plus de quinze ans, je comprendrais
bien qu'il n'y investit plus beaucoup d'effort, voire même qu'il
supprime l'option d'ici peu. Qu'on change quelque chose qui a
marché d'une version à l'autre, sans même qu'il y a eu un
avertissement entre-temps, je ne suis pas d'accord. Mais je
reconnais des limites quand même -- au bout de quinze ans, on
pourrait prétendre que les utilisateurs ont eu le temps de faire
l'évolution.
La première idée que j'ai eu fut d'invoquer g++ -E -P
-traditional-cpp, mais curieusement, sans plus de succès.
Alors là, c'est curieux. Parce que si -traditional-cpp doit
signifier ce que le nom semble, il faudrait bien l'accepter.
De l'autre côté : -traditional-cpp, est-ce le préprocesseur de
Riesser, ou celui de AT&T ? Ni l'un ni l'autre n'exigeait que le
résultat d'une concatenation soit un token. Mais ni l'un ni
l'autre ne connaissait ## non plus : Riesser utiliser a/**/b, et
AT&T a, puis un saut de ligne, et b au début de la ligne
suivant.
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Riesser ou un AT&T ou autre ?
Envoyer un rapport d'erreur ? Si on a une option, et qu'on ne
sait pas ce qu'il fait, c'est bien un défaut, je crois.
J'ajouterais que, vue que c'est une hack pour supporter quelque
chose qui a changé il y a plus de quinze ans, je comprendrais
bien qu'il n'y investit plus beaucoup d'effort, voire même qu'il
supprime l'option d'ici peu. Qu'on change quelque chose qui a
marché d'une version à l'autre, sans même qu'il y a eu un
avertissement entre-temps, je ne suis pas d'accord. Mais je
reconnais des limites quand même -- au bout de quinze ans, on
pourrait prétendre que les utilisateurs ont eu le temps de faire
l'évolution.
La première idée que j'ai eu fut d'invoquer g++ -E -P
-traditional-cpp, mais curieusement, sans plus de succès.
Alors là, c'est curieux. Parce que si -traditional-cpp doit
signifier ce que le nom semble, il faudrait bien l'accepter.
De l'autre côté : -traditional-cpp, est-ce le préprocesseur de
Riesser, ou celui de AT&T ? Ni l'un ni l'autre n'exigeait que le
résultat d'une concatenation soit un token. Mais ni l'un ni
l'autre ne connaissait ## non plus : Riesser utiliser a/**/b, et
AT&T a, puis un saut de ligne, et b au début de la ligne
suivant.
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Riesser ou un AT&T ou autre ?
Envoyer un rapport d'erreur ? Si on a une option, et qu'on ne
sait pas ce qu'il fait, c'est bien un défaut, je crois.
J'ajouterais que, vue que c'est une hack pour supporter quelque
chose qui a changé il y a plus de quinze ans, je comprendrais
bien qu'il n'y investit plus beaucoup d'effort, voire même qu'il
supprime l'option d'ici peu. Qu'on change quelque chose qui a
marché d'une version à l'autre, sans même qu'il y a eu un
avertissement entre-temps, je ne suis pas d'accord. Mais je
reconnais des limites quand même -- au bout de quinze ans, on
pourrait prétendre que les utilisateurs ont eu le temps de faire
l'évolution.
James Kanze writes:
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Reisser ou un AT&T ou autre ?
Envoyer un rapport d'erreur ? Si on a une option, et qu'on ne
sait pas ce qu'il fait, c'est bien un défaut, je crois.
Je crois aussi.
A noter que si l'on se réfère aux manuels de GCC-2.95.3, et de
GCC-3.0.4, on a déjà plus de détail :
-traditional-cpp
Attempt to support some aspects of traditional C
preprocessors. Specifically:
* Comments convert to nothing at all, rather than to a
space. This allows traditional token concatenation.
* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
* The predefined macro __STDC__ is not defined when you use
`-traditional', but __GNUC__ is (since the GNU extensions
which __GNUC__ indicates are not affected by
`-traditional'). If you need to write header files that work
differently depending on whether `-traditional' is in use,
by testing both of these predefined macros you can
distinguish four situations: GNU C, traditional GNU C, other
ISO C compilers, and other old C compilers. The predefined
macro __STDC_VERSION__ is also not defined when you use
`-traditional'. See section `Standard Predefined Macros' in
The C Preprocessor, for more discussion of these and other
predefined macros.
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Apparemment, au niveau de la concaténation
traditionelle, il tendait à imiter le préprocesseur de Reisser.
Par contre, il n'est pas dit que le résultat d'une
concaténation soit nécessairement un token valide.
Dans les versions suivantes de la documentation de GCC, on a
le droit a plus minimaliste, et au moins le point sur la
concaténation a changé, et dans les versions de GCC que j'ai,
il n'imite plus le preprocesseur de Reisser, le commentaire
est équivalent à un espace.
J'ajouterais que, vue que c'est une hack pour supporter
quelque chose qui a changé il y a plus de quinze ans, je
comprendrais bien qu'il n'y investit plus beaucoup d'effort,
voire même qu'il supprime l'option d'ici peu. Qu'on change
quelque chose qui a marché d'une version à l'autre, sans
même qu'il y a eu un avertissement entre-temps, je ne suis
pas d'accord. Mais je reconnais des limites quand même -- au
bout de quinze ans, on pourrait prétendre que les
utilisateurs ont eu le temps de faire l'évolution.
On peut comprendre qu'ils rendent l'option obsolète un jour.
Reste qu'on ne sait pas très bien ce que fait cette option
Aujourd'hui ...
James Kanze <kanze.james@neuf.fr> writes:
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Reisser ou un AT&T ou autre ?
Envoyer un rapport d'erreur ? Si on a une option, et qu'on ne
sait pas ce qu'il fait, c'est bien un défaut, je crois.
Je crois aussi.
A noter que si l'on se réfère aux manuels de GCC-2.95.3, et de
GCC-3.0.4, on a déjà plus de détail :
-traditional-cpp
Attempt to support some aspects of traditional C
preprocessors. Specifically:
* Comments convert to nothing at all, rather than to a
space. This allows traditional token concatenation.
* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
* The predefined macro __STDC__ is not defined when you use
`-traditional', but __GNUC__ is (since the GNU extensions
which __GNUC__ indicates are not affected by
`-traditional'). If you need to write header files that work
differently depending on whether `-traditional' is in use,
by testing both of these predefined macros you can
distinguish four situations: GNU C, traditional GNU C, other
ISO C compilers, and other old C compilers. The predefined
macro __STDC_VERSION__ is also not defined when you use
`-traditional'. See section `Standard Predefined Macros' in
The C Preprocessor, for more discussion of these and other
predefined macros.
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Apparemment, au niveau de la concaténation
traditionelle, il tendait à imiter le préprocesseur de Reisser.
Par contre, il n'est pas dit que le résultat d'une
concaténation soit nécessairement un token valide.
Dans les versions suivantes de la documentation de GCC, on a
le droit a plus minimaliste, et au moins le point sur la
concaténation a changé, et dans les versions de GCC que j'ai,
il n'imite plus le preprocesseur de Reisser, le commentaire
est équivalent à un espace.
J'ajouterais que, vue que c'est une hack pour supporter
quelque chose qui a changé il y a plus de quinze ans, je
comprendrais bien qu'il n'y investit plus beaucoup d'effort,
voire même qu'il supprime l'option d'ici peu. Qu'on change
quelque chose qui a marché d'une version à l'autre, sans
même qu'il y a eu un avertissement entre-temps, je ne suis
pas d'accord. Mais je reconnais des limites quand même -- au
bout de quinze ans, on pourrait prétendre que les
utilisateurs ont eu le temps de faire l'évolution.
On peut comprendre qu'ils rendent l'option obsolète un jour.
Reste qu'on ne sait pas très bien ce que fait cette option
Aujourd'hui ...
James Kanze writes:
La documentation de cette option est un peu spartiate, comment
savoir s'il imite un Reisser ou un AT&T ou autre ?
Envoyer un rapport d'erreur ? Si on a une option, et qu'on ne
sait pas ce qu'il fait, c'est bien un défaut, je crois.
Je crois aussi.
A noter que si l'on se réfère aux manuels de GCC-2.95.3, et de
GCC-3.0.4, on a déjà plus de détail :
-traditional-cpp
Attempt to support some aspects of traditional C
preprocessors. Specifically:
* Comments convert to nothing at all, rather than to a
space. This allows traditional token concatenation.
* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
* The predefined macro __STDC__ is not defined when you use
`-traditional', but __GNUC__ is (since the GNU extensions
which __GNUC__ indicates are not affected by
`-traditional'). If you need to write header files that work
differently depending on whether `-traditional' is in use,
by testing both of these predefined macros you can
distinguish four situations: GNU C, traditional GNU C, other
ISO C compilers, and other old C compilers. The predefined
macro __STDC_VERSION__ is also not defined when you use
`-traditional'. See section `Standard Predefined Macros' in
The C Preprocessor, for more discussion of these and other
predefined macros.
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Apparemment, au niveau de la concaténation
traditionelle, il tendait à imiter le préprocesseur de Reisser.
Par contre, il n'est pas dit que le résultat d'une
concaténation soit nécessairement un token valide.
Dans les versions suivantes de la documentation de GCC, on a
le droit a plus minimaliste, et au moins le point sur la
concaténation a changé, et dans les versions de GCC que j'ai,
il n'imite plus le preprocesseur de Reisser, le commentaire
est équivalent à un espace.
J'ajouterais que, vue que c'est une hack pour supporter
quelque chose qui a changé il y a plus de quinze ans, je
comprendrais bien qu'il n'y investit plus beaucoup d'effort,
voire même qu'il supprime l'option d'ici peu. Qu'on change
quelque chose qui a marché d'une version à l'autre, sans
même qu'il y a eu un avertissement entre-temps, je ne suis
pas d'accord. Mais je reconnais des limites quand même -- au
bout de quinze ans, on pourrait prétendre que les
utilisateurs ont eu le temps de faire l'évolution.
On peut comprendre qu'ils rendent l'option obsolète un jour.
Reste qu'on ne sait pas très bien ce que fait cette option
Aujourd'hui ...
-traditional-cpp
On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
-traditional-cpp
On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
-traditional-cpp
On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
Aussi de Reisser. Je suis 100% sûr que ça ne marchait pas avec
le préprocesseur de AT&T. Mais pour être vraiment Reisser, il
faudrait que l'expansion ait lieu dans les constantes de
caractère aussi.
* The predefined macro __STDC__ is not defined when you use
`-traditional', but __GNUC__ is (since the GNU extensions
which __GNUC__ indicates are not affected by
`-traditional'). If you need to write header files that work
differently depending on whether `-traditional' is in use,
by testing both of these predefined macros you can
distinguish four situations: GNU C, traditional GNU C, other
ISO C compilers, and other old C compilers. The predefined
macro __STDC_VERSION__ is also not defined when you use
`-traditional'. See section `Standard Predefined Macros' in
The C Preprocessor, for more discussion of these and other
predefined macros.
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Et ça c'est carrément bizarre. Une constante de chaîne n'a
jamais eu, et n'a pas aujourd'hui, le droit de contenir un saut
à la ligne. C'est une erreur, qui exige une diagnostique. (Et
c'est quelque chose ou le préprocesseur AT&T et la norme, et je
crois aussi Reisser, sont tous d'accord.)
J'ajouterais que, vue que c'est une hack pour supporter
quelque chose qui a changé il y a plus de quinze ans, je
comprendrais bien qu'il n'y investit plus beaucoup d'effort,
voire même qu'il supprime l'option d'ici peu. Qu'on change
quelque chose qui a marché d'une version à l'autre, sans
même qu'il y a eu un avertissement entre-temps, je ne suis
pas d'accord. Mais je reconnais des limites quand même -- au
bout de quinze ans, on pourrait prétendre que les
utilisateurs ont eu le temps de faire l'évolution.
On peut comprendre qu'ils rendent l'option obsolète un jour.
Reste qu'on ne sait pas très bien ce que fait cette option
Aujourd'hui ...
Peut-être rien ? Peut-être elle n'existe que pour ne pas casser
des fichiers make.
* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
Aussi de Reisser. Je suis 100% sûr que ça ne marchait pas avec
le préprocesseur de AT&T. Mais pour être vraiment Reisser, il
faudrait que l'expansion ait lieu dans les constantes de
caractère aussi.
* The predefined macro __STDC__ is not defined when you use
`-traditional', but __GNUC__ is (since the GNU extensions
which __GNUC__ indicates are not affected by
`-traditional'). If you need to write header files that work
differently depending on whether `-traditional' is in use,
by testing both of these predefined macros you can
distinguish four situations: GNU C, traditional GNU C, other
ISO C compilers, and other old C compilers. The predefined
macro __STDC_VERSION__ is also not defined when you use
`-traditional'. See section `Standard Predefined Macros' in
The C Preprocessor, for more discussion of these and other
predefined macros.
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Et ça c'est carrément bizarre. Une constante de chaîne n'a
jamais eu, et n'a pas aujourd'hui, le droit de contenir un saut
à la ligne. C'est une erreur, qui exige une diagnostique. (Et
c'est quelque chose ou le préprocesseur AT&T et la norme, et je
crois aussi Reisser, sont tous d'accord.)
J'ajouterais que, vue que c'est une hack pour supporter
quelque chose qui a changé il y a plus de quinze ans, je
comprendrais bien qu'il n'y investit plus beaucoup d'effort,
voire même qu'il supprime l'option d'ici peu. Qu'on change
quelque chose qui a marché d'une version à l'autre, sans
même qu'il y a eu un avertissement entre-temps, je ne suis
pas d'accord. Mais je reconnais des limites quand même -- au
bout de quinze ans, on pourrait prétendre que les
utilisateurs ont eu le temps de faire l'évolution.
On peut comprendre qu'ils rendent l'option obsolète un jour.
Reste qu'on ne sait pas très bien ce que fait cette option
Aujourd'hui ...
Peut-être rien ? Peut-être elle n'existe que pour ne pas casser
des fichiers make.
* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
Aussi de Reisser. Je suis 100% sûr que ça ne marchait pas avec
le préprocesseur de AT&T. Mais pour être vraiment Reisser, il
faudrait que l'expansion ait lieu dans les constantes de
caractère aussi.
* The predefined macro __STDC__ is not defined when you use
`-traditional', but __GNUC__ is (since the GNU extensions
which __GNUC__ indicates are not affected by
`-traditional'). If you need to write header files that work
differently depending on whether `-traditional' is in use,
by testing both of these predefined macros you can
distinguish four situations: GNU C, traditional GNU C, other
ISO C compilers, and other old C compilers. The predefined
macro __STDC_VERSION__ is also not defined when you use
`-traditional'. See section `Standard Predefined Macros' in
The C Preprocessor, for more discussion of these and other
predefined macros.
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Et ça c'est carrément bizarre. Une constante de chaîne n'a
jamais eu, et n'a pas aujourd'hui, le droit de contenir un saut
à la ligne. C'est une erreur, qui exige une diagnostique. (Et
c'est quelque chose ou le préprocesseur AT&T et la norme, et je
crois aussi Reisser, sont tous d'accord.)
J'ajouterais que, vue que c'est une hack pour supporter
quelque chose qui a changé il y a plus de quinze ans, je
comprendrais bien qu'il n'y investit plus beaucoup d'effort,
voire même qu'il supprime l'option d'ici peu. Qu'on change
quelque chose qui a marché d'une version à l'autre, sans
même qu'il y a eu un avertissement entre-temps, je ne suis
pas d'accord. Mais je reconnais des limites quand même -- au
bout de quinze ans, on pourrait prétendre que les
utilisateurs ont eu le temps de faire l'évolution.
On peut comprendre qu'ils rendent l'option obsolète un jour.
Reste qu'on ne sait pas très bien ce que fait cette option
Aujourd'hui ...
Peut-être rien ? Peut-être elle n'existe que pour ne pas casser
des fichiers make.
Fabien Chêne wrote:
[...]-traditional-cpp
[...]On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
Suite à un essai rapide, j'ai l'impression que cette option ne
fonctionne pas du tout avec g++, seulement avec gcc. Au moins en
ce qui concerne la remplacement des paramètres dans une chaîne.
Fabien Chêne wrote:
[...]
-traditional-cpp
[...]
On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
Suite à un essai rapide, j'ai l'impression que cette option ne
fonctionne pas du tout avec g++, seulement avec gcc. Au moins en
ce qui concerne la remplacement des paramètres dans une chaîne.
Fabien Chêne wrote:
[...]-traditional-cpp
[...]On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
Suite à un essai rapide, j'ai l'impression que cette option ne
fonctionne pas du tout avec g++, seulement avec gcc. Au moins en
ce qui concerne la remplacement des paramètres dans une chaîne.
"kanze" writes:* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
Aussi de Reisser. Je suis 100% sûr que ça ne marchait pas
avec le préprocesseur de AT&T. Mais pour être vraiment
Reisser, il faudrait que l'expansion ait lieu dans les
constantes de caractère aussi.
C'est à dire ?
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Et ça c'est carrément bizarre. Une constante de chaîne n'a
jamais eu, et n'a pas aujourd'hui, le droit de contenir un
saut à la ligne. C'est une erreur, qui exige une
diagnostique. (Et c'est quelque chose ou le préprocesseur
AT&T et la norme, et je crois aussi Reisser, sont tous
d'accord.)
Il serait intéressant de savoir de quel préprocesseur «
old-fashion » provient ce dernier paragraphe. J'ai du mal à
croire qu'ils l'ait inventé de toute pièce :-/
"kanze" <kanze@gabi-soft.fr> writes:
* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
Aussi de Reisser. Je suis 100% sûr que ça ne marchait pas
avec le préprocesseur de AT&T. Mais pour être vraiment
Reisser, il faudrait que l'expansion ait lieu dans les
constantes de caractère aussi.
C'est à dire ?
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Et ça c'est carrément bizarre. Une constante de chaîne n'a
jamais eu, et n'a pas aujourd'hui, le droit de contenir un
saut à la ligne. C'est une erreur, qui exige une
diagnostique. (Et c'est quelque chose ou le préprocesseur
AT&T et la norme, et je crois aussi Reisser, sont tous
d'accord.)
Il serait intéressant de savoir de quel préprocesseur «
old-fashion » provient ce dernier paragraphe. J'ai du mal à
croire qu'ils l'ait inventé de toute pièce :-/
"kanze" writes:* In a preprocessing directive, the `#' symbol must appear as
the first character of a line.
* Macro arguments are recognized within string constants in a
macro definition (and their values are stringified, though
without additional quote marks, when they appear in such a
context). The preprocessor always considers a string
constant to end at a newline.
Aussi de Reisser. Je suis 100% sûr que ça ne marchait pas
avec le préprocesseur de AT&T. Mais pour être vraiment
Reisser, il faudrait que l'expansion ait lieu dans les
constantes de caractère aussi.
C'est à dire ?
* The preprocessor considers a string constant to end at a
newline (unless the newline is escaped with `'). (Without
`-traditional', string constants can contain the newline
character as typed.)
Et ça c'est carrément bizarre. Une constante de chaîne n'a
jamais eu, et n'a pas aujourd'hui, le droit de contenir un
saut à la ligne. C'est une erreur, qui exige une
diagnostique. (Et c'est quelque chose ou le préprocesseur
AT&T et la norme, et je crois aussi Reisser, sont tous
d'accord.)
Il serait intéressant de savoir de quel préprocesseur «
old-fashion » provient ce dernier paragraphe. J'ai du mal à
croire qu'ils l'ait inventé de toute pièce :-/
"kanze" writes:Fabien Chêne wrote:
[...]-traditional-cpp
[...]On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
Suite à un essai rapide, j'ai l'impression que cette option ne
fonctionne pas du tout avec g++, seulement avec gcc. Au moins en
ce qui concerne la remplacement des paramètres dans une chaîne.
Un essai rapide pour la concaténation « à la Reisser » sur
GCC-3.4.6 me donne un résultat identique avec gcc et g++, en
mode traditionnel -- ça ne concatène pas. C'est bien cela dont
tu parles ? Et cela produit un résultat différent ?
"kanze" <kanze@gabi-soft.fr> writes:
Fabien Chêne wrote:
[...]
-traditional-cpp
[...]
On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
Suite à un essai rapide, j'ai l'impression que cette option ne
fonctionne pas du tout avec g++, seulement avec gcc. Au moins en
ce qui concerne la remplacement des paramètres dans une chaîne.
Un essai rapide pour la concaténation « à la Reisser » sur
GCC-3.4.6 me donne un résultat identique avec gcc et g++, en
mode traditionnel -- ça ne concatène pas. C'est bien cela dont
tu parles ? Et cela produit un résultat différent ?
"kanze" writes:Fabien Chêne wrote:
[...]-traditional-cpp
[...]On peut comprendre qu'ils rendent l'option obsolète un jour. Reste
qu'on ne sait pas très bien ce que fait cette option Aujourd'hui ...
Suite à un essai rapide, j'ai l'impression que cette option ne
fonctionne pas du tout avec g++, seulement avec gcc. Au moins en
ce qui concerne la remplacement des paramètres dans une chaîne.
Un essai rapide pour la concaténation « à la Reisser » sur
GCC-3.4.6 me donne un résultat identique avec gcc et g++, en
mode traditionnel -- ça ne concatène pas. C'est bien cela dont
tu parles ? Et cela produit un résultat différent ?
