assert

Andre Heinen <nospam@nospam.invalid> a écrit :

On Mon, 20 Jun 2005 14:58:52 +0000 (UTC), Marc Boyer

Il me semble pourtant que la première et la deuxième partie de la
phrase ont le même sens?

Non,

Heu... si.

Entre ce que tu pensais, ce que tu as écrit, et ce que j'ai compris
je pense qu'il y a eut perte d'information.

- celles qui arrivent lors du débugage

J'ai voulu dire: les bugs.

OK. Mais on a encore des bugs en production alors ?

- celles qui sont susceptibles de se produire en utilisation
normales

J'ai voulu dire: les problèmes qui ne sont pas dûs à une erreur dans
le programme, mais à un problème runtime tel que par exemple une
entrée incorrecte.

Pour moi, ce ne sont pas vraiment des erreurs, surtout dans l'exemple
présenté avec un opérateur humain. Qu'un fichier XML soit corrompu,
je veux bien que ce soit une erreur. Mais qu'un utilisateur dérape
sur son clavier, je n'appelle pas ça une erreur.

Mais je suis moins confiant. Donc, laisser
des tests qui vérifient que le code reste dans un état cohérent,
même en mode release, je ne vois pas ce que ça a de choquant.

Mais moi non plus.

Pierre et Gaby ont eu la même réaction que toi: ça m'étonne. Ai-je
conseillé de retirer ces tests dans les versions release? Ai-je
conseillé d'utiliser assert() plutôt qu'un autre mécanisme?

Dans ta phrase tellle que je l'ai lu, "Assert n'est donc à utiliser
que pour le débogage", oui, ces tests disparraissaient dans la version
release (le débogage et l'exploitation en production étant des
phases à mon sens différentes).

Je n'ai pas du tout voulu déconseiller la mise en place de tests
redondants qui aideront à détecter les derniers bugs lorsque le
programme sera mis en production.

Je suis d'accord avec ton intention.

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?

Jean-Marc Bourguet wrote:

kanze@gabi-soft.fr writes:

Je sais. Et c'est bien là le problème : ce logiciel était
conçu et développé pour l'Ariane IV. Où l'assert servait
bien, et était même nécessaire.

Il n'y a pas d'assert en cause.

Je sais, je sais. Mais en C++, l'équivalent aurait été une
assert (ou trop souvent, simplement rien de tout).

Au choix une exception (mais le nom donne n'est pas une
exception predefinie d'Ada) ou une interruption (le nom est
bon, mais le rapport parlait d'exception).

L'effet, c'était bien l'équivalent d'un échec d'exception en
C++. Mais il ne faut pas perdre de vue non plus que l'analyse
initial du logiciel considérait bien ce qui se passerait dans le
cas de l'exception/l'interruption/l'échec de l'assertion. Il a
été déterminé que dans ce cas-là, le hardware faisait exactement
ce qu'il fallait, et que donc, ce n'était pas la peine de
l'attraper.

Il y a differents problemes. Parmis ceux dont je me souviens:

- on a reutilise un composant sans verifier que les nouvelles
conditions d'utilisation ne sortaient pas de la zone acceptable

C'était le problème principal, à mon avis. Pour faire des
économies, on a décidé d'utiliser le logiciel de l'Ariane IV.
Sans se poser la question si le cahier de charges était
identique.

- on a lance qqch sans faire de tests (alors que lors de la
decision precedente, la justification etait que des problemes
eventuels seraient detectes par les tests)

Une fois qu'on est sur le bon chemin... Tout développement (non
seulement logiciel) doit commencer par l'établissement d'un
cahier de charges. (Ça ne veut pas dire que ce cahier ne peut
pas évoluer par la suite -- sauf dans des systèmes critiques.)
Comment est-ce qu'on va tester si le programme marche si on n'a
même pas défini ce qu'il devait faire.

- on a laisse le malfonctionnement d'un composant dont l'utilite
etait terminee generer la destruction de la fusee

- on a laisse sortir d'un composant en mode production des infos
de debug (sur un bus servant normallement pour des donnees)

Je suis moins sûr sur ces deux derniers. Mais au fond, tout
revient à ne pas avoir établi le cahier de charges, puis avoir
vérifié (ni même posé la question) que le composant logiciel y
était conforme. On l'a utilisé exactement comme si on était dans
un Ariane IV.

C'est un peu comme si on voulait utiliser un compilateur C++
pour compiler des programmes en Ada. Pourquoi pas, après tout.
C'est bien un compilateur, et c'est d'un compilateur dont on a
besoin.

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

