A la lecture des papiers sur les concepts, je constate que les noms de
concepts standard -- qui seront donc dans le namespace std --
commencent par une majuscule, chaque mot étant séparé par une
majscule. Par exemple std::CopyConstructible.
Je ne sais pas si c'est une tradition ou une règle absolue, mais
jusque là toute la bibliothèque standard est écrite avec la convention
de nommage C «classique» : std::un_composant_standard. Pourquoi en
serait-il autrement pour les concepts ? En tout cas l'entête
<concepts> de conceptgcc n'utilise pas la «convention classique».
J'ai l'impression qu'en C++, la mode consiste à faire débuter les noms
de classe/struct/union/[typedef] par une majuscule, aussi j'aurai eu
tendance à penser que l'usage des minuscules aurait moins cassé de
code ce genre, non ?
#include <concepts>
struct CopyConstructible;
typedef int Assignable;
using namespace std;
template <CopyConstructible T>
where Assignable<T>
void f( T t );
| Pour le front-end, disons que j'ai l'impression que les bugs de | middle-end, back-end sont bien plus redoutés.
La plupart des compilateurs C++ partagent le middle-end et back-end avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à ce niveau. À quoi pensais-tu en particulier ?
pour être pragmatique: on considère deux classes de bugs, les ice-on-valid et les wrong-code (désolé, j'anglicise pour être clair). Les premiers sont pénibles au possible, les seconds sont innacceptables; Du moins, c'est la façon dont je les perçois. La classe de bug et la partie du compilateur incriminée sont à priori orthogonales, mais je doute que cela résiste aux statistiques; et je pencherai pour: les ice-on-valid sont souvent de la responsabilité du front-end, les wrong-code sont souvent de la responsabilité du middle-end ou back-end.
Je crois que dans le cycle de développement de Gcc, les modifications importantes du middle-end sont fait en stage 1, tandis qu'il est possible de créer un front-end en stage 2.
| Depuis toutes ces | années, les tests de non régression sur le front-end C++98 doivent | être assez exhaustifs.
Ahem. D'expérience, je serais beaucoup plus circonspet.
D'inexpérience, je suis également circonspect (je feint) :-)
| Aussi, les bugs sur le nouveau front-end seront | peut-être pour la plupart contournable en se passant des nouveautés | C++0x.
Spéculation ou assertion basée sur des expériences passées ?
Spéculation basée sur de l'optimisme.
Si on prends l'exemple de l'introduction des concepts, qui impacte surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait voir par exemple comment se comporte conceptgcc, est-ce qu'il passe les tests de non régression axés front-end ? Si oui, est-ce que c'est un frein extraordinaire à son développement ?
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
[...]
| Pour le front-end, disons que j'ai l'impression que les bugs de
| middle-end, back-end sont bien plus redoutés.
La plupart des compilateurs C++ partagent le middle-end et back-end
avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à
ce niveau. À quoi pensais-tu en particulier ?
pour être pragmatique: on considère deux classes de bugs, les
ice-on-valid et les wrong-code (désolé, j'anglicise pour être clair).
Les premiers sont pénibles au possible, les seconds sont
innacceptables; Du moins, c'est la façon dont je les perçois. La
classe de bug et la partie du compilateur incriminée sont à priori
orthogonales, mais je doute que cela résiste aux statistiques; et je
pencherai pour: les ice-on-valid sont souvent de la responsabilité du
front-end, les wrong-code sont souvent de la responsabilité du
middle-end ou back-end.
Je crois que dans le cycle de développement de Gcc, les modifications
importantes du middle-end sont fait en stage 1, tandis qu'il est
possible de créer un front-end en stage 2.
| Depuis toutes ces
| années, les tests de non régression sur le front-end C++98 doivent
| être assez exhaustifs.
Ahem.
D'expérience, je serais beaucoup plus circonspet.
D'inexpérience, je suis également circonspect (je feint) :-)
| Aussi, les bugs sur le nouveau front-end seront
| peut-être pour la plupart contournable en se passant des nouveautés
| C++0x.
Spéculation ou assertion basée sur des expériences passées ?
Spéculation basée sur de l'optimisme.
Si on prends l'exemple de l'introduction des concepts, qui impacte
surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait
voir par exemple comment se comporte conceptgcc, est-ce qu'il passe
les tests de non régression axés front-end ? Si oui, est-ce que c'est
un frein extraordinaire à son développement ?
| Pour le front-end, disons que j'ai l'impression que les bugs de | middle-end, back-end sont bien plus redoutés.
La plupart des compilateurs C++ partagent le middle-end et back-end avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à ce niveau. À quoi pensais-tu en particulier ?
pour être pragmatique: on considère deux classes de bugs, les ice-on-valid et les wrong-code (désolé, j'anglicise pour être clair). Les premiers sont pénibles au possible, les seconds sont innacceptables; Du moins, c'est la façon dont je les perçois. La classe de bug et la partie du compilateur incriminée sont à priori orthogonales, mais je doute que cela résiste aux statistiques; et je pencherai pour: les ice-on-valid sont souvent de la responsabilité du front-end, les wrong-code sont souvent de la responsabilité du middle-end ou back-end.
Je crois que dans le cycle de développement de Gcc, les modifications importantes du middle-end sont fait en stage 1, tandis qu'il est possible de créer un front-end en stage 2.
| Depuis toutes ces | années, les tests de non régression sur le front-end C++98 doivent | être assez exhaustifs.
Ahem. D'expérience, je serais beaucoup plus circonspet.
D'inexpérience, je suis également circonspect (je feint) :-)
| Aussi, les bugs sur le nouveau front-end seront | peut-être pour la plupart contournable en se passant des nouveautés | C++0x.
Spéculation ou assertion basée sur des expériences passées ?
Spéculation basée sur de l'optimisme.
Si on prends l'exemple de l'introduction des concepts, qui impacte surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait voir par exemple comment se comporte conceptgcc, est-ce qu'il passe les tests de non régression axés front-end ? Si oui, est-ce que c'est un frein extraordinaire à son développement ?
-- Fab
fabien.chene
Jean-Marc Bourguet writes:
Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée.
D'expérience, ça peut être *très* pénible à débugger. Et encore plus à *faire* fixer, car quand c'est arrivé aucune des deux définitions n'était sous notre responsabilité et on arrive alors dans un problème politique avec deux "fournisseurs" qui considèrent qu'il n'y a pas de problème chez eux.
Ouch !
2) à un problème d'ordre d'initialisation statique entre différentes TU.
J'ai eu peu de problèmes avec cela, et la source du problème fut toujours facile à trouver.
J'ai des problèmes avec cela lors de la transformation de bibliothèque statique en bibliothèque dynamique. C'est à la limite de l'échec, core dump systématique.
La solution parfois un peu plus -- quand apparemment il y a des dépendances circulaires -- mais alors d'après mon expérience en Ada, un système de module n'aide pas: il faut de toute manière restructurer.
Je n'ai pas suffisament explorer le papier sur les modules pour être sur, mais il est indiqué que ça aide à éviter ces problèmes. Je ne sais pas si le système de module d'ADA est comparable à celui proposé ?
-- Fab
Jean-Marc Bourguet <jm@bourguet.org> writes:
Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en
C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée.
D'expérience, ça peut être *très* pénible à débugger. Et encore plus à
*faire* fixer, car quand c'est arrivé aucune des deux définitions n'était
sous notre responsabilité et on arrive alors dans un problème politique
avec deux "fournisseurs" qui considèrent qu'il n'y a pas de problème chez
eux.
Ouch !
2) à un problème d'ordre d'initialisation statique entre différentes
TU.
J'ai eu peu de problèmes avec cela, et la source du problème fut toujours
facile à trouver.
J'ai des problèmes avec cela lors de la transformation de bibliothèque
statique en bibliothèque dynamique. C'est à la limite de l'échec, core
dump systématique.
La solution parfois un peu plus -- quand apparemment il
y a des dépendances circulaires -- mais alors d'après mon expérience en
Ada, un système de module n'aide pas: il faut de toute manière
restructurer.
Je n'ai pas suffisament explorer le papier sur les modules pour être
sur, mais il est indiqué que ça aide à éviter ces problèmes. Je ne
sais pas si le système de module d'ADA est comparable à celui proposé ?
Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée.
D'expérience, ça peut être *très* pénible à débugger. Et encore plus à *faire* fixer, car quand c'est arrivé aucune des deux définitions n'était sous notre responsabilité et on arrive alors dans un problème politique avec deux "fournisseurs" qui considèrent qu'il n'y a pas de problème chez eux.
Ouch !
2) à un problème d'ordre d'initialisation statique entre différentes TU.
J'ai eu peu de problèmes avec cela, et la source du problème fut toujours facile à trouver.
J'ai des problèmes avec cela lors de la transformation de bibliothèque statique en bibliothèque dynamique. C'est à la limite de l'échec, core dump systématique.
La solution parfois un peu plus -- quand apparemment il y a des dépendances circulaires -- mais alors d'après mon expérience en Ada, un système de module n'aide pas: il faut de toute manière restructurer.
Je n'ai pas suffisament explorer le papier sur les modules pour être sur, mais il est indiqué que ça aide à éviter ces problèmes. Je ne sais pas si le système de module d'ADA est comparable à celui proposé ?
-- Fab
Gabriel Dos Reis
(Fabien Chêne) writes:
| Gabriel Dos Reis writes: | | [...] | > | Pour le front-end, disons que j'ai l'impression que les bugs de | > | middle-end, back-end sont bien plus redoutés. | > | > La plupart des compilateurs C++ partagent le middle-end et back-end | > avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à | > ce niveau. À quoi pensais-tu en particulier ? | | pour être pragmatique: on considère deux classes de bugs, les | ice-on-valid et les wrong-code (désolé, j'anglicise pour être clair).
Et les accept-invalid et ice-on-invalid? Je propose que tu te portes volontaire pour trier les bugs de GCC et tu me diras ce que les utilisateurs pensent de ta classification :-)
| Les premiers asont pénibles au possible, les seconds sont | innacceptables; Du moins, c'est la façon dont je les perçois. La | classe de bug et la partie du compilateur incriminée sont à priori | orthogonales,
je ne vois pas comment. J'ai vu passé beaucoup de bug reports des deux classes qui vont d'un composant à l'autre -- on pourrait arguer que le compilateur est mal foutu, mais si nous devons parler des compilateurs de la vraie vie, ils sont en général mal foutus :-)
| mais je doute que cela résiste aux statistiques; et je | pencherai pour: les ice-on-valid sont souvent de la responsabilité du | front-end, les wrong-code sont souvent de la responsabilité du | middle-end ou back-end.
"souvent" est un quantitatif peu quantitatif :-) Et même si la majorité des wrong-codes venaient du middle-end, tous les « wrong codes » ne sont pas égaux. Il y a des wrong-code que les gens ont décidé de vivre avec et d'autres qui provoquent des psychodrames.
| Je crois que dans le cycle de développement de Gcc, les modifications | importantes du middle-end sont fait en stage 1, tandis qu'il est | possible de créer un front-end en stage 2.
Pouf, ils sont faits quand les gens le veulent. J'ai vu même des changements en stage 3, ou branch release.
Je sais s'il y a n théorème général à prouver sur les bugs ici.
| > | Depuis toutes ces | > | années, les tests de non régression sur le front-end C++98 doivent | > | être assez exhaustifs. | > | > Ahem. | > D'expérience, je serais beaucoup plus circonspet. | | D'inexpérience, je suis également circonspect (je feint) :-) | | > | Aussi, les bugs sur le nouveau front-end seront | > | peut-être pour la plupart contournable en se passant des nouveautés | > | C++0x. | > | > Spéculation ou assertion basée sur des expériences passées ? | | Spéculation basée sur de l'optimisme. | | Si on prends l'exemple de l'introduction des concepts, qui impacte | surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait | voir par exemple comment se comporte conceptgcc, est-ce qu'il passe | les tests de non régression axés front-end ?
Je ne sais pas ; il faudrait demander aux auteurs.
Je sais que ma propre implémentation expérimentale (complètement différente) et incomplète a quelques accept-invalid.
| Si oui, est-ce que c'est | un frein extraordinaire à son développement ?
Tout dépend de ce que tu attends de la qualité du compilateur. Pour faire de la recherche, cela n'est pas bien grave. Pour la production, je me retriendrais de faire de la spéculation (je me suis déjà brûlé plusieurs fois en tant que GCC RM.)
-- Gaby
fabien.chene@gmail.com (Fabien Chêne) writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| [...]
| > | Pour le front-end, disons que j'ai l'impression que les bugs de
| > | middle-end, back-end sont bien plus redoutés.
| >
| > La plupart des compilateurs C++ partagent le middle-end et back-end
| > avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à
| > ce niveau. À quoi pensais-tu en particulier ?
|
| pour être pragmatique: on considère deux classes de bugs, les
| ice-on-valid et les wrong-code (désolé, j'anglicise pour être clair).
Et les accept-invalid et ice-on-invalid? Je propose que tu te portes
volontaire pour trier les bugs de GCC et tu me diras ce que les
utilisateurs pensent de ta classification :-)
| Les premiers asont pénibles au possible, les seconds sont
| innacceptables; Du moins, c'est la façon dont je les perçois. La
| classe de bug et la partie du compilateur incriminée sont à priori
| orthogonales,
je ne vois pas comment. J'ai vu passé beaucoup de bug reports des deux
classes qui vont d'un composant à l'autre -- on pourrait arguer que le
compilateur est mal foutu, mais si nous devons parler des compilateurs
de la vraie vie, ils sont en général mal foutus :-)
| mais je doute que cela résiste aux statistiques; et je
| pencherai pour: les ice-on-valid sont souvent de la responsabilité du
| front-end, les wrong-code sont souvent de la responsabilité du
| middle-end ou back-end.
"souvent" est un quantitatif peu quantitatif :-)
Et même si la majorité des wrong-codes venaient du middle-end, tous
les « wrong codes » ne sont pas égaux. Il y a des wrong-code que les
gens ont décidé de vivre avec et d'autres qui provoquent des
psychodrames.
| Je crois que dans le cycle de développement de Gcc, les modifications
| importantes du middle-end sont fait en stage 1, tandis qu'il est
| possible de créer un front-end en stage 2.
Pouf, ils sont faits quand les gens le veulent. J'ai vu même des
changements en stage 3, ou branch release.
Je sais s'il y a n théorème général à prouver sur les bugs ici.
| > | Depuis toutes ces
| > | années, les tests de non régression sur le front-end C++98 doivent
| > | être assez exhaustifs.
| >
| > Ahem.
| > D'expérience, je serais beaucoup plus circonspet.
|
| D'inexpérience, je suis également circonspect (je feint) :-)
|
| > | Aussi, les bugs sur le nouveau front-end seront
| > | peut-être pour la plupart contournable en se passant des nouveautés
| > | C++0x.
| >
| > Spéculation ou assertion basée sur des expériences passées ?
|
| Spéculation basée sur de l'optimisme.
|
| Si on prends l'exemple de l'introduction des concepts, qui impacte
| surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait
| voir par exemple comment se comporte conceptgcc, est-ce qu'il passe
| les tests de non régression axés front-end ?
Je ne sais pas ; il faudrait demander aux auteurs.
Je sais que ma propre implémentation expérimentale (complètement
différente) et incomplète a quelques accept-invalid.
| Si oui, est-ce que c'est
| un frein extraordinaire à son développement ?
Tout dépend de ce que tu attends de la qualité du compilateur.
Pour faire de la recherche, cela n'est pas bien grave. Pour la
production, je me retriendrais de faire de la spéculation (je me
suis déjà brûlé plusieurs fois en tant que GCC RM.)
| Gabriel Dos Reis writes: | | [...] | > | Pour le front-end, disons que j'ai l'impression que les bugs de | > | middle-end, back-end sont bien plus redoutés. | > | > La plupart des compilateurs C++ partagent le middle-end et back-end | > avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à | > ce niveau. À quoi pensais-tu en particulier ? | | pour être pragmatique: on considère deux classes de bugs, les | ice-on-valid et les wrong-code (désolé, j'anglicise pour être clair).
Et les accept-invalid et ice-on-invalid? Je propose que tu te portes volontaire pour trier les bugs de GCC et tu me diras ce que les utilisateurs pensent de ta classification :-)
| Les premiers asont pénibles au possible, les seconds sont | innacceptables; Du moins, c'est la façon dont je les perçois. La | classe de bug et la partie du compilateur incriminée sont à priori | orthogonales,
je ne vois pas comment. J'ai vu passé beaucoup de bug reports des deux classes qui vont d'un composant à l'autre -- on pourrait arguer que le compilateur est mal foutu, mais si nous devons parler des compilateurs de la vraie vie, ils sont en général mal foutus :-)
| mais je doute que cela résiste aux statistiques; et je | pencherai pour: les ice-on-valid sont souvent de la responsabilité du | front-end, les wrong-code sont souvent de la responsabilité du | middle-end ou back-end.
"souvent" est un quantitatif peu quantitatif :-) Et même si la majorité des wrong-codes venaient du middle-end, tous les « wrong codes » ne sont pas égaux. Il y a des wrong-code que les gens ont décidé de vivre avec et d'autres qui provoquent des psychodrames.
| Je crois que dans le cycle de développement de Gcc, les modifications | importantes du middle-end sont fait en stage 1, tandis qu'il est | possible de créer un front-end en stage 2.
Pouf, ils sont faits quand les gens le veulent. J'ai vu même des changements en stage 3, ou branch release.
Je sais s'il y a n théorème général à prouver sur les bugs ici.
| > | Depuis toutes ces | > | années, les tests de non régression sur le front-end C++98 doivent | > | être assez exhaustifs. | > | > Ahem. | > D'expérience, je serais beaucoup plus circonspet. | | D'inexpérience, je suis également circonspect (je feint) :-) | | > | Aussi, les bugs sur le nouveau front-end seront | > | peut-être pour la plupart contournable en se passant des nouveautés | > | C++0x. | > | > Spéculation ou assertion basée sur des expériences passées ? | | Spéculation basée sur de l'optimisme. | | Si on prends l'exemple de l'introduction des concepts, qui impacte | surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait | voir par exemple comment se comporte conceptgcc, est-ce qu'il passe | les tests de non régression axés front-end ?
Je ne sais pas ; il faudrait demander aux auteurs.
Je sais que ma propre implémentation expérimentale (complètement différente) et incomplète a quelques accept-invalid.
| Si oui, est-ce que c'est | un frein extraordinaire à son développement ?
Tout dépend de ce que tu attends de la qualité du compilateur. Pour faire de la recherche, cela n'est pas bien grave. Pour la production, je me retriendrais de faire de la spéculation (je me suis déjà brûlé plusieurs fois en tant que GCC RM.)
-- Gaby
Arnaud Debaene
"Fabien Chêne" a écrit dans le message de news:
Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
Et le Koenigs Lookup? Et la résolution de noms dépendants?
Arnaud
"Fabien Chêne" <fabien.chene@gmail.com> a écrit dans le message de news:
87fydeitnn.fsf@gmail.com...
Je me posais la question justement, les compilateurs ne vont-ils pas
fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a
été standardisé, avait déjà été implémenté, non ? -- export excepté ...
Et le Koenigs Lookup? Et la résolution de noms dépendants?
Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
Et le Koenigs Lookup? Et la résolution de noms dépendants?
Arnaud
Jean-Marc Bourguet
(Fabien Chêne) writes:
Jean-Marc Bourguet writes:
Je n'ai pas suffisament explorer le papier sur les modules pour être sur, mais il est indiqué que ça aide à éviter ces problèmes. Je ne sais pas si le système de module d'ADA est comparable à celui proposé ?
Le système de module est fort différent et pas facilement comparable. En ce qui concerne l'équivalent de l'initialisation des statiques, la situation est plus compliquée pour au moins trois raisons: Ada offre un contrôle plus fin et permet une vérification à l'exécution d'une part, Ada sépare l'interface de l'implémentation d'autre part, il y a une hiérarchie de modules enfin. Mais il y a moyen d'avoir la même chose que ce que propose David: un graphe acyclique de dépendance et l'intialisation dans un ordre qui résulte d'un tri topologique et c'est ce que j'utilisais quasiment systématiquement -- sauf quand la souplesse supplémentaire me permettait d'éviter des restructurations nécessaire uniquement pour des raisons d'initialisation statique.
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
fabien.chene@gmail.com (Fabien Chêne) writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
Je n'ai pas suffisament explorer le papier sur les modules pour être
sur, mais il est indiqué que ça aide à éviter ces problèmes. Je ne
sais pas si le système de module d'ADA est comparable à celui proposé ?
Le système de module est fort différent et pas facilement comparable. En
ce qui concerne l'équivalent de l'initialisation des statiques, la
situation est plus compliquée pour au moins trois raisons: Ada offre un
contrôle plus fin et permet une vérification à l'exécution d'une part, Ada
sépare l'interface de l'implémentation d'autre part, il y a une hiérarchie
de modules enfin. Mais il y a moyen d'avoir la même chose que ce que
propose David: un graphe acyclique de dépendance et l'intialisation dans un
ordre qui résulte d'un tri topologique et c'est ce que j'utilisais
quasiment systématiquement -- sauf quand la souplesse supplémentaire me
permettait d'éviter des restructurations nécessaire uniquement pour des
raisons d'initialisation statique.
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
Je n'ai pas suffisament explorer le papier sur les modules pour être sur, mais il est indiqué que ça aide à éviter ces problèmes. Je ne sais pas si le système de module d'ADA est comparable à celui proposé ?
Le système de module est fort différent et pas facilement comparable. En ce qui concerne l'équivalent de l'initialisation des statiques, la situation est plus compliquée pour au moins trois raisons: Ada offre un contrôle plus fin et permet une vérification à l'exécution d'une part, Ada sépare l'interface de l'implémentation d'autre part, il y a une hiérarchie de modules enfin. Mais il y a moyen d'avoir la même chose que ce que propose David: un graphe acyclique de dépendance et l'intialisation dans un ordre qui résulte d'un tri topologique et c'est ce que j'utilisais quasiment systématiquement -- sauf quand la souplesse supplémentaire me permettait d'éviter des restructurations nécessaire uniquement pour des raisons d'initialisation statique.
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
Jean-Marc Bourguet
"James Kanze" writes:
C'est quoi, ice ?
Internal Compiler Error
J'ai toujours cru qu'il y avait quatres types d'erreurs : -- des erreurs internes du compilateur : un core dump, ou qu'il détecte une situation impossible et avorte, Voilà, ils classifient un peu plus loin suivant que le code causant
l'erreur devrait être admis ou pas.
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
"James Kanze" <james.kanze@gmail.com> writes:
C'est quoi, ice ?
Internal Compiler Error
J'ai toujours cru qu'il y avait quatres types d'erreurs :
-- des erreurs internes du compilateur : un core dump, ou
qu'il détecte une situation impossible et avorte,
Voilà, ils classifient un peu plus loin suivant que le code causant
l'erreur devrait être admis ou pas.
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
J'ai toujours cru qu'il y avait quatres types d'erreurs : -- des erreurs internes du compilateur : un core dump, ou qu'il détecte une situation impossible et avorte, Voilà, ils classifient un peu plus loin suivant que le code causant
l'erreur devrait être admis ou pas.
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
Fabien Chêne
[...]
| pour être pragmatique: on considère deux classes de bugs, les | ice-on-valid et les wrong-code (désolé, j'anglicise pour être c lair).
Et les accept-invalid et ice-on-invalid?
C'est quoi, ice ?
Internal Compiler Error.
J'ai toujours cru qu'il y avait quatres types d'erreurs : -- des erreurs internes du compilateur : un core dump, ou qu'il détecte une situation impossible et avorte,
selon la terminologie Gcc, tu regroupes là ice-on-valid et ice-on-invalid.
-- qu'il accepte du code qui exige une diagnostique, ou des cas de comportement indéfini qu'on a voulu diagnostiquer,
accept-invalid
-- qu'il rejette du code valide, ou
reject-valid
-- qu'il génère du mauvais code.
wrong-code
-- Fab
[...]
| pour être pragmatique: on considère deux classes de bugs, les
| ice-on-valid et les wrong-code (désolé, j'anglicise pour être c lair).
Et les accept-invalid et ice-on-invalid?
C'est quoi, ice ?
Internal Compiler Error.
J'ai toujours cru qu'il y avait quatres types d'erreurs :
-- des erreurs internes du compilateur : un core dump, ou
qu'il détecte une situation impossible et avorte,
selon la terminologie Gcc, tu regroupes là ice-on-valid et
ice-on-invalid.
-- qu'il accepte du code qui exige une diagnostique, ou des cas
de comportement indéfini qu'on a voulu diagnostiquer,
| pour être pragmatique: on considère deux classes de bugs, les | ice-on-valid et les wrong-code (désolé, j'anglicise pour être c lair).
Et les accept-invalid et ice-on-invalid?
C'est quoi, ice ?
Internal Compiler Error.
J'ai toujours cru qu'il y avait quatres types d'erreurs : -- des erreurs internes du compilateur : un core dump, ou qu'il détecte une situation impossible et avorte,
selon la terminologie Gcc, tu regroupes là ice-on-valid et ice-on-invalid.
-- qu'il accepte du code qui exige une diagnostique, ou des cas de comportement indéfini qu'on a voulu diagnostiquer,
accept-invalid
-- qu'il rejette du code valide, ou
reject-valid
-- qu'il génère du mauvais code.
wrong-code
-- Fab
fabien.chene
Gabriel Dos Reis writes:
(avec un peu de retard) [...]
Je sais s'il y a n théorème général à prouver sur les bugs ici.
| > | Depuis toutes ces | > | années, les tests de non régression sur le front-end C++98 doivent | > | être assez exhaustifs. | > | > Ahem. | > D'expérience, je serais beaucoup plus circonspet. | | D'inexpérience, je suis également circonspect (je feint) :-) | | > | Aussi, les bugs sur le nouveau front-end seront | > | peut-être pour la plupart contournable en se passant des nouveautés | > | C++0x. | > | > Spéculation ou assertion basée sur des expériences passées ? | | Spéculation basée sur de l'optimisme. | | Si on prends l'exemple de l'introduction des concepts, qui impacte | surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait | voir par exemple comment se comporte conceptgcc, est-ce qu'il passe | les tests de non régression axés front-end ?
Je ne sais pas ; il faudrait demander aux auteurs.
make check-g++ passe, mais je ne suis pas sur de bien m'y prendre :-)
Je sais que ma propre implémentation expérimentale (complètement différente) [snip]
En s'y prenant complètement différemment, peut-on arriver à ne pas trop embourber le parseur, et avoir un temps de compilation acceptable ?
| Si oui, est-ce que c'est | un frein extraordinaire à son développement ?
Tout dépend de ce que tu attends de la qualité du compilateur. Pour faire de la recherche, cela n'est pas bien grave. Pour la production, je me retriendrais de faire de la spéculation (je me suis déjà brûlé plusieurs fois en tant que GCC RM.)
Je comprends alors ta position.
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
(avec un peu de retard)
[...]
Je sais s'il y a n théorème général à prouver sur les bugs ici.
| > | Depuis toutes ces
| > | années, les tests de non régression sur le front-end C++98 doivent
| > | être assez exhaustifs.
| >
| > Ahem.
| > D'expérience, je serais beaucoup plus circonspet.
|
| D'inexpérience, je suis également circonspect (je feint) :-)
|
| > | Aussi, les bugs sur le nouveau front-end seront
| > | peut-être pour la plupart contournable en se passant des nouveautés
| > | C++0x.
| >
| > Spéculation ou assertion basée sur des expériences passées ?
|
| Spéculation basée sur de l'optimisme.
|
| Si on prends l'exemple de l'introduction des concepts, qui impacte
| surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait
| voir par exemple comment se comporte conceptgcc, est-ce qu'il passe
| les tests de non régression axés front-end ?
Je ne sais pas ; il faudrait demander aux auteurs.
make check-g++ passe, mais je ne suis pas sur de bien m'y prendre :-)
Je sais que ma propre implémentation expérimentale (complètement
différente) [snip]
En s'y prenant complètement différemment, peut-on arriver à ne pas
trop embourber le parseur, et avoir un temps de compilation
acceptable ?
| Si oui, est-ce que c'est
| un frein extraordinaire à son développement ?
Tout dépend de ce que tu attends de la qualité du compilateur.
Pour faire de la recherche, cela n'est pas bien grave. Pour la
production, je me retriendrais de faire de la spéculation (je me
suis déjà brûlé plusieurs fois en tant que GCC RM.)
Je sais s'il y a n théorème général à prouver sur les bugs ici.
| > | Depuis toutes ces | > | années, les tests de non régression sur le front-end C++98 doivent | > | être assez exhaustifs. | > | > Ahem. | > D'expérience, je serais beaucoup plus circonspet. | | D'inexpérience, je suis également circonspect (je feint) :-) | | > | Aussi, les bugs sur le nouveau front-end seront | > | peut-être pour la plupart contournable en se passant des nouveautés | > | C++0x. | > | > Spéculation ou assertion basée sur des expériences passées ? | | Spéculation basée sur de l'optimisme. | | Si on prends l'exemple de l'introduction des concepts, qui impacte | surtout le front-end -- tu me corrigeras si je me trompe. Il faudrait | voir par exemple comment se comporte conceptgcc, est-ce qu'il passe | les tests de non régression axés front-end ?
Je ne sais pas ; il faudrait demander aux auteurs.
make check-g++ passe, mais je ne suis pas sur de bien m'y prendre :-)
Je sais que ma propre implémentation expérimentale (complètement différente) [snip]
En s'y prenant complètement différemment, peut-on arriver à ne pas trop embourber le parseur, et avoir un temps de compilation acceptable ?
| Si oui, est-ce que c'est | un frein extraordinaire à son développement ?
Tout dépend de ce que tu attends de la qualité du compilateur. Pour faire de la recherche, cela n'est pas bien grave. Pour la production, je me retriendrais de faire de la spéculation (je me suis déjà brûlé plusieurs fois en tant que GCC RM.)
Je comprends alors ta position.
-- Fab
Gabriel Dos Reis
(Fabien Chêne) writes:
[...]
| > Je sais que ma propre implémentation expérimentale (complètement | > différente) [snip] | | En s'y prenant complètement différemment, peut-on arriver à ne pas | trop embourber le parseur, et avoir un temps de compilation | acceptable ?
Je ne sais pas. Mais, en spéculant, il faut bien voir que si la pratique actuelle de mettre tout le code dans les entêtes ne changent pas, je ne vois pas de raison d'espérer un temps de compilation peu prohibitive : avec les concepts, le compilateur doit systématiquement vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
-- Gaby
fabien.chene@gmail.com (Fabien Chêne) writes:
[...]
| > Je sais que ma propre implémentation expérimentale (complètement
| > différente) [snip]
|
| En s'y prenant complètement différemment, peut-on arriver à ne pas
| trop embourber le parseur, et avoir un temps de compilation
| acceptable ?
Je ne sais pas. Mais, en spéculant, il faut bien voir que si la
pratique actuelle de mettre tout le code dans les entêtes ne changent
pas, je ne vois pas de raison d'espérer un temps de compilation peu
prohibitive : avec les concepts, le compilateur doit systématiquement
vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
| > Je sais que ma propre implémentation expérimentale (complètement | > différente) [snip] | | En s'y prenant complètement différemment, peut-on arriver à ne pas | trop embourber le parseur, et avoir un temps de compilation | acceptable ?
Je ne sais pas. Mais, en spéculant, il faut bien voir que si la pratique actuelle de mettre tout le code dans les entêtes ne changent pas, je ne vois pas de raison d'espérer un temps de compilation peu prohibitive : avec les concepts, le compilateur doit systématiquement vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
-- Gaby
fabien.chene
Gabriel Dos Reis writes:
(Fabien Chêne) writes:
[...]
| > Je sais que ma propre implémentation expérimentale (complètement | > différente) [snip] | | En s'y prenant complètement différemment, peut-on arriver à ne pas | trop embourber le parseur, et avoir un temps de compilation | acceptable ?
Je ne sais pas. Mais, en spéculant, il faut bien voir que si la pratique actuelle de mettre tout le code dans les entêtes ne changent pas, je ne vois pas de raison d'espérer un temps de compilation peu prohibitive : avec les concepts, le compilateur doit systématiquement vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
Les compilateurs qui implémentent « export », ou bien l'optimisation à l'édition de lien, et qui vont continuer de fournir un support permettant de précompiler des entêtes pour C++0x, seront à priori bien armés pour offrir un temps de compilation acceptable ou non ? Il me semble qu'on est alors pas loin des « modules » ; au passage, si cela pouvait éradiquer les entêtes précompilées, quelle joie !
Si l'utilisation des concepts devenait finalement (je lisais à l'instant la propositions de D.Gregor sur gcc-patch) un échec du point de vue temps de compilation, cela ne serait-il pas finalement un pas vers la bonne direction ?
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
fabien.chene@gmail.com (Fabien Chêne) writes:
[...]
| > Je sais que ma propre implémentation expérimentale (complètement
| > différente) [snip]
|
| En s'y prenant complètement différemment, peut-on arriver à ne pas
| trop embourber le parseur, et avoir un temps de compilation
| acceptable ?
Je ne sais pas. Mais, en spéculant, il faut bien voir que si la
pratique actuelle de mettre tout le code dans les entêtes ne changent
pas, je ne vois pas de raison d'espérer un temps de compilation peu
prohibitive : avec les concepts, le compilateur doit systématiquement
vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
Les compilateurs qui implémentent « export », ou bien l'optimisation à
l'édition de lien, et qui vont continuer de fournir un support
permettant de précompiler des entêtes pour C++0x, seront à priori bien
armés pour offrir un temps de compilation acceptable ou non ? Il me
semble qu'on est alors pas loin des « modules » ; au passage, si cela
pouvait éradiquer les entêtes précompilées, quelle joie !
Si l'utilisation des concepts devenait finalement (je lisais à
l'instant la propositions de D.Gregor sur gcc-patch) un échec du
point de vue temps de compilation, cela ne serait-il pas finalement un
pas vers la bonne direction ?
| > Je sais que ma propre implémentation expérimentale (complètement | > différente) [snip] | | En s'y prenant complètement différemment, peut-on arriver à ne pas | trop embourber le parseur, et avoir un temps de compilation | acceptable ?
Je ne sais pas. Mais, en spéculant, il faut bien voir que si la pratique actuelle de mettre tout le code dans les entêtes ne changent pas, je ne vois pas de raison d'espérer un temps de compilation peu prohibitive : avec les concepts, le compilateur doit systématiquement vérifier tout le corps d'un template -- ce qu'il ne faisait pas avant.
Les compilateurs qui implémentent « export », ou bien l'optimisation à l'édition de lien, et qui vont continuer de fournir un support permettant de précompiler des entêtes pour C++0x, seront à priori bien armés pour offrir un temps de compilation acceptable ou non ? Il me semble qu'on est alors pas loin des « modules » ; au passage, si cela pouvait éradiquer les entêtes précompilées, quelle joie !
Si l'utilisation des concepts devenait finalement (je lisais à l'instant la propositions de D.Gregor sur gcc-patch) un échec du point de vue temps de compilation, cela ne serait-il pas finalement un pas vers la bonne direction ?
