Définition d'une hiérarchie d'exceptions

Alain Gaillard wrote:

[...]

Donc en effet et si je ne m'abuse, NDEBUG concerne bien assert
et assert seulement et aucunement une compilation en mode
debug, ni l'inverse d'ailleurs.

La norme ne connaît pas de notion de « mode debug » ou
d'autre. Elle ne s'occupe pas non plus de comment on invoque de
diverses options que peuvent avoir un compilateur. Formellement,
un compilateur pourrait traiter le fait que NDEBUG soit défini
ou non comme un espèce de pragma qui influe sur l'optimisation,
la génération des information de déboggage, etc. (Mais je ne
connais pas de compilateur où c'est le cas.)

Même si on s'attend quand même
à trouver NDEBUG là où il n'y a pas de compilation en "mode
debug" :)

Je ne suis pas sûr ce qu'on entend par « mode debug ». J'en
vois plusieurs choses qui peuvent varier : l'absence ou la
présence des informations de deboggage dans le fichier (sous
Unix, au moins, il y a une commande strip qui permet de les
enlever après le fait), les différents niveaux d'optimisation,
la présence ou l'absence des vérifications dans la bibliothèque
standard (ou dans le code utilisateur), dans certains cas, la
presence ou l'absence des traces, etc. Toutes ses options sont
orthogonales, peuvent être activées ou désactivées
indépendamment, et le sont corramment.

En général, on essaie de livrer un code le plus près possible au
code qu'on a testé. C-à-d que les options qui modifie le code
générer (présence ou absence des vérifications, optimisation)
sont les mêmes dans le code livré et le code de développement,
dans la mesure du possible. On n'active l'optimisateur que si le
profileur en indique la nécessité, et on ne supprime les
vérifications que si l'activation de l'optimisateur n'a pas
suffit. (Et on « déboggue » alors avec les nouvelles options,
même si c'est beaucoup plus difficile.) En revanche, il est
assez courant d'enlève les informations de déboggage dans les
exécutables qu'on livre, parce que ça n'a aucune influence sur
le code exécutable.

--
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

Donc en effet et si je ne m'abuse, NDEBUG concerne bien assert
et assert seulement et aucunement une compilation en mode
debug, ni l'inverse d'ailleurs.

La norme ne connaît pas de notion de « mode debug »

Je ne pense pas avoir dit autre chose en citant 17.4.2.1
Pour faire bonne mesure j'ajoute que la norme ne connait pas non plus de
"mode release"

Je ne suis pas sûr ce qu'on entend par « mode debug ».

Je pense que ce sont des utilisateurs de VC++ qui ont fait allusion au
"mode debug" de celui-ci, comme ils auraient pu faire allusion au "mode
release".

Quand on bascule en "mode release", VC++ (le mien, 2005, en tout cas)
définit la macro NDEBUG.
Mais on est bien d'accord c'est un comportement par défaut de VC++ rien
de plus. Il serait correct sous ce mode de ne pas définir la macro de
même qu'il serait correct de la définir en mode debug si on veut.

Puisque la macro selon norme (et comme je l'ai dit) "concerne bien
assert et assert seulement et aucunement une compilation en mode debug,
ni l'inverse d'ailleurs"


--
Alain

Alain Gaillard wrote:

[...]

Je ne suis pas sûr ce qu'on entend par « mode debug ».

Je pense que ce sont des utilisateurs de VC++ qui ont fait
allusion au "mode debug" de celui-ci, comme ils auraient pu
faire allusion au "mode release".

J'utilise VC++ depuis quelque semaines, et je n'y ai pas trouvé
un mode debug non plus. Tout au plus, l'IDE propose (sans rien
imposer) un certain nombre de défauts pour les options de
compilation -- qu'on est libre de prendre ou de laisser.

Quand on bascule en "mode release", VC++ (le mien, 2005, en
tout cas) définit la macro NDEBUG.

Et c'est où, cette « mode release » ? J'utilise aussi VC++
2005, et je ne l'ai pas trouvé. (Il n'apparaît en tout cas pas
quand on fait « cl /help ». Mais je sais qu'il y a d'autres
options aussi qui n'y apparaissent pas non plus.)

Mais on est bien d'accord c'est un comportement par défaut de
VC++ rien de plus.

Le comportement par défaut de VC++, c'est de ne pas définir
NDEBUG. Il est défini dans certaines configurations proposées
par l'IDE. Mais qui utilise une configuration quelconque sans
savoir ce qu'elle fait. (Et est-ce que tu as déjà trouvé un
défaut quelconque qui convient sans modification à ton
environement et à ta mode de travailler ?)

--
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

J'utilise VC++ depuis quelque semaines, et je n'y ai pas trouvé
un mode debug non plus.

Et comme tu l'utilises en ligne de commande, ainsi que tu l'as dit dans
un autre post, c'est normal :)

Mais tout le monde n'est pas masochiste comme toi ;)
Quelle idée de ne pas utiliser l'IDE :)
Moi j'aime bien utiliser l'IDE je trouve ça très pratique. Emacs et les
makefiles j'ai passé l'âge.
Ce "mode debug" ou "configuration debug" si tu préfères est évidemment
une cuisine de l'IDE.

Et c'est où, cette « mode release »

Oh... juste à côté du "mode debug" ;)


