De toute façon, la direction de l'évolution est claire, et ça ne m'étonnerait pas de voir disparaître l'option dans une version future.
Je crois que ce qui les bloque ce sont les utilisations traditionnelles du preprocesseurs C dans des contextes hors du langage C, imake par exemple; il me semble me souvenir qu'emacs a utilise quelque chose du genre pour sa configuration; si c'est toujours le cas, il va avoir quelqu'un d'influent qui va s'opposer bien fort.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"kanze" <kanze@gabi-soft.fr> writes:
De toute façon, la direction de l'évolution est claire, et ça ne
m'étonnerait pas de voir disparaître l'option dans une version
future.
Je crois que ce qui les bloque ce sont les utilisations
traditionnelles du preprocesseurs C dans des contextes hors du
langage C, imake par exemple; il me semble me souvenir qu'emacs a
utilise quelque chose du genre pour sa configuration; si c'est
toujours le cas, il va avoir quelqu'un d'influent qui va s'opposer
bien fort.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
De toute façon, la direction de l'évolution est claire, et ça ne m'étonnerait pas de voir disparaître l'option dans une version future.
Je crois que ce qui les bloque ce sont les utilisations traditionnelles du preprocesseurs C dans des contextes hors du langage C, imake par exemple; il me semble me souvenir qu'emacs a utilise quelque chose du genre pour sa configuration; si c'est toujours le cas, il va avoir quelqu'un d'influent qui va s'opposer bien fort.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze
Jean-Marc Bourguet wrote:
"kanze" writes:
De toute façon, la direction de l'évolution est claire, et ça ne m'étonnerait pas de voir disparaître l'option dans une version future.
Je crois que ce qui les bloque ce sont les utilisations traditionnelles du preprocesseurs C dans des contextes hors du langage C, imake par exemple; il me semble me souvenir qu'emacs a utilise quelque chose du genre pour sa configuration; si c'est toujours le cas, il va avoir quelqu'un d'influent qui va s'opposer bien fort.
Ce qui expliquerait l'énoncé « They are now only supported with the -E switch ».
En revanche, je vois toujours mal une telle application qui n'a pas été modifiée pour le préprocesseur standard. Avant la norme, il y avait bien deux standards de fait, incompatible. Maintenir du code préprocesseur pour qu'il marche avec les deux été assez pénible. Alors qu'aujourd'hui, où tous les préprocesseurs ont une mode ISO, ce n'est pas la peine.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet wrote:
"kanze" <kanze@gabi-soft.fr> writes:
De toute façon, la direction de l'évolution est claire, et
ça ne m'étonnerait pas de voir disparaître l'option dans une
version future.
Je crois que ce qui les bloque ce sont les utilisations
traditionnelles du preprocesseurs C dans des contextes hors du
langage C, imake par exemple; il me semble me souvenir
qu'emacs a utilise quelque chose du genre pour sa
configuration; si c'est toujours le cas, il va avoir quelqu'un
d'influent qui va s'opposer bien fort.
Ce qui expliquerait l'énoncé « They are now only supported with
the -E switch ».
En revanche, je vois toujours mal une telle application qui n'a
pas été modifiée pour le préprocesseur standard. Avant la norme,
il y avait bien deux standards de fait, incompatible. Maintenir
du code préprocesseur pour qu'il marche avec les deux été assez
pénible. Alors qu'aujourd'hui, où tous les préprocesseurs ont
une mode ISO, ce n'est pas la peine.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
De toute façon, la direction de l'évolution est claire, et ça ne m'étonnerait pas de voir disparaître l'option dans une version future.
Je crois que ce qui les bloque ce sont les utilisations traditionnelles du preprocesseurs C dans des contextes hors du langage C, imake par exemple; il me semble me souvenir qu'emacs a utilise quelque chose du genre pour sa configuration; si c'est toujours le cas, il va avoir quelqu'un d'influent qui va s'opposer bien fort.
Ce qui expliquerait l'énoncé « They are now only supported with the -E switch ».
En revanche, je vois toujours mal une telle application qui n'a pas été modifiée pour le préprocesseur standard. Avant la norme, il y avait bien deux standards de fait, incompatible. Maintenir du code préprocesseur pour qu'il marche avec les deux été assez pénible. Alors qu'aujourd'hui, où tous les préprocesseurs ont une mode ISO, ce n'est pas la peine.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
espie
In article , kanze wrote:
Dans la pratique, fort peu de compilateurs ont profité de cette possibilité, et la quasi-totalité des préprocesseurs travaillent toujours avec les chaînes de caractères directement, et maintiennent les tokens en tant que chaîne, ne les évaluant qu'après toute expansion du macro. Du coup, ## revient à un opérateur de concatenation de chaîne, et ton exemple ne pose pas de problème. Dans le cas de g++, je ne sais pas si c'est l'exception, et qu'il travaille internalement en token, ou si simplement ils ont ajouté un test explicit pour donner une erreur à cause du comportement indéfini.
gcc est l'exception, effectivement. Ils ont entierement reecrit le preprocesseur depuis une version 3.x (je ne sais plus la valeur de x).
Ce dernier gere effectivement des tokens en interne, et collabore tres etroitement avec le compilateur lui-meme (en fait, par defaut, ce n'est pas un programme separe), ce qui leur permet diverses choses. A priori, d'etre plus efficace (ce qui n'est pas du luxe vu la vitesse d'escargot des autres passes), mais egalement de pondre des messages d'erreurs plus precis et intelligents (vu qu'il annote les choses correctement pour pouvoir montrer la vraie ligne de source avec une position au caractere pres). Allie avec les travaux de Gaby sur les rapports d'erreurs de template, le resultat est un nettement plus grand confort d'utilisation.
A l'arrivee, par contre, ca a force a corriger les myriades de code qui utilisaient ## pour concatener des tokens distincts (et dieux sait qu'il y en avait) et ca a legerement plombe quelques utilisations du preprocesseur pour d'autre chose que du C/C++...
In article <1151568376.426742.323560@b68g2000cwa.googlegroups.com>,
kanze <kanze@gabi-soft.fr> wrote:
Dans la pratique, fort peu de compilateurs ont profité de cette
possibilité, et la quasi-totalité des préprocesseurs travaillent
toujours avec les chaînes de caractères directement, et
maintiennent les tokens en tant que chaîne, ne les évaluant
qu'après toute expansion du macro. Du coup, ## revient à un
opérateur de concatenation de chaîne, et ton exemple ne pose pas
de problème. Dans le cas de g++, je ne sais pas si c'est
l'exception, et qu'il travaille internalement en token, ou si
simplement ils ont ajouté un test explicit pour donner une
erreur à cause du comportement indéfini.
gcc est l'exception, effectivement. Ils ont entierement reecrit le
preprocesseur depuis une version 3.x (je ne sais plus la valeur de x).
Ce dernier gere effectivement des tokens en interne, et collabore tres
etroitement avec le compilateur lui-meme (en fait, par defaut, ce n'est
pas un programme separe), ce qui leur permet diverses choses.
A priori, d'etre plus efficace (ce qui n'est pas du luxe vu la vitesse
d'escargot des autres passes), mais egalement de pondre des messages
d'erreurs plus precis et intelligents (vu qu'il annote les choses correctement
pour pouvoir montrer la vraie ligne de source avec une position au
caractere pres). Allie avec les travaux de Gaby sur les rapports d'erreurs
de template, le resultat est un nettement plus grand confort d'utilisation.
A l'arrivee, par contre, ca a force a corriger les myriades de code qui
utilisaient ## pour concatener des tokens distincts (et dieux sait qu'il
y en avait) et ca a legerement plombe quelques utilisations du preprocesseur
pour d'autre chose que du C/C++...
Dans la pratique, fort peu de compilateurs ont profité de cette possibilité, et la quasi-totalité des préprocesseurs travaillent toujours avec les chaînes de caractères directement, et maintiennent les tokens en tant que chaîne, ne les évaluant qu'après toute expansion du macro. Du coup, ## revient à un opérateur de concatenation de chaîne, et ton exemple ne pose pas de problème. Dans le cas de g++, je ne sais pas si c'est l'exception, et qu'il travaille internalement en token, ou si simplement ils ont ajouté un test explicit pour donner une erreur à cause du comportement indéfini.
gcc est l'exception, effectivement. Ils ont entierement reecrit le preprocesseur depuis une version 3.x (je ne sais plus la valeur de x).
Ce dernier gere effectivement des tokens en interne, et collabore tres etroitement avec le compilateur lui-meme (en fait, par defaut, ce n'est pas un programme separe), ce qui leur permet diverses choses. A priori, d'etre plus efficace (ce qui n'est pas du luxe vu la vitesse d'escargot des autres passes), mais egalement de pondre des messages d'erreurs plus precis et intelligents (vu qu'il annote les choses correctement pour pouvoir montrer la vraie ligne de source avec une position au caractere pres). Allie avec les travaux de Gaby sur les rapports d'erreurs de template, le resultat est un nettement plus grand confort d'utilisation.
A l'arrivee, par contre, ca a force a corriger les myriades de code qui utilisaient ## pour concatener des tokens distincts (et dieux sait qu'il y en avait) et ca a legerement plombe quelques utilisations du preprocesseur pour d'autre chose que du C/C++...
