Le résultat est :
(A l'origine le fichier est vide)
a l'écran : RIEN dans le fichier : hey baby!
pourquoi RIEN ? (ne s'affiche à l'écran)
J 'ai essayé avec, entre l'appel entre les deux operateur << et >>, les
methode seekp/seekg(0,ios::end), flush et sync ...
rien à faire.
A mon avis c'est un bogue de xlC ?
unix . aix 5.2 xlC version 6
| > Côté gestion des erreurs, c'est autre chose. | | Ce n'est pas non plus un probleme irremediable.
cela dépend de la qualité que tu veux. Le nouveau parseur C++ a d'abord essayé quelque chose come tu décris et cela a conduit à de la confusion dans beaucoup trop de cas, et finalement l'idée a été abandonnée.
J'espere que tu ne me crois pas pretentieux au point de penser qu'un deux messages ecrits en faisant autre chose j'ai pu penser et resoudre tous les problemes de parsing du C++ (j'ai l'impression qu'ils sont un ordre de grandeur plus complexes que ceux que j'ai eu a resoudre -- pour info le langage le plus complique pour lequel j'ai travaille sur un parseur est VHDL).
Au fait, est-ce que la confusion etait superieure a celles des autres methodes systematiques? (Toute les methodes automatiques que j'ai pu essayer m'ont semble catastrophiques).
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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| > Côté gestion des erreurs, c'est autre chose.
|
| Ce n'est pas non plus un probleme irremediable.
cela dépend de la qualité que tu veux. Le nouveau parseur C++ a
d'abord essayé quelque chose come tu décris et cela a conduit à de la
confusion dans beaucoup trop de cas, et finalement l'idée a été
abandonnée.
J'espere que tu ne me crois pas pretentieux au point de penser qu'un
deux messages ecrits en faisant autre chose j'ai pu penser et resoudre
tous les problemes de parsing du C++ (j'ai l'impression qu'ils sont un
ordre de grandeur plus complexes que ceux que j'ai eu a resoudre --
pour info le langage le plus complique pour lequel j'ai travaille sur
un parseur est VHDL).
Au fait, est-ce que la confusion etait superieure a celles des autres
methodes systematiques? (Toute les methodes automatiques que j'ai pu
essayer m'ont semble catastrophiques).
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
| > Côté gestion des erreurs, c'est autre chose. | | Ce n'est pas non plus un probleme irremediable.
cela dépend de la qualité que tu veux. Le nouveau parseur C++ a d'abord essayé quelque chose come tu décris et cela a conduit à de la confusion dans beaucoup trop de cas, et finalement l'idée a été abandonnée.
J'espere que tu ne me crois pas pretentieux au point de penser qu'un deux messages ecrits en faisant autre chose j'ai pu penser et resoudre tous les problemes de parsing du C++ (j'ai l'impression qu'ils sont un ordre de grandeur plus complexes que ceux que j'ai eu a resoudre -- pour info le langage le plus complique pour lequel j'ai travaille sur un parseur est VHDL).
Au fait, est-ce que la confusion etait superieure a celles des autres methodes systematiques? (Toute les methodes automatiques que j'ai pu essayer m'ont semble catastrophiques).
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
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > [...] | > | > | > Côté gestion des erreurs, c'est autre chose. | > | | > | Ce n'est pas non plus un probleme irremediable. | > | > cela dépend de la qualité que tu veux. Le nouveau parseur C++ a | > d'abord essayé quelque chose come tu décris et cela a conduit à de la | > confusion dans beaucoup trop de cas, et finalement l'idée a été | > abandonnée. | | J'espere que tu ne me crois pas pretentieux au point de penser qu'un
Non, non :-)
[...]
| Au fait, est-ce que la confusion etait superieure a celles des autres | methodes systematiques? (Toute les methodes automatiques que j'ai pu | essayer m'ont semble catastrophiques).
L'autre méthode automatique qu'on a essayée est Bison + hacks immondes. Sans les hacks immondes, évidemment c'est l'abime. Avec les hacks, on a un léger mieux, mais on rencontre des difficultés de grandeur supérieure (i.e. on ne peut pas parser correctement certaines constructions). Donc, c'est pas très comparable, mais grosso modo, c'est pas terrible. Avec la méthode que tu as décrite, on n'arrivait, dans le meilleur des cas à emettre des erreurs plusieurs fois et dans le pire les erreurs étaient mélangées. Ce qui ajoutait une autre dimension de confusion.
Actuellement, les messages ne sont pas aussi terribles qu'on voudrait mais on sait que c'est faisable et que la situation est liée plus au manque de temps (et un peu de paresse) qu'une difficulté liée à la méthode choisie.
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > Jean-Marc Bourguet <jm@bourguet.org> writes:
| >
| > [...]
| >
| > | > Côté gestion des erreurs, c'est autre chose.
| > |
| > | Ce n'est pas non plus un probleme irremediable.
| >
| > cela dépend de la qualité que tu veux. Le nouveau parseur C++ a
| > d'abord essayé quelque chose come tu décris et cela a conduit à de la
| > confusion dans beaucoup trop de cas, et finalement l'idée a été
| > abandonnée.
|
| J'espere que tu ne me crois pas pretentieux au point de penser qu'un
Non, non :-)
[...]
| Au fait, est-ce que la confusion etait superieure a celles des autres
| methodes systematiques? (Toute les methodes automatiques que j'ai pu
| essayer m'ont semble catastrophiques).
L'autre méthode automatique qu'on a essayée est Bison + hacks immondes.
Sans les hacks immondes, évidemment c'est l'abime. Avec les hacks, on
a un léger mieux, mais on rencontre des difficultés de grandeur
supérieure (i.e. on ne peut pas parser correctement certaines
constructions). Donc, c'est pas très comparable, mais grosso modo,
c'est pas terrible. Avec la méthode que tu as décrite, on
n'arrivait, dans le meilleur des cas à emettre des erreurs plusieurs
fois et dans le pire les erreurs étaient mélangées. Ce qui ajoutait
une autre dimension de confusion.
Actuellement, les messages ne sont pas aussi terribles qu'on voudrait
mais on sait que c'est faisable et que la situation est liée plus au
manque de temps (et un peu de paresse) qu'une difficulté liée à la
méthode choisie.
| Gabriel Dos Reis writes: | | > Jean-Marc Bourguet writes: | > | > [...] | > | > | > Côté gestion des erreurs, c'est autre chose. | > | | > | Ce n'est pas non plus un probleme irremediable. | > | > cela dépend de la qualité que tu veux. Le nouveau parseur C++ a | > d'abord essayé quelque chose come tu décris et cela a conduit à de la | > confusion dans beaucoup trop de cas, et finalement l'idée a été | > abandonnée. | | J'espere que tu ne me crois pas pretentieux au point de penser qu'un
Non, non :-)
[...]
| Au fait, est-ce que la confusion etait superieure a celles des autres | methodes systematiques? (Toute les methodes automatiques que j'ai pu | essayer m'ont semble catastrophiques).
L'autre méthode automatique qu'on a essayée est Bison + hacks immondes. Sans les hacks immondes, évidemment c'est l'abime. Avec les hacks, on a un léger mieux, mais on rencontre des difficultés de grandeur supérieure (i.e. on ne peut pas parser correctement certaines constructions). Donc, c'est pas très comparable, mais grosso modo, c'est pas terrible. Avec la méthode que tu as décrite, on n'arrivait, dans le meilleur des cas à emettre des erreurs plusieurs fois et dans le pire les erreurs étaient mélangées. Ce qui ajoutait une autre dimension de confusion.
Actuellement, les messages ne sont pas aussi terribles qu'on voudrait mais on sait que c'est faisable et que la situation est liée plus au manque de temps (et un peu de paresse) qu'une difficulté liée à la méthode choisie.
-- Gaby
Jean-Marc Bourguet
Gabriel Dos Reis writes:
Avec la méthode que tu as décrite, on n'arrivait, dans le meilleur des cas à emettre des erreurs plusieurs fois et dans le pire les erreurs étaient mélangées. Ce qui ajoutait une autre dimension de confusion.
Euh? La methode que j'ai decrite n'emet qu'un seul message d'erreur et s'arrete (Ce qui en soi est un probleme; la completer pour continuer a parser est interessant. Une idee pendant que mon test passe, plutot que de se suicider lors de la detection d'erreur, les parseurs se mettent dans un etat de zombie. Si le symbole est accepte par au moins 1 parseur, on tue les zombies, sinon on demande aux zombies de donner un score indiquant la facilite avec laquelle ils arrivent a continuer et un de ceux ayant le meilleur score est choisi et est le seul a continuer et a emettre un message d'erreur. Tiens on revient a la methode initiale parce qu'il est a nouveau question de backtrack).
Actuellement, les messages ne sont pas aussi terribles qu'on voudrait mais on sait que c'est faisable et que la situation est liée plus au manque de temps (et un peu de paresse) qu'une difficulté liée à la méthode choisie.
C'est quoi la methode actuelle? (Je sais j'ai qu'a prendre les sources)
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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
Avec la méthode que tu as décrite, on n'arrivait, dans le meilleur
des cas à emettre des erreurs plusieurs fois et dans le pire les
erreurs étaient mélangées. Ce qui ajoutait une autre dimension de
confusion.
Euh? La methode que j'ai decrite n'emet qu'un seul message d'erreur
et s'arrete (Ce qui en soi est un probleme; la completer pour
continuer a parser est interessant. Une idee pendant que mon test
passe, plutot que de se suicider lors de la detection d'erreur, les
parseurs se mettent dans un etat de zombie. Si le symbole est accepte
par au moins 1 parseur, on tue les zombies, sinon on demande aux
zombies de donner un score indiquant la facilite avec laquelle ils
arrivent a continuer et un de ceux ayant le meilleur score est choisi
et est le seul a continuer et a emettre un message d'erreur. Tiens on
revient a la methode initiale parce qu'il est a nouveau question de
backtrack).
Actuellement, les messages ne sont pas aussi terribles qu'on
voudrait mais on sait que c'est faisable et que la situation est
liée plus au manque de temps (et un peu de paresse) qu'une
difficulté liée à la méthode choisie.
C'est quoi la methode actuelle? (Je sais j'ai qu'a prendre les
sources)
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
Avec la méthode que tu as décrite, on n'arrivait, dans le meilleur des cas à emettre des erreurs plusieurs fois et dans le pire les erreurs étaient mélangées. Ce qui ajoutait une autre dimension de confusion.
Euh? La methode que j'ai decrite n'emet qu'un seul message d'erreur et s'arrete (Ce qui en soi est un probleme; la completer pour continuer a parser est interessant. Une idee pendant que mon test passe, plutot que de se suicider lors de la detection d'erreur, les parseurs se mettent dans un etat de zombie. Si le symbole est accepte par au moins 1 parseur, on tue les zombies, sinon on demande aux zombies de donner un score indiquant la facilite avec laquelle ils arrivent a continuer et un de ceux ayant le meilleur score est choisi et est le seul a continuer et a emettre un message d'erreur. Tiens on revient a la methode initiale parce qu'il est a nouveau question de backtrack).
Actuellement, les messages ne sont pas aussi terribles qu'on voudrait mais on sait que c'est faisable et que la situation est liée plus au manque de temps (et un peu de paresse) qu'une difficulté liée à la méthode choisie.
C'est quoi la methode actuelle? (Je sais j'ai qu'a prendre les sources)
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
Gabriel Dos Reis writes:
|> writes:
|> | > C'est une structure capable d'analyser toutes les grammaires non |> | > ambigues. Il y a deux problemes: la gestion des actions |> | > semantiques et la gestion des erreurs.
|> | Si les actions sémantiques ne sont pas irrévocables, je ne |> | vois pas trop de problème. Dans beaucoup de cas, l'action |> | sémantique ne fait que construire un arbre -- dans ce |> | cas-là, c'est facile à jeter l'arbre quand le thread |> | échoue, et ne prendre en compte que l'arbre d'un des threads |> | à la fin.
|> sauf quand on parse C++ -- qui est un bon exemple de langage qui |> impose le back-tracking. Et da'près l'avis des différents |> fabricants de compilateur (surtout ceux de EDG compris), cela n'est |> pas du tout facile comme tu prétents (et ton "beaucoup de cas" |> est en fait *peu*, du moins si tu considères que C++ a des |> templates).
Tout est facile, tant qu'on n'a pas à le faire soi-même :-).
Loin de moi à dire que c'est réelement facile. Disons que je ne vois pas de problème a priori -- ça ne veut pas dire qu'il n'en a pas.
Par contre, en ce qui concerne le problème de la gestion des erreurs, je vois des problèmes déjà avant de commencer. Au moins qu'on se contente de s'arrêter à la première erreur, avec comme message d'erreur un simple '?'.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> kanze@gabi-soft.fr writes:
|> | > C'est une structure capable d'analyser toutes les grammaires non
|> | > ambigues. Il y a deux problemes: la gestion des actions
|> | > semantiques et la gestion des erreurs.
|> | Si les actions sémantiques ne sont pas irrévocables, je ne
|> | vois pas trop de problème. Dans beaucoup de cas, l'action
|> | sémantique ne fait que construire un arbre -- dans ce
|> | cas-là, c'est facile à jeter l'arbre quand le thread
|> | échoue, et ne prendre en compte que l'arbre d'un des threads
|> | à la fin.
|> sauf quand on parse C++ -- qui est un bon exemple de langage qui
|> impose le back-tracking. Et da'près l'avis des différents
|> fabricants de compilateur (surtout ceux de EDG compris), cela n'est
|> pas du tout facile comme tu prétents (et ton "beaucoup de cas"
|> est en fait *peu*, du moins si tu considères que C++ a des
|> templates).
Tout est facile, tant qu'on n'a pas à le faire soi-même :-).
Loin de moi à dire que c'est réelement facile. Disons que je ne
vois pas de problème a priori -- ça ne veut pas dire qu'il n'en a
pas.
Par contre, en ce qui concerne le problème de la gestion des erreurs,
je vois des problèmes déjà avant de commencer. Au moins qu'on
se contente de s'arrêter à la première erreur, avec comme
message d'erreur un simple '?'.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> | > C'est une structure capable d'analyser toutes les grammaires non |> | > ambigues. Il y a deux problemes: la gestion des actions |> | > semantiques et la gestion des erreurs.
|> | Si les actions sémantiques ne sont pas irrévocables, je ne |> | vois pas trop de problème. Dans beaucoup de cas, l'action |> | sémantique ne fait que construire un arbre -- dans ce |> | cas-là, c'est facile à jeter l'arbre quand le thread |> | échoue, et ne prendre en compte que l'arbre d'un des threads |> | à la fin.
|> sauf quand on parse C++ -- qui est un bon exemple de langage qui |> impose le back-tracking. Et da'près l'avis des différents |> fabricants de compilateur (surtout ceux de EDG compris), cela n'est |> pas du tout facile comme tu prétents (et ton "beaucoup de cas" |> est en fait *peu*, du moins si tu considères que C++ a des |> templates).
Tout est facile, tant qu'on n'a pas à le faire soi-même :-).
Loin de moi à dire que c'est réelement facile. Disons que je ne vois pas de problème a priori -- ça ne veut pas dire qu'il n'en a pas.
Par contre, en ce qui concerne le problème de la gestion des erreurs, je vois des problèmes déjà avant de commencer. Au moins qu'on se contente de s'arrêter à la première erreur, avec comme message d'erreur un simple '?'.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
