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 :-(
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.
Pour être vraiment utile, l'absence de spéc doit signifier pas d'exception. Mais avec le code déjà existant, on ne 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.
Il y a aussi un deuxième problème qu'il faudrait résoudre : comment spécifier que std::vector<T>::vector<T>( size_t, T const& ) ne peut lever que std::bad_alloc OU des exceptions levées éventuellement par le constructeur de copie de T ?
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.
Il y a un gros problème avec les exceptions en Java. Tout problème se résoud en exception. Et est-ce que tu pourrais concevoir une fonction où java.lang.VirtualMachineError ne peut pas être levée ? Du coup, il y a des exceptions qui sont vérifiées, et celles qui ne le sont pas, d'une façon un peu arbitraire. Le résultat, c'est que tu as les desavantages des deux solutions.
-- 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:<bocu6l$k3m$1@news.cict.fr>...
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.
Pour être vraiment utile, l'absence de spéc doit signifier pas
d'exception. Mais avec le code déjà existant, on ne 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.
Il y a aussi un deuxième problème qu'il faudrait résoudre : comment
spécifier que std::vector<T>::vector<T>( size_t, T const& ) ne peut
lever que std::bad_alloc OU des exceptions levées éventuellement par le
constructeur de copie de T ?
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.
Il y a un gros problème avec les exceptions en Java. Tout problème se
résoud en exception. Et est-ce que tu pourrais concevoir une fonction où
java.lang.VirtualMachineError ne peut pas être levée ? Du coup, il y a
des exceptions qui sont vérifiées, et celles qui ne le sont pas, d'une
façon un peu arbitraire. Le résultat, c'est que tu as les desavantages
des deux solutions.
--
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
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.
Pour être vraiment utile, l'absence de spéc doit signifier pas d'exception. Mais avec le code déjà existant, on ne 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.
Il y a aussi un deuxième problème qu'il faudrait résoudre : comment spécifier que std::vector<T>::vector<T>( size_t, T const& ) ne peut lever que std::bad_alloc OU des exceptions levées éventuellement par le constructeur de copie de T ?
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.
Il y a un gros problème avec les exceptions en Java. Tout problème se résoud en exception. Et est-ce que tu pourrais concevoir une fonction où java.lang.VirtualMachineError ne peut pas être levée ? Du coup, il y a des exceptions qui sont vérifiées, et celles qui ne le sont pas, d'une façon un peu arbitraire. Le résultat, c'est que tu as les desavantages des deux solutions.
-- 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