? J'utilise aussi VC++

2005, et je ne l'ai pas trouvé.

Tu n'utilises pas VC++
Tu utilises cl 2005, i.e le compilateur de VC++ 2005
Dans VC++ il y a V qui signifie Visual, ce que tout le monde comprend
comme l'IDE complet :-)

Le comportement par défaut de VC++, c'est de ne pas définir
NDEBUG.

Le comportement par défaut de VC++ (avec un V comme Visual, donc, l'IDE)
est bien de définir par défaut NDEBUG en "mode relase" :)

Le compilateur, cl, lui ne définit rien du tout en effet. Sans doute
est-ce ce que ce tu as voulu dire ?

Il est défini dans certaines configurations proposées
par l'IDE.

Ben voilà, on y arrive :)

(Et est-ce que tu as déjà trouvé un
défaut quelconque qui convient sans modification à ton
environement et à ta mode de travailler ?)

Non, en effet.


--
Alain

Alain Gaillard wrote:

C'est uniquement dans le cas de la construction d'un
tableau "automatique" (i.e. alloué dans la pile) que seul l'objet levant
l'exception est détruit.

Même pas au fait.
Les objets dans le tableau construits avant la levée de l'exception
seront détruits mais pas l'objet levant l'exception. Si l'exception est
levée dans le constructeur je veux dire. Dans ce cas l'objet en question
n'est pas construit du tout.

