Bonjour
Est ce que vous pouvez me dire ce que fait cette macro svp ? je n'ai pas
trouvé sur le net de description de celle ci
assert(condition)
Merci d'avance
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Pierre Maurette
Marc Boyer
Andre Heinen a écrit :
On Mon, 20 Jun 2005 02:01:56 +0200, nico wrote:
assert(condition)
Ca permet de vérifier une condition et de stopper le programme si la condition est fausse. Généralement utilisé pour du debug/de la prevention de bug :
J'ajoute qu'assert a ceci de particulier qu'elle n'est pas compilée lorsque la macro NDEBUG est définie, ce qui permet d'aisément supprimer les tests (et ainsi accélérer le programme) lorsqu'on compile une version release.
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Andre Heinen <nospam@nospam.invalid> a écrit :
On Mon, 20 Jun 2005 02:01:56 +0200, nico <nospam@spam.fr> wrote:
assert(condition)
Ca permet de vérifier une condition et de stopper le programme si la
condition est fausse. Généralement utilisé pour du debug/de la prevention
de bug :
J'ajoute qu'assert a ceci de particulier qu'elle n'est pas compilée
lorsque la macro NDEBUG est définie, ce qui permet d'aisément
supprimer les tests (et ainsi accélérer le programme) lorsqu'on
compile une version release.
Assert n'est donc à utiliser que pour le débogage, et jamais pour la
détection d'erreurs susceptibles de se produire lors d'une utilisation
normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas
avec la première.
Un assert vérifie qu'une condition ne doit jamais arriver,
ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi
on devrait les enlever en mode release, tant qu'on a pas
montré que ça causait un pb de perf ou qu'on a pas remplacé
assert par un système de log d'erreur plus performant.
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
Ca permet de vérifier une condition et de stopper le programme si la condition est fausse. Généralement utilisé pour du debug/de la prevention de bug :
J'ajoute qu'assert a ceci de particulier qu'elle n'est pas compilée lorsque la macro NDEBUG est définie, ce qui permet d'aisément supprimer les tests (et ainsi accélérer le programme) lorsqu'on compile une version release.
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Andre Heinen
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Andre Heinen a écrit :
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens? Je dis qu'on ne doit utiliser assert que pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour le débogage.
-- 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/
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Andre Heinen <nospam@nospam.invalid> a écrit :
Assert n'est donc à utiliser que pour le débogage, et jamais pour la
détection d'erreurs susceptibles de se produire lors d'une utilisation
normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas
avec la première.
Un assert vérifie qu'une condition ne doit jamais arriver,
ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi
on devrait les enlever en mode release, tant qu'on a pas
montré que ça causait un pb de perf ou qu'on a pas remplacé
assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la
phrase ont le même sens? Je dis qu'on ne doit utiliser assert que
pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour
le débogage.
--
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/
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Andre Heinen a écrit :
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens? Je dis qu'on ne doit utiliser assert que pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour le débogage.
-- 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/
Marc Boyer
Andre Heinen a écrit :
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Andre Heinen a écrit :
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens?
Non, tu distingues deux cas d'erreurs: - celles qui arrivent lors du débugage - celles qui sont susceptibles de se produire en utilisation normales
Si le code que tu produis est d'une telle qualité qu'il se divise en ces deux classes, bravo. 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.
Je dis qu'on ne doit utiliser assert que pour le débogage.
C'est bien ce qui me chagrinne. Surtout avec l'exemple illustratif.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Andre Heinen <nospam@nospam.invalid> a écrit :
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Andre Heinen <nospam@nospam.invalid> a écrit :
Assert n'est donc à utiliser que pour le débogage, et jamais pour la
détection d'erreurs susceptibles de se produire lors d'une utilisation
normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas
avec la première.
Un assert vérifie qu'une condition ne doit jamais arriver,
ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi
on devrait les enlever en mode release, tant qu'on a pas
montré que ça causait un pb de perf ou qu'on a pas remplacé
assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la
phrase ont le même sens?
Non, tu distingues deux cas d'erreurs:
- celles qui arrivent lors du débugage
- celles qui sont susceptibles de se produire en utilisation
normales
Si le code que tu produis est d'une telle qualité qu'il se divise
en ces deux classes, bravo. 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.
Je dis qu'on ne doit utiliser assert que pour le débogage.
C'est bien ce qui me chagrinne. Surtout avec l'exemple
illustratif.
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Andre Heinen a écrit :
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens?
Non, tu distingues deux cas d'erreurs: - celles qui arrivent lors du débugage - celles qui sont susceptibles de se produire en utilisation normales
Si le code que tu produis est d'une telle qualité qu'il se divise en ces deux classes, bravo. 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.
Je dis qu'on ne doit utiliser assert que pour le débogage.
C'est bien ce qui me chagrinne. Surtout avec l'exemple illustratif.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
Pierre Maurette
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens? Je dis qu'on ne doit utiliser assert que pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour le débogage. Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Pierre Maurette
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Assert n'est donc à utiliser que pour le débogage, et jamais pour la
détection d'erreurs susceptibles de se produire lors d'une utilisation
normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas
avec la première.
Un assert vérifie qu'une condition ne doit jamais arriver,
ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi
on devrait les enlever en mode release, tant qu'on a pas
montré que ça causait un pb de perf ou qu'on a pas remplacé
assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la
phrase ont le même sens? Je dis qu'on ne doit utiliser assert que
pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour
le débogage.
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce
moment-là, même si la condition assert-ée n'est pas censée survenir, il
peut être utile d'être modeste et de préférer "au cas où" un
comportement prévisible (abort()) et un message relativement explicite
que le client pourra remonter.
--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens? Je dis qu'on ne doit utiliser assert que pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour le débogage. Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Pierre Maurette
Gabriel Dos Reis
Andre Heinen writes:
| Assert n'est donc à utiliser que pour le débogage, et jamais pour la | détection d'erreurs susceptibles de se produire lors d'une utilisation | normale du programme.
Je ne comprends pas. Tu lui conseillerais de mettre un bouet de sauvetage quand il s'amuse dans une piscine et qu'il l'enlève quand il s'en va en mer ?
-- Gaby
Andre Heinen <nospam@nospam.invalid> writes:
| Assert n'est donc à utiliser que pour le débogage, et jamais pour la
| détection d'erreurs susceptibles de se produire lors d'une utilisation
| normale du programme.
Je ne comprends pas. Tu lui conseillerais de mettre un bouet de
sauvetage quand il s'amuse dans une piscine et qu'il l'enlève quand il
s'en va en mer ?
| Assert n'est donc à utiliser que pour le débogage, et jamais pour la | détection d'erreurs susceptibles de se produire lors d'une utilisation | normale du programme.
Je ne comprends pas. Tu lui conseillerais de mettre un bouet de sauvetage quand il s'amuse dans une piscine et qu'il l'enlève quand il s'en va en mer ?
-- Gaby
Gabriel Dos Reis
"Pierre Maurette" writes:
| > On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer | > wrote: | > | >>> Assert n'est donc à utiliser que pour le débogage, et jamais pour | >>> la | >>> détection d'erreurs susceptibles de se produire lors d'une utilisation | >>> normale du programme. | >> Je suis d'accord avec la deuxième partie de la phrase, mais pas | >> avec la première. | >> Un assert vérifie qu'une condition ne doit jamais arriver, | >> ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on | >> devrait les enlever en mode release, tant qu'on a pas | >> montré que ça causait un pb de perf ou qu'on a pas remplacé | >> assert par un système de log d'erreur plus performant. | > | > Il me semble pourtant que la première et la deuxième partie de la | > phrase ont le même sens? Je dis qu'on ne doit utiliser assert que | > pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour | > le débogage. | Ne peut-on pas laisser du code de déboguage dans une release ? Je veux | dire si un assert ne pose pas de problème de performance. A ce | moment-là, même si la condition assert-ée n'est pas censée survenir, | il peut être utile d'être modeste et de préférer "au cas où" un | comportement prévisible (abort()) et un message relativement explicite | que le client pourra remonter.
| > On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer
| > <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
| >
| >>> Assert n'est donc à utiliser que pour le débogage, et jamais pour
| >>> la
| >>> détection d'erreurs susceptibles de se produire lors d'une utilisation
| >>> normale du programme.
| >> Je suis d'accord avec la deuxième partie de la phrase, mais pas
| >> avec la première.
| >> Un assert vérifie qu'une condition ne doit jamais arriver,
| >> ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on
| >> devrait les enlever en mode release, tant qu'on a pas
| >> montré que ça causait un pb de perf ou qu'on a pas remplacé
| >> assert par un système de log d'erreur plus performant.
| >
| > Il me semble pourtant que la première et la deuxième partie de la
| > phrase ont le même sens? Je dis qu'on ne doit utiliser assert que
| > pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour
| > le débogage.
| Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
| dire si un assert ne pose pas de problème de performance. A ce
| moment-là, même si la condition assert-ée n'est pas censée survenir,
| il peut être utile d'être modeste et de préférer "au cas où" un
| comportement prévisible (abort()) et un message relativement explicite
| que le client pourra remonter.
| > On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer | > wrote: | > | >>> Assert n'est donc à utiliser que pour le débogage, et jamais pour | >>> la | >>> détection d'erreurs susceptibles de se produire lors d'une utilisation | >>> normale du programme. | >> Je suis d'accord avec la deuxième partie de la phrase, mais pas | >> avec la première. | >> Un assert vérifie qu'une condition ne doit jamais arriver, | >> ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on | >> devrait les enlever en mode release, tant qu'on a pas | >> montré que ça causait un pb de perf ou qu'on a pas remplacé | >> assert par un système de log d'erreur plus performant. | > | > Il me semble pourtant que la première et la deuxième partie de la | > phrase ont le même sens? Je dis qu'on ne doit utiliser assert que | > pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour | > le débogage. | Ne peut-on pas laisser du code de déboguage dans une release ? Je veux | dire si un assert ne pose pas de problème de performance. A ce | moment-là, même si la condition assert-ée n'est pas censée survenir, | il peut être utile d'être modeste et de préférer "au cas où" un | comportement prévisible (abort()) et un message relativement explicite | que le client pourra remonter.
Un peu comme Ariane V ? ;-p
-- Gaby
Pierre Maurette
"Pierre Maurette" writes:
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme. Je suis d'accord avec la deuxième partie de la phrase, mais pas
avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens? Je dis qu'on ne doit utiliser assert que pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour le débogage. Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
Un peu comme Ariane V ? ;-p Il suffirait d'un assert parachutiste, non ?
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Assert n'est donc à utiliser que pour le débogage, et jamais pour
la
détection d'erreurs susceptibles de se produire lors d'une utilisation
normale du programme.
Je suis d'accord avec la deuxième partie de la phrase, mais pas
avec la première.
Un assert vérifie qu'une condition ne doit jamais arriver,
ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on
devrait les enlever en mode release, tant qu'on a pas
montré que ça causait un pb de perf ou qu'on a pas remplacé
assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la
phrase ont le même sens? Je dis qu'on ne doit utiliser assert que
pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour
le débogage.
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce
moment-là, même si la condition assert-ée n'est pas censée survenir,
il peut être utile d'être modeste et de préférer "au cas où" un
comportement prévisible (abort()) et un message relativement explicite
que le client pourra remonter.
Un peu comme Ariane V ?
;-p
Il suffirait d'un assert parachutiste, non ?
--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo
On Mon, 20 Jun 2005 14:19:00 +0000 (UTC), Marc Boyer wrote:
Assert n'est donc à utiliser que pour le débogage, et jamais pour la détection d'erreurs susceptibles de se produire lors d'une utilisation normale du programme. Je suis d'accord avec la deuxième partie de la phrase, mais pas
avec la première. Un assert vérifie qu'une condition ne doit jamais arriver, ici, qu'on ne divise jamais par 0. Je ne vois pas pourquoi on devrait les enlever en mode release, tant qu'on a pas montré que ça causait un pb de perf ou qu'on a pas remplacé assert par un système de log d'erreur plus performant.
Il me semble pourtant que la première et la deuxième partie de la phrase ont le même sens? Je dis qu'on ne doit utiliser assert que pour le débogage. Je ne dis pas qu'on ne doit utiliser qu'assert pour le débogage. Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
Un peu comme Ariane V ? ;-p Il suffirait d'un assert parachutiste, non ?
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Pierre Maurette
Pierre Maurette
"Pierre Maurette" writes: [...]
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
Un peu comme Ariane V ? ;-p Plus sérieusement que réponse précédente : j'ai fait un peu
d'automatisme industriel (pas du C++, ni même du C). Les normes de sécurité imposent des redondances, jusqu'au matériel. Je ne serais pas choqué de ce code "inutile": while(BonhommeSousLaPresse) { // Traiter Messages } assert(!BonhommeSousLaPresse); DescendrePresse(!BonhommeSousLaPresse);
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce
moment-là, même si la condition assert-ée n'est pas censée survenir,
il peut être utile d'être modeste et de préférer "au cas où" un
comportement prévisible (abort()) et un message relativement explicite
que le client pourra remonter.
Un peu comme Ariane V ?
;-p
Plus sérieusement que réponse précédente : j'ai fait un peu
d'automatisme industriel (pas du C++, ni même du C). Les normes de
sécurité imposent des redondances, jusqu'au matériel. Je ne serais pas
choqué de ce code "inutile":
while(BonhommeSousLaPresse)
{
// Traiter Messages
}
assert(!BonhommeSousLaPresse);
DescendrePresse(!BonhommeSousLaPresse);
--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
Un peu comme Ariane V ? ;-p Plus sérieusement que réponse précédente : j'ai fait un peu
d'automatisme industriel (pas du C++, ni même du C). Les normes de sécurité imposent des redondances, jusqu'au matériel. Je ne serais pas choqué de ce code "inutile": while(BonhommeSousLaPresse) { // Traiter Messages } assert(!BonhommeSousLaPresse); DescendrePresse(!BonhommeSousLaPresse);
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Pierre Maurette
Pierre Maurette
"Pierre Maurette" writes: [...]
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
Un peu comme Ariane V ? ;-p Plus sérieusement que réponse précédente : j'ai fait un peu d'automatisme
industriel (pas du C++, ni même du C). Les normes de sécurité imposent des redondances, jusqu'au matériel. Je ne serais pas choqué de ce code "inutile": while(BonhommeSousLaPresse) { // Traiter Messages } assert(!BonhommeSousLaPresse); DescendrePresse(!BonhommeSousLaPresse); Pour un langage compilé, ce que je viens d'écrire n'est pas loin d'être
un grosse bêtise. Disons qu'il s'agirait d'une règle de style imposée. Et BonhommeSousLaPresse serait certainement déclaré volatile.
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
dire si un assert ne pose pas de problème de performance. A ce
moment-là, même si la condition assert-ée n'est pas censée survenir,
il peut être utile d'être modeste et de préférer "au cas où" un
comportement prévisible (abort()) et un message relativement explicite
que le client pourra remonter.
Un peu comme Ariane V ? ;-p
Plus sérieusement que réponse précédente : j'ai fait un peu d'automatisme
industriel (pas du C++, ni même du C). Les normes de sécurité imposent des
redondances, jusqu'au matériel. Je ne serais pas choqué de ce code "inutile":
while(BonhommeSousLaPresse)
{
// Traiter Messages
}
assert(!BonhommeSousLaPresse);
DescendrePresse(!BonhommeSousLaPresse);
Pour un langage compilé, ce que je viens d'écrire n'est pas loin d'être
un grosse bêtise. Disons qu'il s'agirait d'une règle de style imposée.
Et BonhommeSousLaPresse serait certainement déclaré volatile.
--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo
Ne peut-on pas laisser du code de déboguage dans une release ? Je veux dire si un assert ne pose pas de problème de performance. A ce moment-là, même si la condition assert-ée n'est pas censée survenir, il peut être utile d'être modeste et de préférer "au cas où" un comportement prévisible (abort()) et un message relativement explicite que le client pourra remonter.
Un peu comme Ariane V ? ;-p Plus sérieusement que réponse précédente : j'ai fait un peu d'automatisme
industriel (pas du C++, ni même du C). Les normes de sécurité imposent des redondances, jusqu'au matériel. Je ne serais pas choqué de ce code "inutile": while(BonhommeSousLaPresse) { // Traiter Messages } assert(!BonhommeSousLaPresse); DescendrePresse(!BonhommeSousLaPresse); Pour un langage compilé, ce que je viens d'écrire n'est pas loin d'être
un grosse bêtise. Disons qu'il s'agirait d'une règle de style imposée. Et BonhommeSousLaPresse serait certainement déclaré volatile.
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
