float quantite; // la variable quantité
a moins que tu traites des fractions d'objets
int quantite;
Et ton boucher, il ne vend le rosbif que par blocs d'un kilo?
float quantite; // la variable quantité
a moins que tu traites des fractions d'objets
int quantite;
Et ton boucher, il ne vend le rosbif que par blocs d'un kilo?
float quantite; // la variable quantité
a moins que tu traites des fractions d'objets
int quantite;
Et ton boucher, il ne vend le rosbif que par blocs d'un kilo?
"Pierre Maurette" a écrit dans le message de
news:Vous êtes monochromatique, Candide.
cohérent ou non ? ça change tout...
"Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de
news: mn.2c067d6278a72a0d.31483@laposte.net...
Vous êtes monochromatique, Candide.
cohérent ou non ? ça change tout...
"Pierre Maurette" a écrit dans le message de
news:Vous êtes monochromatique, Candide.
cohérent ou non ? ça change tout...
Jean-Marc Bourguet wrote:"Laurent Deniau" writes:C'est la que l'approche est differente. Je considere le
code correcte par defaut (parce que debugge et teste ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans
des contextes très différents et que je maîtrise beaucoup
moins ce dont je ne m'occupe pas dans le programme que toi.
C'est fort possible. Je ne suis pas vraiment dans une logique
industrielle, mais plutot R&D.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de
l'utilisateur. Ces vérifications doivent être là quoi qu'il
passe dans la tête d'un CM, de celui qui reprendra le code,
ou des défauts considérés comme adéquats par le fournisseur
du compilateur qu'on utilisera dans le futur. Les
assertions sont pour moi des commentaires dont la validité
est vérifiée à l'exécution, elles ne font pas partie de ce
que le programme est sensé faire. Vérifier les entrées de
l'utilisateur, le programme doit le faire.
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Jean-Marc Bourguet wrote:
"Laurent Deniau" <Laurent.Deniau@gmail.com> writes:
C'est la que l'approche est differente. Je considere le
code correcte par defaut (parce que debugge et teste ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans
des contextes très différents et que je maîtrise beaucoup
moins ce dont je ne m'occupe pas dans le programme que toi.
C'est fort possible. Je ne suis pas vraiment dans une logique
industrielle, mais plutot R&D.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de
l'utilisateur. Ces vérifications doivent être là quoi qu'il
passe dans la tête d'un CM, de celui qui reprendra le code,
ou des défauts considérés comme adéquats par le fournisseur
du compilateur qu'on utilisera dans le futur. Les
assertions sont pour moi des commentaires dont la validité
est vérifiée à l'exécution, elles ne font pas partie de ce
que le programme est sensé faire. Vérifier les entrées de
l'utilisateur, le programme doit le faire.
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Jean-Marc Bourguet wrote:"Laurent Deniau" writes:C'est la que l'approche est differente. Je considere le
code correcte par defaut (parce que debugge et teste ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans
des contextes très différents et que je maîtrise beaucoup
moins ce dont je ne m'occupe pas dans le programme que toi.
C'est fort possible. Je ne suis pas vraiment dans une logique
industrielle, mais plutot R&D.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de
l'utilisateur. Ces vérifications doivent être là quoi qu'il
passe dans la tête d'un CM, de celui qui reprendra le code,
ou des défauts considérés comme adéquats par le fournisseur
du compilateur qu'on utilisera dans le futur. Les
assertions sont pour moi des commentaires dont la validité
est vérifiée à l'exécution, elles ne font pas partie de ce
que le programme est sensé faire. Vérifier les entrées de
l'utilisateur, le programme doit le faire.
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Jean-Marc Bourguet wrote:"Laurent Deniau" writes:OOC supporte seulement l'heritage simple et utilise la delegation de
type pour simuler l'heritage multiple. Un objet est structurellement
valide (du point de vu OOC) juste apres son *allocation* et avant son
initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation
neutre pour le destructeur par l'effet de l'allocation.
Non. Il est structurellement complet, mais pas initialise.J'avais compris desi le constructeur commence par rendre son objet neutre pour
son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme
Exact.il faut que toute la hiérarchie soit dans un état neutre
pour pouvoir appeler le destructeur, j'imaginais une
construction en deux temps.
Jean-Marc Bourguet wrote:
"Laurent Deniau" <Laurent.Deniau@gmail.com> writes:
OOC supporte seulement l'heritage simple et utilise la delegation de
type pour simuler l'heritage multiple. Un objet est structurellement
valide (du point de vu OOC) juste apres son *allocation* et avant son
initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation
neutre pour le destructeur par l'effet de l'allocation.
Non. Il est structurellement complet, mais pas initialise.
J'avais compris de
si le constructeur commence par rendre son objet neutre pour
son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme
Exact.
il faut que toute la hiérarchie soit dans un état neutre
pour pouvoir appeler le destructeur, j'imaginais une
construction en deux temps.
Jean-Marc Bourguet wrote:"Laurent Deniau" writes:OOC supporte seulement l'heritage simple et utilise la delegation de
type pour simuler l'heritage multiple. Un objet est structurellement
valide (du point de vu OOC) juste apres son *allocation* et avant son
initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation
neutre pour le destructeur par l'effet de l'allocation.
Non. Il est structurellement complet, mais pas initialise.J'avais compris desi le constructeur commence par rendre son objet neutre pour
son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme
Exact.il faut que toute la hiérarchie soit dans un état neutre
pour pouvoir appeler le destructeur, j'imaginais une
construction en deux temps.
P'tain, je suis un alien ou quoi, je parle à un réseau de neurones ou
à des humains ?
C'est vraiment pas compliqué, une des facultés d'un code éxécutable,
c'est qu'il va s'exécuter très vite.
Un debugger me permet de tout contrôler de l'exécution du code machine,
à ma vitesse, en avant en arrière, il me montre ce que je fais dans
mon CODE SOURCE (humain quoi), il fait la correspondance, je peux pas
rêver mieux pour comprendre.
Un debogueur, c'est un comprendeur.
cachez ce code-machine que je ne saurais voir : je pense que c'est une
excellente solution pour ne rien comprendre en profondeur.
P'tain, je suis un alien ou quoi, je parle à un réseau de neurones ou
à des humains ?
C'est vraiment pas compliqué, une des facultés d'un code éxécutable,
c'est qu'il va s'exécuter très vite.
Un debugger me permet de tout contrôler de l'exécution du code machine,
à ma vitesse, en avant en arrière, il me montre ce que je fais dans
mon CODE SOURCE (humain quoi), il fait la correspondance, je peux pas
rêver mieux pour comprendre.
Un debogueur, c'est un comprendeur.
cachez ce code-machine que je ne saurais voir : je pense que c'est une
excellente solution pour ne rien comprendre en profondeur.
P'tain, je suis un alien ou quoi, je parle à un réseau de neurones ou
à des humains ?
C'est vraiment pas compliqué, une des facultés d'un code éxécutable,
c'est qu'il va s'exécuter très vite.
Un debugger me permet de tout contrôler de l'exécution du code machine,
à ma vitesse, en avant en arrière, il me montre ce que je fais dans
mon CODE SOURCE (humain quoi), il fait la correspondance, je peux pas
rêver mieux pour comprendre.
Un debogueur, c'est un comprendeur.
cachez ce code-machine que je ne saurais voir : je pense que c'est une
excellente solution pour ne rien comprendre en profondeur.
Laurent Deniau writes:Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
Tu me demandes quel spec il faut a mon avis ou comment
j'implementerais une spec donnee?
Sur la spec, j'en vois plusieurs possibles:
1/ str_len retourne 0 pour str == NULL
Ca me semble raisonnable, j'ai pas d'objections tant que l'ensemble de
la lib fonctionne sur le principe que NULL est un synonyme de "".
2/ str_len retourne -1 + errno pour str == NULL
Je ne vois pas dans quels cas ca peut etre un avantage sur tester la
validite de str avant, mais ca evite d'avoir un comportement indefini
ce est generalement un bien.
3/ str_len retourne par exception pour str == NULL
Exception signifie pour moi traitement non local de l'erreur, je n'en
vois pas de possible pour cette erreur. Certainement pas mon choix.
4/ str != NULL est une precondition.
Attitude classique en C. On peut discuter de l'interet par rapport au
2 dans ce cas particulier, mais en general, c'est difficile d'eviter
d'avoir des preconditions.
1 et 2 imposent l'implementation.
3 je fait test+exception, un assert ne participe pas pour moi a
l'implementation de la spec.
Le 4ieme cas est le plus interessant. Si str est NULL, c'est donc une
erreur de programmation. Face a une erreur de programmation, mon
attitude c'est de sortir le plus vite possible en evitant de faire
croire que tout c'est bien passe, que des resultats sont valides, que
continuer est possible.
Je ne vois pas ce qu'il y a a logger de plus que la pile qu'on optient
avec l'assert-debug.
exit() me gene dans ce cas, c'est un batard entre _exit() qui ne fait
rien et jeter une exception recuperee par le main qui fait non
seulement ce qui est enregisterer par atexit mais aussi le stack
unwinding. Il faudrait que le stack unwinding et l'execution des
atexit soit notifie qu'on est en cas d'erreur de programmation et non
d'un cas prevu.
assert-exception me gene aussi pour la meme raison. Et pour la raison
supplementaire que les exceptions font partie de la spec.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Avec l'avantage d'un error_handler peut aussi demander de ressayer.
Je crois sincerement que c'est le bon choix pour des bibliotheques,
mais je suis surtout utilisateur de celles-ci. Comme je l'ai ecrit,
j'en utilise une qui jette des exceptions quand ses preconditions ne
sont pas verifiees, j'ai un assert sur le catch.
Laurent Deniau <laurent.deniau@cern.ch> writes:
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
Tu me demandes quel spec il faut a mon avis ou comment
j'implementerais une spec donnee?
Sur la spec, j'en vois plusieurs possibles:
1/ str_len retourne 0 pour str == NULL
Ca me semble raisonnable, j'ai pas d'objections tant que l'ensemble de
la lib fonctionne sur le principe que NULL est un synonyme de "".
2/ str_len retourne -1 + errno pour str == NULL
Je ne vois pas dans quels cas ca peut etre un avantage sur tester la
validite de str avant, mais ca evite d'avoir un comportement indefini
ce est generalement un bien.
3/ str_len retourne par exception pour str == NULL
Exception signifie pour moi traitement non local de l'erreur, je n'en
vois pas de possible pour cette erreur. Certainement pas mon choix.
4/ str != NULL est une precondition.
Attitude classique en C. On peut discuter de l'interet par rapport au
2 dans ce cas particulier, mais en general, c'est difficile d'eviter
d'avoir des preconditions.
1 et 2 imposent l'implementation.
3 je fait test+exception, un assert ne participe pas pour moi a
l'implementation de la spec.
Le 4ieme cas est le plus interessant. Si str est NULL, c'est donc une
erreur de programmation. Face a une erreur de programmation, mon
attitude c'est de sortir le plus vite possible en evitant de faire
croire que tout c'est bien passe, que des resultats sont valides, que
continuer est possible.
Je ne vois pas ce qu'il y a a logger de plus que la pile qu'on optient
avec l'assert-debug.
exit() me gene dans ce cas, c'est un batard entre _exit() qui ne fait
rien et jeter une exception recuperee par le main qui fait non
seulement ce qui est enregisterer par atexit mais aussi le stack
unwinding. Il faudrait que le stack unwinding et l'execution des
atexit soit notifie qu'on est en cas d'erreur de programmation et non
d'un cas prevu.
assert-exception me gene aussi pour la meme raison. Et pour la raison
supplementaire que les exceptions font partie de la spec.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Avec l'avantage d'un error_handler peut aussi demander de ressayer.
Je crois sincerement que c'est le bon choix pour des bibliotheques,
mais je suis surtout utilisateur de celles-ci. Comme je l'ai ecrit,
j'en utilise une qui jette des exceptions quand ses preconditions ne
sont pas verifiees, j'ai un assert sur le catch.
Laurent Deniau writes:Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
Tu me demandes quel spec il faut a mon avis ou comment
j'implementerais une spec donnee?
Sur la spec, j'en vois plusieurs possibles:
1/ str_len retourne 0 pour str == NULL
Ca me semble raisonnable, j'ai pas d'objections tant que l'ensemble de
la lib fonctionne sur le principe que NULL est un synonyme de "".
2/ str_len retourne -1 + errno pour str == NULL
Je ne vois pas dans quels cas ca peut etre un avantage sur tester la
validite de str avant, mais ca evite d'avoir un comportement indefini
ce est generalement un bien.
3/ str_len retourne par exception pour str == NULL
Exception signifie pour moi traitement non local de l'erreur, je n'en
vois pas de possible pour cette erreur. Certainement pas mon choix.
4/ str != NULL est une precondition.
Attitude classique en C. On peut discuter de l'interet par rapport au
2 dans ce cas particulier, mais en general, c'est difficile d'eviter
d'avoir des preconditions.
1 et 2 imposent l'implementation.
3 je fait test+exception, un assert ne participe pas pour moi a
l'implementation de la spec.
Le 4ieme cas est le plus interessant. Si str est NULL, c'est donc une
erreur de programmation. Face a une erreur de programmation, mon
attitude c'est de sortir le plus vite possible en evitant de faire
croire que tout c'est bien passe, que des resultats sont valides, que
continuer est possible.
Je ne vois pas ce qu'il y a a logger de plus que la pile qu'on optient
avec l'assert-debug.
exit() me gene dans ce cas, c'est un batard entre _exit() qui ne fait
rien et jeter une exception recuperee par le main qui fait non
seulement ce qui est enregisterer par atexit mais aussi le stack
unwinding. Il faudrait que le stack unwinding et l'execution des
atexit soit notifie qu'on est en cas d'erreur de programmation et non
d'un cas prevu.
assert-exception me gene aussi pour la meme raison. Et pour la raison
supplementaire que les exceptions font partie de la spec.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Avec l'avantage d'un error_handler peut aussi demander de ressayer.
Je crois sincerement que c'est le bon choix pour des bibliotheques,
mais je suis surtout utilisateur de celles-ci. Comme je l'ai ecrit,
j'en utilise une qui jette des exceptions quand ses preconditions ne
sont pas verifiees, j'ai un assert sur le catch.
Je me demande si je ne faisais pas une supposition qui n'est pas
valide. Si une exception est jetee pendant la construction du parent,
est-ce que le constructeur de la classe derivee est appele. Si non,
mon hypothese etait fausse.
Je me demande si je ne faisais pas une supposition qui n'est pas
valide. Si une exception est jetee pendant la construction du parent,
est-ce que le constructeur de la classe derivee est appele. Si non,
mon hypothese etait fausse.
Je me demande si je ne faisais pas une supposition qui n'est pas
valide. Si une exception est jetee pendant la construction du parent,
est-ce que le constructeur de la classe derivee est appele. Si non,
mon hypothese etait fausse.
Par ailleurs, l'intérêt le plus flagrant du C en 2006, c'est sa
portabilité. Et le moyen pour cela, c'est justement de cacher le code
machine.
Par ailleurs, l'intérêt le plus flagrant du C en 2006, c'est sa
portabilité. Et le moyen pour cela, c'est justement de cacher le code
machine.
Par ailleurs, l'intérêt le plus flagrant du C en 2006, c'est sa
portabilité. Et le moyen pour cela, c'est justement de cacher le code
machine.
Jean-Marc Bourguet wrote:Laurent Deniau writes:Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
Tu me demandes quel spec il faut a mon avis ou comment
j'implementerais une spec donnee?
voui.Sur la spec, j'en vois plusieurs possibles:
1/ str_len retourne 0 pour str == NULL
Ca me semble raisonnable, j'ai pas d'objections tant que l'ensemble de
la lib fonctionne sur le principe que NULL est un synonyme de "".
Le genre de chose que j'evite absolument. C'est trop permissif et si toute
la bib est comme ca, debugger peut devenir franchement poilu. Objective-C
dans ses versions permissives qui acceptent d'envoyer un message a nil est
un cas typique que j'evite comme la peste.
2/ str_len retourne -1 + errno pour str == NULL Je ne vois pas
dans quels cas ca peut etre un avantage sur tester la validite de
str avant, mais ca evite d'avoir un comportement indefini ce est
generalement un bien.
Ca c'est la version C canal-historique. Ce n'est pas non plus celle
que je prefere.3/ str_len retourne par exception pour str == NULL
Exception signifie pour moi traitement non local de l'erreur, je n'en
vois pas de possible pour cette erreur. Certainement pas mon choix.
he, he. C'est bien la ma question... Et c'est mon choix pour tout ce qui
releve d'une bib (90% de mon code).4/ str != NULL est une precondition.
Attitude classique en C. On peut discuter de l'interet par rapport au
2 dans ce cas particulier, mais en general, c'est difficile d'eviter
d'avoir des preconditions.
1 et 2 imposent l'implementation.
3 je fait test+exception, un assert ne participe pas pour moi a
l'implementation de la spec.
Le 4ieme cas est le plus interessant. Si str est NULL, c'est donc une
erreur de programmation. Face a une erreur de programmation, mon
attitude c'est de sortir le plus vite possible en evitant de faire
croire que tout c'est bien passe, que des resultats sont valides, que
continuer est possible.
Mais si tu es dans une bib, comment tu sorts? Tu ne sais pas a l'avance
quelles sont les contraintes de l'utilisateur de ta bib.
Ben je vois que tu n'as pas non plus la reponse-qui-va-bien.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Avec l'avantage d'un error_handler peut aussi demander de ressayer.
Je crois sincerement que c'est le bon choix pour des bibliotheques,
mais je suis surtout utilisateur de celles-ci. Comme je l'ai ecrit,
j'en utilise une qui jette des exceptions quand ses preconditions ne
sont pas verifiees, j'ai un assert sur le catch.
Exactement mon cas.
Jean-Marc Bourguet wrote:
Laurent Deniau <laurent.deniau@cern.ch> writes:
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
Tu me demandes quel spec il faut a mon avis ou comment
j'implementerais une spec donnee?
voui.
Sur la spec, j'en vois plusieurs possibles:
1/ str_len retourne 0 pour str == NULL
Ca me semble raisonnable, j'ai pas d'objections tant que l'ensemble de
la lib fonctionne sur le principe que NULL est un synonyme de "".
Le genre de chose que j'evite absolument. C'est trop permissif et si toute
la bib est comme ca, debugger peut devenir franchement poilu. Objective-C
dans ses versions permissives qui acceptent d'envoyer un message a nil est
un cas typique que j'evite comme la peste.
2/ str_len retourne -1 + errno pour str == NULL Je ne vois pas
dans quels cas ca peut etre un avantage sur tester la validite de
str avant, mais ca evite d'avoir un comportement indefini ce est
generalement un bien.
Ca c'est la version C canal-historique. Ce n'est pas non plus celle
que je prefere.
3/ str_len retourne par exception pour str == NULL
Exception signifie pour moi traitement non local de l'erreur, je n'en
vois pas de possible pour cette erreur. Certainement pas mon choix.
he, he. C'est bien la ma question... Et c'est mon choix pour tout ce qui
releve d'une bib (90% de mon code).
4/ str != NULL est une precondition.
Attitude classique en C. On peut discuter de l'interet par rapport au
2 dans ce cas particulier, mais en general, c'est difficile d'eviter
d'avoir des preconditions.
1 et 2 imposent l'implementation.
3 je fait test+exception, un assert ne participe pas pour moi a
l'implementation de la spec.
Le 4ieme cas est le plus interessant. Si str est NULL, c'est donc une
erreur de programmation. Face a une erreur de programmation, mon
attitude c'est de sortir le plus vite possible en evitant de faire
croire que tout c'est bien passe, que des resultats sont valides, que
continuer est possible.
Mais si tu es dans une bib, comment tu sorts? Tu ne sais pas a l'avance
quelles sont les contraintes de l'utilisateur de ta bib.
Ben je vois que tu n'as pas non plus la reponse-qui-va-bien.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Avec l'avantage d'un error_handler peut aussi demander de ressayer.
Je crois sincerement que c'est le bon choix pour des bibliotheques,
mais je suis surtout utilisateur de celles-ci. Comme je l'ai ecrit,
j'en utilise une qui jette des exceptions quand ses preconditions ne
sont pas verifiees, j'ai un assert sur le catch.
Exactement mon cas.
Jean-Marc Bourguet wrote:Laurent Deniau writes:Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
size_t str_len(const char *str)
{
assert(str);
...
}
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug
ou un assert-exception.
Tu me demandes quel spec il faut a mon avis ou comment
j'implementerais une spec donnee?
voui.Sur la spec, j'en vois plusieurs possibles:
1/ str_len retourne 0 pour str == NULL
Ca me semble raisonnable, j'ai pas d'objections tant que l'ensemble de
la lib fonctionne sur le principe que NULL est un synonyme de "".
Le genre de chose que j'evite absolument. C'est trop permissif et si toute
la bib est comme ca, debugger peut devenir franchement poilu. Objective-C
dans ses versions permissives qui acceptent d'envoyer un message a nil est
un cas typique que j'evite comme la peste.
2/ str_len retourne -1 + errno pour str == NULL Je ne vois pas
dans quels cas ca peut etre un avantage sur tester la validite de
str avant, mais ca evite d'avoir un comportement indefini ce est
generalement un bien.
Ca c'est la version C canal-historique. Ce n'est pas non plus celle
que je prefere.3/ str_len retourne par exception pour str == NULL
Exception signifie pour moi traitement non local de l'erreur, je n'en
vois pas de possible pour cette erreur. Certainement pas mon choix.
he, he. C'est bien la ma question... Et c'est mon choix pour tout ce qui
releve d'une bib (90% de mon code).4/ str != NULL est une precondition.
Attitude classique en C. On peut discuter de l'interet par rapport au
2 dans ce cas particulier, mais en general, c'est difficile d'eviter
d'avoir des preconditions.
1 et 2 imposent l'implementation.
3 je fait test+exception, un assert ne participe pas pour moi a
l'implementation de la spec.
Le 4ieme cas est le plus interessant. Si str est NULL, c'est donc une
erreur de programmation. Face a une erreur de programmation, mon
attitude c'est de sortir le plus vite possible en evitant de faire
croire que tout c'est bien passe, que des resultats sont valides, que
continuer est possible.
Mais si tu es dans une bib, comment tu sorts? Tu ne sais pas a l'avance
quelles sont les contraintes de l'utilisateur de ta bib.
Ben je vois que tu n'as pas non plus la reponse-qui-va-bien.
C'est vrai que l'on peut directement se poser la question de
l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus
ou moins brutalement. La question soujacente, c'est quelle classe de
problemes reveles au niveau N peuvent etre resolus au niveau N-P
(P<N)? On a parfois l'impression (c'est parfois mon cas) que les
exceptions servent surtout a se donner bonne conscience a ceux qui
ecrivent des bibliotheques mais que ceux qui les attrapes ne savent
pas trop quoi en faire. Un error_handler est souvent plus simple et
tout aussi efficace.
Avec l'avantage d'un error_handler peut aussi demander de ressayer.
Je crois sincerement que c'est le bon choix pour des bibliotheques,
mais je suis surtout utilisateur de celles-ci. Comme je l'ai ecrit,
j'en utilise une qui jette des exceptions quand ses preconditions ne
sont pas verifiees, j'ai un assert sur le catch.
Exactement mon cas.
Jean-Marc Bourguet wrote:Je me demande si je ne faisais pas une supposition qui n'est pas
valide. Si une exception est jetee pendant la construction du parent,
est-ce que le constructeur de la classe derivee est appele. Si non,
Tu veux dire le destructeur?
mon hypothese etait fausse.
Si tu parles pour C++, la reponse est non. L'objet derive est
incompletement construit, son destructeur ne sera pas appele.
Si tu parles pour OOC, la reponse est oui. Les destructeurs sont
systematiquement appeles. D'ou la necessite de rentre neutre le
parent pour son destructeur avant le debut de l'initialisation des
membres. Concretement, je n'ai vu que la necessite de mettre a NULL
les pointeurs membres, rien de bien mechant.
Jean-Marc Bourguet wrote:
Je me demande si je ne faisais pas une supposition qui n'est pas
valide. Si une exception est jetee pendant la construction du parent,
est-ce que le constructeur de la classe derivee est appele. Si non,
Tu veux dire le destructeur?
mon hypothese etait fausse.
Si tu parles pour C++, la reponse est non. L'objet derive est
incompletement construit, son destructeur ne sera pas appele.
Si tu parles pour OOC, la reponse est oui. Les destructeurs sont
systematiquement appeles. D'ou la necessite de rentre neutre le
parent pour son destructeur avant le debut de l'initialisation des
membres. Concretement, je n'ai vu que la necessite de mettre a NULL
les pointeurs membres, rien de bien mechant.
Jean-Marc Bourguet wrote:Je me demande si je ne faisais pas une supposition qui n'est pas
valide. Si une exception est jetee pendant la construction du parent,
est-ce que le constructeur de la classe derivee est appele. Si non,
Tu veux dire le destructeur?
mon hypothese etait fausse.
Si tu parles pour C++, la reponse est non. L'objet derive est
incompletement construit, son destructeur ne sera pas appele.
Si tu parles pour OOC, la reponse est oui. Les destructeurs sont
systematiquement appeles. D'ou la necessite de rentre neutre le
parent pour son destructeur avant le debut de l'initialisation des
membres. Concretement, je n'ai vu que la necessite de mettre a NULL
les pointeurs membres, rien de bien mechant.