En effet, je parlais d'une exception levée au cours de la construction
d'un tableau "automatique" (j'aime pas ce terme, mais j'ai rien de mieux
:/), alors seul l'élément du tableau qui a levé l'exception est réputé
non construit, les autres éléments sont construits correctement et ne
sont pas détruits. Par contre, j'arrive pas à imaginer une situation où
on pourrait effectivement /observer/ ce phénomène (i.e. la
non-destructions des éléments du tableau à la levée de l'exception)

Pierre

Pierre Barbier de Reuille wrote:

Sylvain Togni wrote:

Dans ce cas je teste :
1 - exécution sans gestion d'erreur (Time without errors)
2 - exécution avec exception (chaque appel lance une exception ou
presque)
3 - exécution avec gestion des exception mais sans levée d'except ion
4 - avec exception, mais peu d'exceptions sont effectivement levées
5 - erreur par valeurs de retour (pratiquement tous les appels gén ères
des erreurs)
6 - erreur par valeurs de retour (peu d'erreurs relevées)

Voici les temps que j'obtiens chez moi (compilé avec g++
avec les options par défaut):

Time without errors : 1.28000 sec
Time with exceptions : 89.0000 sec
Time with (no) exceptions : 1.31000 sec
Time with (few) exceptions : 2.03000 sec
Time with return values : 2.33000 sec
Time with (few) return values : 2.34000 sec

La bonne performance du 3 viens du test effectué (i < 0) par
rapport aux autres tests (i%10 == 0 ou i%100000 == 0).

Parmi d'autres choses. Les résultats dépendent beaucoup de
l'implémentation. C'est donc extrèmement difficile à tirer des
conclusions concrètes.

Ce que j'avais dit au départ, c'est que je n'ai jamais rencontré
un cas réel (dans un programme réel) où la différence aurait pû
être signifiante. Dans les programmes réels, pour des valeurs de
rétour, j'utilise prèsque toujours un type de classe (qui avorte
si l'erreur n'est pas testée, ou si elle encapsule une valeur de
rétour de la fonction, avorte si on essaie de s'en servir en cas
d'erreur). Dans le cas d'un code d'erreur simple, la classe est
conçue de façon à pouvoir être remplacée par un typedef bool,
s'il s'avère que la performance l'exige. À ce jour, ça n'a
jamais été le cas. Dans la pratique, un choix entre valeur de
retour ou exception ne se base jamais sur des performances
rélatives (qui dépendrait de toute façon du compilateur, de ce
qu'on fait, et d'un tas d'autres choses). Et ma question n'était
pas si on pourrait construire un programme où les exceptions
étaient plus rapides, mais si tu avais déjà mesurer un programme
réel qui était trop lent avec les valeurs de retour, mais pas
avec les exceptions.

On a chez moi (VC6) des résultats plus serrés,

En passant, d'après ce que j'ai entendu dire, l'implémentation
des exceptions dans VC++ 6 n'était pas des mieux, et qu'elles
avaient bien un coût direct en temps d'exécution même quand
l'exception n'était pas levée. (Avec Sun CC, et je crois g++, le
seul coût direct est en espace. Il peut y avoir des coûts
indirects de performance suite à une perte de localité.)

malgré le paramètre supplémentaire que la solution à base de
valeurs de retour entraîne :

Time without errors : 2.64800 sec
Time with exceptions : 102.900 sec
Time with (no) exceptions : 2.75700 sec
Time with (few) exceptions : 2.75800 sec
Time with return values : 2.86700 sec
Time with (few) return values : 2.60200 sec

En effet, mais chez moi ça donne des résultats pour le moins bizarre ...

Time without errors : 2.04000 sec
Time with exceptions : 90.0000 sec
Time with (no) exceptions : 2.12000 sec <--
Time with (few) exceptions : 2.06000 sec <--
Time with return values : 2.34000 sec
Time with (few) return values : 2.35000 sec

Comment le fait de ne pas lever d'exception peut être plus
lent ? Bizarre ... bizarre ...

Est-ce réproducible ? Fais tourner tes tests une dizaine de
fois, pour avoir une idée des variations aléatoires dans tes
mesures. (Méfie-toi de la granularité. Même si _SC_CLK_TCK est
élevé, ce n'est pas dit que tu en as une granularité
correspondante.)

Méfie-toi aussi des effets de pagination. Faire tourner chaque
test une fois sans compter le temps, pour être certain qu'il est
dans la mémoire principale, et non encore sur disque.

[...]

Bref, il faut regarder les résultats avec des pincettes

C'est en effet très difficile de faire des mesures signifiantes
sur une machines modernes. Entre les effets de cache, les effets
de pagination, et d'autres choses, les différences qu'on veut
mesurer se trouve souvent perdu dans le bruit de fond.

et la seule chose à retenir est :

1 - un bloc try-catch ne coûte rien (ou presque) tant qu'une
exception n'est pas levée

Ça dépend de l'implémentation. Chez Sun, et je crois g++, c'est
vrai. Dans les versions plus anciennes de VC++, j'ai entendu
dire que ce n'est pas le cas.

2 - le coût de lever d'une exception est élevé

Là aussi, ça dépend de l'implémentation. Je pourrais imaginer
une implémentation où le coût n'était pas plus élevé que la
propagation d'un code de retour erroné. Évidemment, dans une
telle implémentation, le coût de base, quand il n'y a pas
d'exception, serait plus élevée.

3 - le coup d'une gestion d'erreur par valeur de retour est
indépendant du fait qu'il y ait une erreur ou non.

J'en conclu quand même que pour des *erreurs*, les exceptions
sont plus efficaces.

Plus ou moin, selon la fréquence et la distance de propagation.
Et l'implémentation.

Je repète : dans la pratique, je n'ai jamais rencontré un cas
où la différence était assez pour qu'elle joue un rôle dans le
choix. Les motivations du choix tiennent toujours de la
lisibilité et de la maintainabilité. Uniquement.

En gros, plus une erreur est fréquentes, et plus il y a de
chances qu'il faut la traiter localement, plus les code de
retour sont indiqués. Plus l'erreur est rare, et plus il y de
chances qu'il faut la propager loins, plus l'exception s'impose.
Ou exactement on tire la ligne est plutôt une question
d'appréciation personnelle, je crois, même s'il doit y avoir un
consensus aux deux extrèmes.

En ce qui concerne la validation du code, il est possible de
vérifier dans les tests que le code de retour est testé, même
sans provoquer l'erreur ; pour vérifier qu'on n'a pas oublié un
try/catch, il faut provoquer l'erreur. Mais à mon avis, un jeu
de tests qui ne provoque pas l'erreur n'est pas complet ; c'est
donc une différence negligeable.

Après, si c'est plus un retour à traiter différemment (i.e.
qqch qui arrive fréquemment), alors une valeur de retour
s'impose.

Mais c'est une autre situation.

Un argument supplémentaire pour les exceptions, évidemment,
c'est la possibilité d'encapsuler plus d'information en ce qui
concerne l'erreur, au moins d'une façon simple.

--
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

Alain Gaillard wrote:

J'utilise VC++ depuis quelque semaines, et je n'y ai pas
trouvé un mode debug non plus.

Et comme tu l'utilises en ligne de commande, ainsi que tu l'as
dit dans un autre post, c'est normal :)

Mais tout le monde n'est pas masochiste comme toi ;) Quelle
idée de ne pas utiliser l'IDE :) Moi j'aime bien utiliser
l'IDE je trouve ça très pratique. Emacs et les makefiles j'ai
passé l'âge.

Le makefile, je ne l'écrit qu'une fois. Pour toute mes
applications. Je n'ai pas à rétrouver mes options chaque fois
que j'ouvre un nouveau projet. Aussi, il n'est écrit qu'une fois
pour toute l'équipe. Du coup, il n'y a pas de risque que
différents membres utilisent des options incompatibles.

Pour la reste, je n'ai pas encore vu ce que m'apporte l'IDE. Un
éditeur qui comprend mieux le C++, peut-être, mais c'est aussi
un éditeur qui n'est disponible que sur une seule plateforme, et
que je ne connais pas. (Je ne suis pas convaincu non plus qu'il
soit mieux que vim ou emacs, mais puisque je ne le connais pas,
je ne peux pas dire.) Et en dehors de l'éditeur, tout ce que
j'ai trouvé dans l'IDE, c'est des restrictions sur ce que je
peux faire. (Mais là aussi, peut-être c'est parce que je ne le
connais pas. D'après ce que j'ai entendu dire, il est possible
d'y integrer des outils du genre ClearCase ou Purify. Elle doit
donc avoir des souplesses que je n'ai pas vu, faute d'avoir
assez régardé.)

Ce "mode debug" ou "configuration debug" si tu préfères est
évidemment une cuisine de l'IDE.

Et c'est où, cette « mode release »

Oh... juste à côté du "mode debug" ;)

