En lisant le "Exceptionnal C++" (je dis ça de tête, j'ai oublié
de noter la page), il justifie à un moment le fait que les
destructeurs de conteneurs ne spécifient pas de throw() pour
des questions de perf. Et je n'arrive pas à imaginer, avec mes
connaissance (limitée) en compilation, pourquoi ce serait couteux.
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait
me dire pourquoi les destructeurs de conteneurs STL ne sont pas
spécifiés throw().
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Le Wed, 05 Nov 2003 08:45:24 +0000, Marc Boyer a écrit :
En lisant le "Exceptionnal C++" (je dis ça de tête, j'ai oublié de noter la page), il justifie à un moment le fait que les destructeurs de conteneurs ne spécifient pas de throw() pour des questions de perf. Et je n'arrive pas à imaginer, avec mes connaissance (limitée) en compilation, pourquoi ce serait couteux.
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés throw().
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Le Wed, 05 Nov 2003 08:45:24 +0000, Marc Boyer a écrit :
En lisant le "Exceptionnal C++" (je dis ça de tête, j'ai oublié de
noter la page), il justifie à un moment le fait que les destructeurs de
conteneurs ne spécifient pas de throw() pour des questions de perf. Et
je n'arrive pas à imaginer, avec mes connaissance (limitée) en
compilation, pourquoi ce serait couteux.
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me
dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés
throw().
je pense que c'est parce qu'on ne présume pas du comportement du
destructeur des éléments
Le Wed, 05 Nov 2003 08:45:24 +0000, Marc Boyer a écrit :
En lisant le "Exceptionnal C++" (je dis ça de tête, j'ai oublié de noter la page), il justifie à un moment le fait que les destructeurs de conteneurs ne spécifient pas de throw() pour des questions de perf. Et je n'arrive pas à imaginer, avec mes connaissance (limitée) en compilation, pourquoi ce serait couteux.
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés throw().
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Marc Boyer
Benoit Dejean wrote:
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés throw().
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un destructeur est interdit (enfin, que ça provoque un appel de std::terminate), ça permettrait de le vérifier à la compilation. Non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Benoit Dejean wrote:
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me
dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés
throw().
je pense que c'est parce qu'on ne présume pas du comportement du
destructeur des éléments
Voui, mais puisque le langage impose qu'une exception
dans un destructeur est interdit (enfin, que ça provoque
un appel de std::terminate), ça permettrait de le vérifier
à la compilation. Non ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés throw().
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un destructeur est interdit (enfin, que ça provoque un appel de std::terminate), ça permettrait de le vérifier à la compilation. Non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Jean-Marc Bourguet
Marc Boyer writes:
Benoit Dejean wrote:
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés throw().
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un destructeur est interdit (enfin, que ça provoque un appel de std::terminate)
Non, c'est une exception pendant une exception qui provoque std::terminate et encore il faut qu'elle soit active simultanement. Une exception pendant un destructeur, c'est sur que c'est permis tant qu'elle ne sort pas du destructeur. Si elle sort, je ne suis pas sur que ce soit interdit (mais je me demande dans quel etat ca laisse l'objet), mais ca peut provoquer une double exception si la cause de l'execution du destructeur etait justement une exception.
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Benoit Dejean wrote:
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me
dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés
throw().
je pense que c'est parce qu'on ne présume pas du comportement du
destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un
destructeur est interdit (enfin, que ça provoque un appel de
std::terminate)
Non, c'est une exception pendant une exception qui provoque
std::terminate et encore il faut qu'elle soit active simultanement.
Une exception pendant un destructeur, c'est sur que c'est permis tant
qu'elle ne sort pas du destructeur. Si elle sort, je ne suis pas sur
que ce soit interdit (mais je me demande dans quel etat ca laisse
l'objet), mais ca peut provoquer une double exception si la cause de
l'execution du destructeur etait justement une exception.
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
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
Et si ma mémoire est défaillante, est-ce que quelquu'un pourrait me dire pourquoi les destructeurs de conteneurs STL ne sont pas spécifiés throw().
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un destructeur est interdit (enfin, que ça provoque un appel de std::terminate)
Non, c'est une exception pendant une exception qui provoque std::terminate et encore il faut qu'elle soit active simultanement. Une exception pendant un destructeur, c'est sur que c'est permis tant qu'elle ne sort pas du destructeur. Si elle sort, je ne suis pas sur que ce soit interdit (mais je me demande dans quel etat ca laisse l'objet), mais ca peut provoquer une double exception si la cause de l'execution du destructeur etait justement une exception.
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
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
Laurent Deniau
Marc Boyer wrote:
En lisant le "Exceptionnal C++" (je dis ça de tête, j'ai oublié de noter la page), il justifie à un moment le fait que les destructeurs de conteneurs ne spécifient pas de throw() pour des questions de perf. Et je n'arrive pas à imaginer, avec mes connaissance (limitée) en compilation, pourquoi ce serait couteux.
Parce que cela implique un try implicite sur le corps de la fonction comme explique dans l'introduction de la section 14.6 du TC++PL3:
donc si try a un cout non negligeable et que l'on met des specifications d'exceptions sur des fonctions critiques (ctor, dtor), on peut voir un probleme de performance survenir...
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Marc Boyer wrote:
En lisant le "Exceptionnal C++" (je dis ça de tête, j'ai oublié
de noter la page), il justifie à un moment le fait que les
destructeurs de conteneurs ne spécifient pas de throw() pour
des questions de perf. Et je n'arrive pas à imaginer, avec mes
connaissance (limitée) en compilation, pourquoi ce serait couteux.
Parce que cela implique un try implicite sur le corps de la fonction comme
explique dans l'introduction de la section 14.6 du TC++PL3:
donc si try a un cout non negligeable et que l'on met des specifications
d'exceptions sur des fonctions critiques (ctor, dtor), on peut voir un probleme
de performance survenir...
a+, ld.
--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]
En lisant le "Exceptionnal C++" (je dis ça de tête, j'ai oublié de noter la page), il justifie à un moment le fait que les destructeurs de conteneurs ne spécifient pas de throw() pour des questions de perf. Et je n'arrive pas à imaginer, avec mes connaissance (limitée) en compilation, pourquoi ce serait couteux.
Parce que cela implique un try implicite sur le corps de la fonction comme explique dans l'introduction de la section 14.6 du TC++PL3:
donc si try a un cout non negligeable et que l'on met des specifications d'exceptions sur des fonctions critiques (ctor, dtor), on peut voir un probleme de performance survenir...
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Marc Boyer
Laurent Deniau wrote:
Marc Boyer wrote: Parce que cela implique un try implicite sur le corps de la fonction comme explique dans l'introduction de la section 14.6 du TC++PL3:
OK, merci.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Laurent Deniau wrote:
Marc Boyer wrote:
Parce que cela implique un try implicite sur le corps de la fonction comme
explique dans l'introduction de la section 14.6 du TC++PL3:
OK, merci.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer wrote: Parce que cela implique un try implicite sur le corps de la fonction comme explique dans l'introduction de la section 14.6 du TC++PL3:
OK, merci.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer
Jean-Marc Bourguet wrote:
Marc Boyer writes:
Benoit Dejean wrote:
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un destructeur est interdit (enfin, que ça provoque un appel de std::terminate)
Non, c'est une exception pendant une exception qui provoque std::terminate et encore il faut qu'elle soit active simultanement. Une exception pendant un destructeur, c'est sur que c'est permis tant qu'elle ne sort pas du destructeur. Si elle sort, je ne suis pas sur que ce soit interdit (mais je me demande dans quel etat ca laisse l'objet), mais ca peut provoquer une double exception si la cause de l'execution du destructeur etait justement une exception.
OK, je viens de relire TC++PL 14.4.7, et tu as en effet raison (et moi, pas tout à fait tort mais tort quand même).
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des signatures d'exception à la compilation. Qu'est-ce qui dans C++ empècherait de faire de même ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Benoit Dejean wrote:
je pense que c'est parce qu'on ne présume pas du comportement du
destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un
destructeur est interdit (enfin, que ça provoque un appel de
std::terminate)
Non, c'est une exception pendant une exception qui provoque
std::terminate et encore il faut qu'elle soit active simultanement.
Une exception pendant un destructeur, c'est sur que c'est permis tant
qu'elle ne sort pas du destructeur. Si elle sort, je ne suis pas sur
que ce soit interdit (mais je me demande dans quel etat ca laisse
l'objet), mais ca peut provoquer une double exception si la cause de
l'execution du destructeur etait justement une exception.
OK, je viens de relire TC++PL 14.4.7, et tu as en effet raison
(et moi, pas tout à fait tort mais tort quand même).
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des
signatures d'exception à la compilation. Qu'est-ce qui dans
C++ empècherait de faire de même ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
je pense que c'est parce qu'on ne présume pas du comportement du destructeur des éléments
Voui, mais puisque le langage impose qu'une exception dans un destructeur est interdit (enfin, que ça provoque un appel de std::terminate)
Non, c'est une exception pendant une exception qui provoque std::terminate et encore il faut qu'elle soit active simultanement. Une exception pendant un destructeur, c'est sur que c'est permis tant qu'elle ne sort pas du destructeur. Si elle sort, je ne suis pas sur que ce soit interdit (mais je me demande dans quel etat ca laisse l'objet), mais ca peut provoquer une double exception si la cause de l'execution du destructeur etait justement une exception.
OK, je viens de relire TC++PL 14.4.7, et tu as en effet raison (et moi, pas tout à fait tort mais tort quand même).
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des signatures d'exception à la compilation. Qu'est-ce qui dans C++ empècherait de faire de même ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Jean-Marc Bourguet
Marc Boyer writes:
Jean-Marc Bourguet wrote:
Marc Boyer writes:
[... verification statique qu'un destructeur ne jette pas d'exception ...]
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des signatures d'exception à la compilation. Qu'est-ce qui dans C++ empècherait de faire de même ?
Pour qu'une verification statique soit possible, il faut: - que toutes les fonctions soient avec une specification - qu'on admette de rejeter du code qui ne jette pas d'exception mais que le compilateur ne peut pas prouver; pour eviter de dependre de l'algo precis du compilateur, on impose donc des contraintes assez stictes (le meme genre de chose a lieu pour les variables non initialisees)
Ces deux conditions ne sont reunissable que quand on commence par definir le langage avec.
Personnellement, je suis globalement pour les verifications statiques, meme quand ca impose ce genre de contraintes. Sauf pour les specification d'exceptions ou je trouve que la seule utile est throw(), au dela bien souvent la seul chose sensee est par reference.
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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
[... verification statique qu'un destructeur ne jette pas d'exception ...]
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des
signatures d'exception à la compilation. Qu'est-ce qui dans
C++ empècherait de faire de même ?
Pour qu'une verification statique soit possible, il faut:
- que toutes les fonctions soient avec une specification
- qu'on admette de rejeter du code qui ne jette pas d'exception
mais que le compilateur ne peut pas prouver; pour eviter de
dependre de l'algo precis du compilateur, on impose donc des
contraintes assez stictes (le meme genre de chose a lieu pour les
variables non initialisees)
Ces deux conditions ne sont reunissable que quand on commence par
definir le langage avec.
Personnellement, je suis globalement pour les verifications statiques,
meme quand ca impose ce genre de contraintes. Sauf pour les
specification d'exceptions ou je trouve que la seule utile est
throw(), au dela bien souvent la seul chose sensee est par reference.
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
[... verification statique qu'un destructeur ne jette pas d'exception ...]
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des signatures d'exception à la compilation. Qu'est-ce qui dans C++ empècherait de faire de même ?
Pour qu'une verification statique soit possible, il faut: - que toutes les fonctions soient avec une specification - qu'on admette de rejeter du code qui ne jette pas d'exception mais que le compilateur ne peut pas prouver; pour eviter de dependre de l'algo precis du compilateur, on impose donc des contraintes assez stictes (le meme genre de chose a lieu pour les variables non initialisees)
Ces deux conditions ne sont reunissable que quand on commence par definir le langage avec.
Personnellement, je suis globalement pour les verifications statiques, meme quand ca impose ce genre de contraintes. Sauf pour les specification d'exceptions ou je trouve que la seule utile est throw(), au dela bien souvent la seul chose sensee est par reference.
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
Marc Boyer
Jean-Marc Bourguet wrote:
Marc Boyer writes: Pour qu'une verification statique soit possible, il faut: - que toutes les fonctions soient avec une specification
Dans la théorie, on pourrait imaginer qu'une absence de spec spécifie "any exception", mais dans la pratique, avec tout le code déjà existant, on peut pas.
- qu'on admette de rejeter du code qui ne jette pas d'exception mais que le compilateur ne peut pas prouver; pour eviter de dependre de l'algo precis du compilateur, on impose donc des contraintes assez stictes (le meme genre de chose a lieu pour les variables non initialisees)
Le C++ est assez pragmatique pour permettre d'offrir un moyen au programmeur de contourner les vérifs statiques quand il le désire. On aurait un truc genre throw_cast<throw()> ou autre syntaxe du genre.
Personnellement, je suis globalement pour les verifications statiques, meme quand ca impose ce genre de contraintes. Sauf pour les specification d'exceptions ou je trouve que la seule utile est throw(), au dela bien souvent la seul chose sensee est par reference.
J'ai pas assez d'expérience pour en juger. Sur le papier, les spec d'exception (cf Java) me plaisent bien. Sur un vrai gros projet, je sais pas.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Pour qu'une verification statique soit possible, il faut:
- que toutes les fonctions soient avec une specification
Dans la théorie, on pourrait imaginer qu'une absence
de spec spécifie "any exception", mais dans la pratique,
avec tout le code déjà existant, on peut pas.
- qu'on admette de rejeter du code qui ne jette pas d'exception
mais que le compilateur ne peut pas prouver; pour eviter de
dependre de l'algo precis du compilateur, on impose donc des
contraintes assez stictes (le meme genre de chose a lieu pour les
variables non initialisees)
Le C++ est assez pragmatique pour permettre d'offrir un moyen au
programmeur de contourner les vérifs statiques quand il le désire.
On aurait un truc genre throw_cast<throw()> ou autre syntaxe du genre.
Personnellement, je suis globalement pour les verifications statiques,
meme quand ca impose ce genre de contraintes. Sauf pour les
specification d'exceptions ou je trouve que la seule utile est
throw(), au dela bien souvent la seul chose sensee est par reference.
J'ai pas assez d'expérience pour en juger. Sur le papier, les
spec d'exception (cf Java) me plaisent bien. Sur un vrai gros
projet, je sais pas.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer writes: Pour qu'une verification statique soit possible, il faut: - que toutes les fonctions soient avec une specification
Dans la théorie, on pourrait imaginer qu'une absence de spec spécifie "any exception", mais dans la pratique, avec tout le code déjà existant, on peut pas.
- qu'on admette de rejeter du code qui ne jette pas d'exception mais que le compilateur ne peut pas prouver; pour eviter de dependre de l'algo precis du compilateur, on impose donc des contraintes assez stictes (le meme genre de chose a lieu pour les variables non initialisees)
Le C++ est assez pragmatique pour permettre d'offrir un moyen au programmeur de contourner les vérifs statiques quand il le désire. On aurait un truc genre throw_cast<throw()> ou autre syntaxe du genre.
Personnellement, je suis globalement pour les verifications statiques, meme quand ca impose ce genre de contraintes. Sauf pour les specification d'exceptions ou je trouve que la seule utile est throw(), au dela bien souvent la seul chose sensee est par reference.
J'ai pas assez d'expérience pour en juger. Sur le papier, les spec d'exception (cf Java) me plaisent bien. Sur un vrai gros projet, je sais pas.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze
Marc Boyer wrote in message news:<boarin$724$...
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des signatures d'exception à la compilation. Qu'est-ce qui dans C++ empècherait de faire de même ?
D'abord, Java ne vérifie la cohérence que partiellement. Deuxièmement, il y a une différence importante dans la signification des spécifications d'exceptions dans les deux langages. En Java, une spécification d'exception signifie qu'on ne lèvera pas une exception non mentionnée ; en C++, la spécification d'exception signifie que si on lève une telle exception, la fonction unexpected serait appelée, et qu'éventuellement, l'exception serait convertie en std::bad_exception.
Je suis bien d'accord que dans ce cas-ci, les règles de Java sont plus utiles. Elles seraient encore plus utiles en Java s'il n'y avait pas tant d'exceptions -- si on traitait de vraies erreurs comme des vraies erreurs, et qu'on enforçait les spécifications d'exception pour toutes les exceptions.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<boarin$724$2@news.cict.fr>...
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des signatures
d'exception à la compilation. Qu'est-ce qui dans C++ empècherait de
faire de même ?
D'abord, Java ne vérifie la cohérence que partiellement. Deuxièmement,
il y a une différence importante dans la signification des
spécifications d'exceptions dans les deux langages. En Java, une
spécification d'exception signifie qu'on ne lèvera pas une exception non
mentionnée ; en C++, la spécification d'exception signifie que si on
lève une telle exception, la fonction unexpected serait appelée, et
qu'éventuellement, l'exception serait convertie en std::bad_exception.
Je suis bien d'accord que dans ce cas-ci, les règles de Java sont plus
utiles. Elles seraient encore plus utiles en Java s'il n'y avait pas
tant d'exceptions -- si on traitait de vraies erreurs comme des vraies
erreurs, et qu'on enforçait les spécifications d'exception pour toutes
les exceptions.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
ça permettrait de le vérifier à la compilation. Non ?
Tu as resolut le probleme de l'arret?
Je vois pas le problème. Java vérifie la cohérence des signatures d'exception à la compilation. Qu'est-ce qui dans C++ empècherait de faire de même ?
D'abord, Java ne vérifie la cohérence que partiellement. Deuxièmement, il y a une différence importante dans la signification des spécifications d'exceptions dans les deux langages. En Java, une spécification d'exception signifie qu'on ne lèvera pas une exception non mentionnée ; en C++, la spécification d'exception signifie que si on lève une telle exception, la fonction unexpected serait appelée, et qu'éventuellement, l'exception serait convertie en std::bad_exception.
Je suis bien d'accord que dans ce cas-ci, les règles de Java sont plus utiles. Elles seraient encore plus utiles en Java s'il n'y avait pas tant d'exceptions -- si on traitait de vraies erreurs comme des vraies erreurs, et qu'on enforçait les spécifications d'exception pour toutes les exceptions.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Jean-Marc Bourguet
Marc Boyer writes:
J'ai pas assez d'expérience pour en juger. Sur le papier, les spec d'exception (cf Java) me plaisent bien. Sur un vrai gros projet, je sais pas.
J'ai deja parle du cas de code partage (et encore en developpement) entre deux projets qui utilisent des back-end differents jetant des exceptions differentes. Tout ce qu'a a connaitre le code, c'est que des exceptions sont possibles, si on doit les specifier, il faut augmenter la couche d'interface vers les backs-end pour catcher et encapsuler les exceptions et ajouter une couche pour les desencapsuler.
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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
J'ai pas assez d'expérience pour en juger. Sur le papier, les
spec d'exception (cf Java) me plaisent bien. Sur un vrai gros
projet, je sais pas.
J'ai deja parle du cas de code partage (et encore en developpement)
entre deux projets qui utilisent des back-end differents jetant des
exceptions differentes. Tout ce qu'a a connaitre le code, c'est que
des exceptions sont possibles, si on doit les specifier, il faut
augmenter la couche d'interface vers les backs-end pour catcher et
encapsuler les exceptions et ajouter une couche pour les
desencapsuler.
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 pas assez d'expérience pour en juger. Sur le papier, les spec d'exception (cf Java) me plaisent bien. Sur un vrai gros projet, je sais pas.
J'ai deja parle du cas de code partage (et encore en developpement) entre deux projets qui utilisent des back-end differents jetant des exceptions differentes. Tout ce qu'a a connaitre le code, c'est que des exceptions sont possibles, si on doit les specifier, il faut augmenter la couche d'interface vers les backs-end pour catcher et encapsuler les exceptions et ajouter une couche pour les desencapsuler.
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
