Dans un thread d'octobre, il y a eu une discussion sur l'implémentation
de la recherche en deux phases. Est-ce que c'est le fait que le
compilateur doit faire deux passes pour analyser le code, parce que C++
n'est pas toujours LALR(1), ou est-ce autre chose ?
Curieusement,
Nowhere man
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A
Le Mon, 16 May 2005 16:42:33 +0200, Gabriel Dos Reis a écrit :
mais GCC-3.x avec x < 4 n'est pas documenté implémenter la recherche de noms en deux phases (quite the contrary). Essaie GCC-3.4.x ou GCC-4.0.x
C'est très étrange, ça compile et fonctionne avec GCC 3.3.5, mais ça ne compile pas avec 3.4.3. Je n'ai plus 4.0 pour le moment.
Étrangement, Nowhere man --
OpenPGP 0xD9D50D8A
Gabriel Dos Reis
Pierre THIERRY writes:
| Le Mon, 16 May 2005 16:42:33 +0200, Gabriel Dos Reis a écrit : | > mais GCC-3.x avec x < 4 n'est pas documenté implémenter la recherche | > de noms en deux phases (quite the contrary). Essaie GCC-3.4.x ou | > GCC-4.0.x | | C'est très étrange, ça compile et fonctionne avec GCC 3.3.5, mais ça ne | compile pas avec 3.4.3. Je n'ai plus 4.0 pour le moment.
Qu'est-ce qui est étrange ?
-- Gaby
Pierre THIERRY <nowhere.man@levallois.eu.org> writes:
| Le Mon, 16 May 2005 16:42:33 +0200, Gabriel Dos Reis a écrit :
| > mais GCC-3.x avec x < 4 n'est pas documenté implémenter la recherche
| > de noms en deux phases (quite the contrary). Essaie GCC-3.4.x ou
| > GCC-4.0.x
|
| C'est très étrange, ça compile et fonctionne avec GCC 3.3.5, mais ça ne
| compile pas avec 3.4.3. Je n'ai plus 4.0 pour le moment.
| Le Mon, 16 May 2005 16:42:33 +0200, Gabriel Dos Reis a écrit : | > mais GCC-3.x avec x < 4 n'est pas documenté implémenter la recherche | > de noms en deux phases (quite the contrary). Essaie GCC-3.4.x ou | > GCC-4.0.x | | C'est très étrange, ça compile et fonctionne avec GCC 3.3.5, mais ça ne | compile pas avec 3.4.3. Je n'ai plus 4.0 pour le moment.
Qu'est-ce qui est étrange ?
-- Gaby
Pierre THIERRY
Le Mon, 16 May 2005 19:10:42 +0200, Gabriel Dos Reis a écrit :
C'est très étrange, ça compile et fonctionne avec GCC 3.3.5, mais ça ne compile pas avec 3.4.3. Je n'ai plus 4.0 pour le moment. Qu'est-ce qui est étrange ?
Ben qu'une version compile le code convenablement et pas la suivante. Y'a régression, quoi...
Étonnamment, Nowhere man --
OpenPGP 0xD9D50D8A
Le Mon, 16 May 2005 19:10:42 +0200, Gabriel Dos Reis a écrit :
C'est très étrange, ça compile et fonctionne avec GCC 3.3.5, mais ça
ne compile pas avec 3.4.3. Je n'ai plus 4.0 pour le moment.
Qu'est-ce qui est étrange ?
Ben qu'une version compile le code convenablement et pas la suivante.
Y'a régression, quoi...
Étonnamment,
Nowhere man
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A
Le Mon, 16 May 2005 19:10:42 +0200, Gabriel Dos Reis a écrit :
C'est très étrange, ça compile et fonctionne avec GCC 3.3.5, mais ça ne compile pas avec 3.4.3. Je n'ai plus 4.0 pour le moment. Qu'est-ce qui est étrange ?
Ben qu'une version compile le code convenablement et pas la suivante. Y'a régression, quoi...
Étonnamment, Nowhere man --
OpenPGP 0xD9D50D8A
Matthieu Moy
Pierre THIERRY writes:
Ben qu'une version compile le code convenablement et pas la suivante. Y'a régression, quoi...
Relis bien le thread.
Ce n'est pas une regression, c'est une progression ... vers le standard. GCC 3.3 accepte du code incorrect, c'est un bug, et il est corrigé dans la 3.4, parce qu'il utilise la recherche en deux phases.
-- Matthieu
Pierre THIERRY <nowhere.man@levallois.eu.org> writes:
Ben qu'une version compile le code convenablement et pas la suivante.
Y'a régression, quoi...
Relis bien le thread.
Ce n'est pas une regression, c'est une progression ... vers le
standard. GCC 3.3 accepte du code incorrect, c'est un bug, et il est
corrigé dans la 3.4, parce qu'il utilise la recherche en deux phases.
Ben qu'une version compile le code convenablement et pas la suivante. Y'a régression, quoi...
Relis bien le thread.
Ce n'est pas une regression, c'est une progression ... vers le standard. GCC 3.3 accepte du code incorrect, c'est un bug, et il est corrigé dans la 3.4, parce qu'il utilise la recherche en deux phases.
-- Matthieu
kanze
Matthieu Moy wrote:
Pierre THIERRY writes:
Ben qu'une version compile le code convenablement et pas la suivante. Y'a régression, quoi...
Relis bien le thread.
Ce n'est pas une regression, c'est une progression ... vers le standard. GCC 3.3 accepte du code incorrect, c'est un bug, et il est corrigé dans la 3.4, parce qu'il utilise la recherche en deux phases.
Attention : ce n'était pas un boggue avant. C'était simplement que le compilateur était plus ancien, et que le langage a changé. (Encore que... l'histoire de la recherche en deux phases est assez complexe, et je me pose toujours la question pourquoi tant d'implémentations l'ont ignoré pendant si longtemps.)
Normalement, on s'attendrait à du support pour la migration. G++ a créé le modèle de comment faire pour ce genre de problème avec leur traitement du changement de la portée des variables dans une boucle for ; d'après ce modèle, je m'attendrais à simplement un avertissement, et l'application des anciennes règles. Mais j'imagine que supporter deux règles de recherche de nom, c'est autrement complexe à implémenter que de supporter deux portées différentes pour une variable définie dans un for.
-- 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
Matthieu Moy wrote:
Pierre THIERRY <nowhere.man@levallois.eu.org> writes:
Ben qu'une version compile le code convenablement et pas la
suivante. Y'a régression, quoi...
Relis bien le thread.
Ce n'est pas une regression, c'est une progression ... vers le
standard. GCC 3.3 accepte du code incorrect, c'est un bug, et
il est corrigé dans la 3.4, parce qu'il utilise la recherche
en deux phases.
Attention : ce n'était pas un boggue avant. C'était simplement
que le compilateur était plus ancien, et que le langage a
changé. (Encore que... l'histoire de la recherche en deux phases
est assez complexe, et je me pose toujours la question pourquoi
tant d'implémentations l'ont ignoré pendant si longtemps.)
Normalement, on s'attendrait à du support pour la migration. G++
a créé le modèle de comment faire pour ce genre de problème avec
leur traitement du changement de la portée des variables dans
une boucle for ; d'après ce modèle, je m'attendrais à simplement
un avertissement, et l'application des anciennes règles. Mais
j'imagine que supporter deux règles de recherche de nom, c'est
autrement complexe à implémenter que de supporter deux portées
différentes pour une variable définie dans un for.
--
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
Ben qu'une version compile le code convenablement et pas la suivante. Y'a régression, quoi...
Relis bien le thread.
Ce n'est pas une regression, c'est une progression ... vers le standard. GCC 3.3 accepte du code incorrect, c'est un bug, et il est corrigé dans la 3.4, parce qu'il utilise la recherche en deux phases.
Attention : ce n'était pas un boggue avant. C'était simplement que le compilateur était plus ancien, et que le langage a changé. (Encore que... l'histoire de la recherche en deux phases est assez complexe, et je me pose toujours la question pourquoi tant d'implémentations l'ont ignoré pendant si longtemps.)
Normalement, on s'attendrait à du support pour la migration. G++ a créé le modèle de comment faire pour ce genre de problème avec leur traitement du changement de la portée des variables dans une boucle for ; d'après ce modèle, je m'attendrais à simplement un avertissement, et l'application des anciennes règles. Mais j'imagine que supporter deux règles de recherche de nom, c'est autrement complexe à implémenter que de supporter deux portées différentes pour une variable définie dans un for.
-- 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
Gabriel Dos Reis
writes:
| Matthieu Moy wrote: | > Pierre THIERRY writes: | | > > Ben qu'une version compile le code convenablement et pas la | > > suivante. Y'a régression, quoi... | | > Relis bien le thread. | | > Ce n'est pas une regression, c'est une progression ... vers le | > standard. GCC 3.3 accepte du code incorrect, c'est un bug, et | > il est corrigé dans la 3.4, parce qu'il utilise la recherche | > en deux phases. | | Attention : ce n'était pas un boggue avant. C'était simplement | que le compilateur était plus ancien, et que le langage a | changé. (Encore que... l'histoire de la recherche en deux phases | est assez complexe, et je me pose toujours la question pourquoi | tant d'implémentations l'ont ignoré pendant si longtemps.)
La règle est suffisamment ancienne pour que toutes les versions de GCC-3.x avec x < 4 soient qualifiées de bugguées. Mais c'était des bugs documentés :-)
| Normalement, on s'attendrait à du support pour la migration. G++ | a créé le modèle de comment faire pour ce genre de problème avec | leur traitement du changement de la portée des variables dans | une boucle for ; d'après ce modèle, je m'attendrais à simplement | un avertissement, et l'application des anciennes règles. Mais | j'imagine que supporter deux règles de recherche de nom, c'est | autrement complexe à implémenter que de supporter deux portées | différentes pour une variable définie dans un for.
Il y a eu beaucoup de discussion (et de volonté) pour faire les choses comme ceci :
(1) faire « l'ancienne » recherche et la recherche mandatée par la norme ; (2) si les résultats sont différents, affichier un warning, et continuer quand même avec la nouvelle recherche.
Mais, (a) il manquait de resource ; (b) GCC (notamment G++) est devenu lent (on peut longuement disserté dessus) et pas de gens était réticent à l'idée d'introduire quelque qui allait encore ralentir le compilateur, (c) il y avait quand même des cas d'ambiguités que l'on pourrait introduire.
À la fin, par manque de resource, un compromis a été implementé -- donner des erreurs avec suggestions dans des cas spécifiques.
-- Gaby
kanze@gabi-soft.fr writes:
| Matthieu Moy wrote:
| > Pierre THIERRY <nowhere.man@levallois.eu.org> writes:
|
| > > Ben qu'une version compile le code convenablement et pas la
| > > suivante. Y'a régression, quoi...
|
| > Relis bien le thread.
|
| > Ce n'est pas une regression, c'est une progression ... vers le
| > standard. GCC 3.3 accepte du code incorrect, c'est un bug, et
| > il est corrigé dans la 3.4, parce qu'il utilise la recherche
| > en deux phases.
|
| Attention : ce n'était pas un boggue avant. C'était simplement
| que le compilateur était plus ancien, et que le langage a
| changé. (Encore que... l'histoire de la recherche en deux phases
| est assez complexe, et je me pose toujours la question pourquoi
| tant d'implémentations l'ont ignoré pendant si longtemps.)
La règle est suffisamment ancienne pour que toutes les versions de
GCC-3.x avec x < 4 soient qualifiées de bugguées. Mais c'était des
bugs documentés :-)
| Normalement, on s'attendrait à du support pour la migration. G++
| a créé le modèle de comment faire pour ce genre de problème avec
| leur traitement du changement de la portée des variables dans
| une boucle for ; d'après ce modèle, je m'attendrais à simplement
| un avertissement, et l'application des anciennes règles. Mais
| j'imagine que supporter deux règles de recherche de nom, c'est
| autrement complexe à implémenter que de supporter deux portées
| différentes pour une variable définie dans un for.
Il y a eu beaucoup de discussion (et de volonté) pour faire les choses
comme ceci :
(1) faire « l'ancienne » recherche et la recherche mandatée par la
norme ;
(2) si les résultats sont différents, affichier un warning, et
continuer quand même avec la nouvelle recherche.
Mais,
(a) il manquait de resource ;
(b) GCC (notamment G++) est devenu lent (on peut longuement disserté
dessus) et pas de gens était réticent à l'idée d'introduire
quelque qui allait encore ralentir le compilateur,
(c) il y avait quand même des cas d'ambiguités que l'on pourrait
introduire.
À la fin, par manque de resource, un compromis a été implementé --
donner des erreurs avec suggestions dans des cas spécifiques.
| Matthieu Moy wrote: | > Pierre THIERRY writes: | | > > Ben qu'une version compile le code convenablement et pas la | > > suivante. Y'a régression, quoi... | | > Relis bien le thread. | | > Ce n'est pas une regression, c'est une progression ... vers le | > standard. GCC 3.3 accepte du code incorrect, c'est un bug, et | > il est corrigé dans la 3.4, parce qu'il utilise la recherche | > en deux phases. | | Attention : ce n'était pas un boggue avant. C'était simplement | que le compilateur était plus ancien, et que le langage a | changé. (Encore que... l'histoire de la recherche en deux phases | est assez complexe, et je me pose toujours la question pourquoi | tant d'implémentations l'ont ignoré pendant si longtemps.)
La règle est suffisamment ancienne pour que toutes les versions de GCC-3.x avec x < 4 soient qualifiées de bugguées. Mais c'était des bugs documentés :-)
| Normalement, on s'attendrait à du support pour la migration. G++ | a créé le modèle de comment faire pour ce genre de problème avec | leur traitement du changement de la portée des variables dans | une boucle for ; d'après ce modèle, je m'attendrais à simplement | un avertissement, et l'application des anciennes règles. Mais | j'imagine que supporter deux règles de recherche de nom, c'est | autrement complexe à implémenter que de supporter deux portées | différentes pour une variable définie dans un for.
Il y a eu beaucoup de discussion (et de volonté) pour faire les choses comme ceci :
(1) faire « l'ancienne » recherche et la recherche mandatée par la norme ; (2) si les résultats sont différents, affichier un warning, et continuer quand même avec la nouvelle recherche.
Mais, (a) il manquait de resource ; (b) GCC (notamment G++) est devenu lent (on peut longuement disserté dessus) et pas de gens était réticent à l'idée d'introduire quelque qui allait encore ralentir le compilateur, (c) il y avait quand même des cas d'ambiguités que l'on pourrait introduire.
À la fin, par manque de resource, un compromis a été implementé -- donner des erreurs avec suggestions dans des cas spécifiques.