Que je n'ai pas trouvé non plus:-).

(Mais je plaisante un peu. Je sais les trouver dans l'IDE.)

J'utilise aussi VC++ 2005, et je ne l'ai pas trouvé.

Tu n'utilises pas VC++ Tu utilises cl 2005, i.e le compilateur
de VC++ 2005 Dans VC++ il y a V qui signifie Visual, ce que
tout le monde comprend comme l'IDE complet :-)

Je croyais qu'on parlait des compilateurs:-). La commande
d'invocation, c'est cl, mais elle se trouve bien sous la
répertoire "Microsoft Visual Studio 8". Donc, VC++.

Le comportement par défaut de VC++, c'est de ne pas définir
NDEBUG.

Le comportement par défaut de VC++ (avec un V comme Visual,
donc, l'IDE) est bien de définir par défaut NDEBUG en "mode
relase" :)

Le compilateur, cl, lui ne définit rien du tout en effet. Sans
doute est-ce ce que ce tu as voulu dire ?

Sans doute. En fait, ce que je voulais dire, surtout, c'est que
tu as ce que tu démandes. Que tu invoques le compilateur à
travers l'IDE, ou depuis la ligne de commande ou un fichier de
make, c'est bien toi qui choisis les options que tu lui passes.

Il est défini dans certaines configurations proposées
par l'IDE.

Ben voilà, on y arrive :)

(Et est-ce que tu as déjà trouvé un
défaut quelconque qui convient sans modification à ton
environement et à ta mode de travailler ?)

Non, en effet.

Ce qui est, en fin de compte, l'essentiel de ce que je voulais
dire. IDE ou ligne de commande, tu dois savoir ce que le
compilateur fait et peut faire, et tu es bien obligé, dans la
pratique, de régarder et de choisir, et non de prendre un défaut
quelconque, que ce soit le défaut du compilateur même, ou un
défaut proposé par l'IDE. Si tu cliques un bouton, sans savoir
ce qu'il fait, c'est bien ta faute, et non celui du compilateur.

--
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

(Je ne suis pas convaincu non plus qu'il
soit mieux que vim ou emacs, mais puisque je ne le connais pas,
je ne peux pas dire.)

Ah si, quand même un peu mieux :-)

quelconque, que ce soit le défaut du compilateur même, ou un
défaut proposé par l'IDE. Si tu cliques un bouton, sans savoir
ce qu'il fait, c'est bien ta faute, et non celui du compilateur.

Incontestablement.

--
Alain

kanze wrote:

Pierre Barbier de Reuille wrote:

Sylvain Togni wrote:

Dans ce cas je teste :
1 - exécution sans gestion d'erreur (Time without errors)
2 - exécution avec exception (chaque appel lance une exception ou
presque)
3 - exécution avec gestion des exception mais sans levée d'exception
4 - avec exception, mais peu d'exceptions sont effectivement levées
5 - erreur par valeurs de retour (pratiquement tous les appels génères
des erreurs)
6 - erreur par valeurs de retour (peu d'erreurs relevées)

Voici les temps que j'obtiens chez moi (compilé avec g++
avec les options par défaut):

Time without errors : 1.28000 sec
Time with exceptions : 89.0000 sec
Time with (no) exceptions : 1.31000 sec
Time with (few) exceptions : 2.03000 sec
Time with return values : 2.33000 sec
Time with (few) return values : 2.34000 sec

La bonne performance du 3 viens du test effectué (i < 0) par
rapport aux autres tests (i%10 == 0 ou i%100000 == 0).

Parmi d'autres choses. Les résultats dépendent beaucoup de
l'implémentation. C'est donc extrèmement difficile à tirer des
conclusions concrètes.

En effet, rien qu'entre g++-linux et g++-cygwin il y a des différences
significatives :/

[...]

En effet, mais chez moi ça donne des résultats pour le moins bizarre ...

Time without errors : 2.04000 sec
Time with exceptions : 90.0000 sec
Time with (no) exceptions : 2.12000 sec <--
Time with (few) exceptions : 2.06000 sec <--
Time with return values : 2.34000 sec
Time with (few) return values : 2.35000 sec

Comment le fait de ne pas lever d'exception peut être plus
lent ? Bizarre ... bizarre ...

Est-ce réproducible ? Fais tourner tes tests une dizaine de
fois, pour avoir une idée des variations aléatoires dans tes
mesures. (Méfie-toi de la granularité. Même si _SC_CLK_TCK est
élevé, ce n'est pas dit que tu en as une granularité
correspondante.)

J'ai toujours l'habitude de lancer plusieurs fois les tests avant d'être
sûr qu'ils soient significatifs ... donc oui, c'est même extrêmement stable.

Méfie-toi aussi des effets de pagination. Faire tourner chaque
test une fois sans compter le temps, pour être certain qu'il est
dans la mémoire principale, et non encore sur disque.

[...]

Je repète : dans la pratique, je n'ai jamais rencontré un cas
où la différence était assez pour qu'elle joue un rôle dans le
choix. Les motivations du choix tiennent toujours de la
lisibilité et de la maintainabilité. Uniquement.

En gros, plus une erreur est fréquentes, et plus il y a de
chances qu'il faut la traiter localement, plus les code de
retour sont indiqués. Plus l'erreur est rare, et plus il y de
chances qu'il faut la propager loins, plus l'exception s'impose.
Ou exactement on tire la ligne est plutôt une question
d'appréciation personnelle, je crois, même s'il doit y avoir un
consensus aux deux extrèmes.

Bref, avec des arguments différents on arrive aux même conclusions ;)
Mais en tout cas, je dois dire que c'est une discussion extrêmement
intéressante et qui n'est, à mon avis, pas assez souvent abordé de façon
objective dans les différents manuels. J'ai vraiment bcp appris dans ce
fil de discussion ...

En ce qui concerne la validation du code, il est possible de
vérifier dans les tests que le code de retour est testé, même
sans provoquer l'erreur ; pour vérifier qu'on n'a pas oublié un
try/catch, il faut provoquer l'erreur. Mais à mon avis, un jeu
de tests qui ne provoque pas l'erreur n'est pas complet ; c'est
donc une différence negligeable.

Après, si c'est plus un retour à traiter différemment (i.e.
qqch qui arrive fréquemment), alors une valeur de retour
s'impose.

Mais c'est une autre situation.

Un argument supplémentaire pour les exceptions, évidemment,
c'est la possibilité d'encapsuler plus d'information en ce qui
concerne l'erreur, au moins d'une façon simple.

--
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 wrote:

"kanze" <kanze@gabi-soft.fr> writes:

[...]

| La seule chose à ajouter, c'est que si tu écris une
| bibliothèque, et tu ne sais pas trop où le client va traiter
| l'erreur, il vaut mieux pécher du côté du code de retour.
| Simplement parce que c'est beaucoup plus facile au client
| d'écrire :
| if ( f() != OK ) throw whatever ;
| que d'écrire :
|
| try {
| f() ;
| } catch ( Whatever& error ) {
| // ...
| }

Je driais exactement l'opposé.

Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs
de scope supplémentaire pour l'appel, que de n'en écrire
qu'une ?

--
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