kanze@gabi-soft.fr writes:


[...]

| > Il y a differents problemes. Parmis ceux dont je me souviens:
|
| > - on a reutilise un composant sans verifier que les nouvelles
| > conditions d'utilisation ne sortaient pas de la zone acceptable
|
| C'était le problème principal, à mon avis. Pour faire des
| économies, on a décidé d'utiliser le logiciel de l'Ariane IV.
| Sans se poser la question si le cahier de charges était
| identique.
|
| > - on a lance qqch sans faire de tests (alors que lors de la
| > decision precedente, la justification etait que des problemes
| > eventuels seraient detectes par les tests)
|
| Une fois qu'on est sur le bon chemin... Tout développement (non
| seulement logiciel) doit commencer par l'établissement d'un
| cahier de charges. (Ça ne veut pas dire que ce cahier ne peut
| pas évoluer par la suite -- sauf dans des systèmes critiques.)
| Comment est-ce qu'on va tester si le programme marche si on n'a
| même pas défini ce qu'il devait faire.
|
| > - on a laisse le malfonctionnement d'un composant dont l'utilite
| > etait terminee generer la destruction de la fusee
|
| > - on a laisse sortir d'un composant en mode production des infos
| > de debug (sur un bus servant normallement pour des donnees)
|
| Je suis moins sûr sur ces deux derniers. Mais au fond, tout
| revient à ne pas avoir établi le cahier de charges, puis avoir

Il y avait un cachier des charges. On peut discuter de ce qu'il
contenait. Mais il y en avait un. Comme le dit le rapport, on a
effectivement laissé fonctionner un composant (ce qui est à l'origine
de la destruction) dont l'utilité était nada après le lancement.

-- Gaby

On Wed, 22 Jun 2005 06:32:23 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:

Pierre et Gaby ont eu la même réaction que toi: ça m'étonne. Ai-je
conseillé de retirer ces tests dans les versions release? Ai-je
conseillé d'utiliser assert() plutôt qu'un autre mécanisme?

Dans ta phrase tellle que je l'ai lu, "Assert n'est donc à utiliser
que pour le débogage", oui, ces tests disparraissaient dans la version
release (le débogage et l'exploitation en production étant des
phases à mon sens différentes).

Ok, maintenant je te comprends. Ma formulation donnait l'impression
que je conseillais, pour les versions release, de définir NDEBUG et de
supprimer les vérifications.

Mais ce que j'avais voulu dire, c'est que, étant donné la possibilité
de faire disparaître les assertions à la compilation, il ne faut pas
utiliser assert() dans les situations où on veut être certain que le
test sera exécuté. Par exemple, il ne faut pas utiliser

assert(condition);

au lieu de

if ( ! condition) {
std::cerr << "messagen";
abort();
}

Ce n'est pas pareil.

Je suppose que nous sommes maintenant d'accord...

--
André Heinen
Mon e-mail, encodé ROT13: n qbg urvara ng rhebcrnayvax qbg pbz
La FAQ: http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/

Le 22-06-2005, Andre Heinen <nospam@nospam.invalid> a écrit :

On Wed, 22 Jun 2005 06:32:23 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:

Mais ce que j'avais voulu dire, c'est que, étant donné la possibilité
de faire disparaître les assertions à la compilation, il ne faut pas
utiliser assert() dans les situations où on veut être certain que le
test sera exécuté. Par exemple, il ne faut pas utiliser

assert(condition);

au lieu de

if ( ! condition) {
std::cerr << "messagen";
abort();
}

Ce n'est pas pareil.

Je suppose que nous sommes maintenant d'accord...

Tout à fait. Encore qu'on pourrait encore discuter.
Mais c'est vrai qu'il manque un mot pour distinguer
l'erreur de programmation des erreurs 'normales' de
fonctionnement (genre pb E/S). Je crois que dans le
monde de la sécurité, c'est faute vs tolérance, mais
je suis pas sur.

Quoi qu'il en soit, la politique de gestion des
pre/postconditions, fautes et erreurs devraient être
définie assez tôt, et qu'on peut être tenté d'utiliser
assert pour les uns et les autres cas, sans trop se
poser de question.

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?

Le mercredi 22 juin 2005 à 14:41, Gabriel Dos Reis a écrit dans
fr.comp.lang.c++ :

Il y avait un cachier des charges.
^^^^^^

Joli lapsus. Révélateur ?

--
___________ 23/06/2005 10:01:42
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763