Si tu comptes gérer l'erreur directement dans la fonction, lancer une exception ne sert à rien. Hors debug, je pense qu'on peut faire l'économie d'une vérification au
niveau de cette fonction. Si j'ai bien compris, des séquences de 3 entiers OpCode Operand Operand sont lues et interprétées. C'est au niveau de ce parser qu'il faut décider, et signaler quelque chose du genre: "Erreur OpCode à l'adresse [ligne] xxx" "Erreur à l'adresse [ligne] xxx / Registre hors limites" etc. La fonction pourrait lancer une exception traitée ailleurs, mais je trouve que c'est se compliquer la vie. -- Pierre
Fabien LE LEZ <gramster@gramster.com> a écrit:
[...]
Si tu comptes gérer l'erreur directement dans la fonction, lancer une
exception ne sert à rien.
Hors debug, je pense qu'on peut faire l'économie d'une vérification au
niveau de cette fonction. Si j'ai bien compris, des séquences de 3
entiers OpCode Operand Operand sont lues et interprétées. C'est au
niveau de ce parser qu'il faut décider, et signaler quelque chose du
genre:
"Erreur OpCode à l'adresse [ligne] xxx"
"Erreur à l'adresse [ligne] xxx / Registre hors limites"
etc.
La fonction pourrait lancer une exception traitée ailleurs, mais je
trouve que c'est se compliquer la vie.
--
Pierre
Si tu comptes gérer l'erreur directement dans la fonction, lancer une exception ne sert à rien. Hors debug, je pense qu'on peut faire l'économie d'une vérification au
niveau de cette fonction. Si j'ai bien compris, des séquences de 3 entiers OpCode Operand Operand sont lues et interprétées. C'est au niveau de ce parser qu'il faut décider, et signaler quelque chose du genre: "Erreur OpCode à l'adresse [ligne] xxx" "Erreur à l'adresse [ligne] xxx / Registre hors limites" etc. La fonction pourrait lancer une exception traitée ailleurs, mais je trouve que c'est se compliquer la vie. -- Pierre
Je pensais mettre le tableau comme membre de la classe, au lieu de se traîner les pR0, etc. dans toutes les fonctions membres.
À vrai dire, j'ai fait comme ça parce que je ne sais pas d'où viennent les pR0, etc. en réalité. S'ils sont des données externes, et une donnée du problème, c'est la solution ci-dessus que j'utiliserais. S'il sont propre à ici, et que ce n'est qu'à travers cette fonction qu'on y accède, ils seraient des variables locales statiques aussi, exactement comme la table. Si on doit les utiliser aussi directement dans d'autres contextes, ils pourraient être des variables membres.
Dans tous les cas, je crois que la table serait locale à la fonction. C'est la fonction qui fournit l'interface du mapping. La table n'est qu'un détail de l'implémentation de la fonction.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<45vop01qcafonbg2dn1h1mg8ej3qse07uj@4ax.com>...
On 18 Nov 2004 02:01:50 -0800, kanze@gabi-soft.fr:
Je pensais mettre le tableau comme membre de la classe, au lieu de se
traîner les pR0, etc. dans toutes les fonctions membres.
À vrai dire, j'ai fait comme ça parce que je ne sais pas d'où viennent
les pR0, etc. en réalité. S'ils sont des données externes, et une donnée
du problème, c'est la solution ci-dessus que j'utiliserais. S'il sont
propre à ici, et que ce n'est qu'à travers cette fonction qu'on y
accède, ils seraient des variables locales statiques aussi, exactement
comme la table. Si on doit les utiliser aussi directement dans d'autres
contextes, ils pourraient être des variables membres.
Dans tous les cas, je crois que la table serait locale à la fonction.
C'est la fonction qui fournit l'interface du mapping. La table n'est
qu'un détail de l'implémentation de la fonction.
--
James Kanze GABI Software http://www.gabi-soft.fr
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 pensais mettre le tableau comme membre de la classe, au lieu de se traîner les pR0, etc. dans toutes les fonctions membres.
À vrai dire, j'ai fait comme ça parce que je ne sais pas d'où viennent les pR0, etc. en réalité. S'ils sont des données externes, et une donnée du problème, c'est la solution ci-dessus que j'utiliserais. S'il sont propre à ici, et que ce n'est qu'à travers cette fonction qu'on y accède, ils seraient des variables locales statiques aussi, exactement comme la table. Si on doit les utiliser aussi directement dans d'autres contextes, ils pourraient être des variables membres.
Dans tous les cas, je crois que la table serait locale à la fonction. C'est la fonction qui fournit l'interface du mapping. La table n'est qu'un détail de l'implémentation de la fonction.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Fabien LE LEZ wrote in message news:...
On 18 Nov 2004 02:01:50 -0800, :
Tu n'as aucun moyen d'en être sûr. Le mieux est de lancer une exception en cas de paramètre incorrect.
Si la validité du paramètre est une précondition, une assertion vaut mieux qu'une exception.
Mouais...
D'un autre côté, si jamais la condition s'avère fausse dans un cas tordu et qu'on ne s'en rend compte que chez le client, j'aime autant qu'il ait un message "Telle fonctionnalité a échoué" avec la possibilité de rester dans le programme et de sauvegarder ses données, plutôt qu'un message "assert() failed at line..., vous venez juste de perdre vos modifications".
Ça dépend de l'application. Il m'arrive souvent en fait d'utiliser des « assert » maison, surtout dans les applications client, justement pour avoir un peu de contrôle sur le message d'erreur. Mais pour la reste : si l'assert échoue, c'est que le programme ne marche pas, et les données sont probablement corrompues. Dans ce cas-là, je tiens à faire le moins possible avant de disparaître -- il n'est pas question d'essayer à exécuter des destructeurs en nettoyant la pile, par exemple.
Mais tout dépend de l'application. J'ai l'habitude des applications plus ou moins critiques. Où il y a toujours un système de back-up d'une sort ou d'une autre, qui va réprendre le relai, et où on veut prendre un minimum absolu de risque avec la possibilité des données corrompues.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<37vop0hbj7j9iacomdl70pm37rd34essa3@4ax.com>...
On 18 Nov 2004 02:01:50 -0800, kanze@gabi-soft.fr:
Tu n'as aucun moyen d'en être sûr. Le mieux est de lancer une
exception en cas de paramètre incorrect.
Si la validité du paramètre est une précondition, une assertion vaut
mieux qu'une exception.
Mouais...
D'un autre côté, si jamais la condition s'avère fausse dans un cas
tordu et qu'on ne s'en rend compte que chez le client, j'aime autant
qu'il ait un message "Telle fonctionnalité a échoué" avec la
possibilité de rester dans le programme et de sauvegarder ses données,
plutôt qu'un message "assert() failed at line..., vous venez juste de
perdre vos modifications".
Ça dépend de l'application. Il m'arrive souvent en fait d'utiliser des
« assert » maison, surtout dans les applications client, justement pour
avoir un peu de contrôle sur le message d'erreur. Mais pour la reste :
si l'assert échoue, c'est que le programme ne marche pas, et les données
sont probablement corrompues. Dans ce cas-là, je tiens à faire le moins
possible avant de disparaître -- il n'est pas question d'essayer à
exécuter des destructeurs en nettoyant la pile, par exemple.
Mais tout dépend de l'application. J'ai l'habitude des applications plus
ou moins critiques. Où il y a toujours un système de back-up d'une sort
ou d'une autre, qui va réprendre le relai, et où on veut prendre un
minimum absolu de risque avec la possibilité des données corrompues.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
Tu n'as aucun moyen d'en être sûr. Le mieux est de lancer une exception en cas de paramètre incorrect.
Si la validité du paramètre est une précondition, une assertion vaut mieux qu'une exception.
Mouais...
D'un autre côté, si jamais la condition s'avère fausse dans un cas tordu et qu'on ne s'en rend compte que chez le client, j'aime autant qu'il ait un message "Telle fonctionnalité a échoué" avec la possibilité de rester dans le programme et de sauvegarder ses données, plutôt qu'un message "assert() failed at line..., vous venez juste de perdre vos modifications".
Ça dépend de l'application. Il m'arrive souvent en fait d'utiliser des « assert » maison, surtout dans les applications client, justement pour avoir un peu de contrôle sur le message d'erreur. Mais pour la reste : si l'assert échoue, c'est que le programme ne marche pas, et les données sont probablement corrompues. Dans ce cas-là, je tiens à faire le moins possible avant de disparaître -- il n'est pas question d'essayer à exécuter des destructeurs en nettoyant la pile, par exemple.
Mais tout dépend de l'application. J'ai l'habitude des applications plus ou moins critiques. Où il y a toujours un système de back-up d'une sort ou d'une autre, qui va réprendre le relai, et où on veut prendre un minimum absolu de risque avec la possibilité des données corrompues.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Fabien LE LEZ
On Fri, 19 Nov 2004 10:45:49 +0100, Pierre Maurette :
Hors debug, je pense qu'on peut faire l'économie d'une vérification au niveau de cette fonction. [...] C'est au niveau de ce parser qu'il faut décider
J'ai l'impression qu'on a des points de vue différents. On a ici une fonction qui doit réagir à des arguments. La méthode canonique est de vérifier les arguments, de façon à s'assurer que la fonction renvoie quelque chose de sensé. Si maintenant cette vérification pose des problèmes (par exemple, le profiler indique qu'elle ralentit sensiblement l'exécution du programme), alors seulement on peut se poser la question, et éventuellement supprimer la vérification.
-- ;-)
On Fri, 19 Nov 2004 10:45:49 +0100, Pierre Maurette
<maurettepierre@wanadoo.fr>:
Hors debug, je pense qu'on peut faire l'économie d'une vérification au
niveau de cette fonction. [...]
C'est au niveau de ce parser qu'il faut décider
J'ai l'impression qu'on a des points de vue différents.
On a ici une fonction qui doit réagir à des arguments. La méthode
canonique est de vérifier les arguments, de façon à s'assurer que la
fonction renvoie quelque chose de sensé.
Si maintenant cette vérification pose des problèmes (par exemple, le
profiler indique qu'elle ralentit sensiblement l'exécution du
programme), alors seulement on peut se poser la question, et
éventuellement supprimer la vérification.
On Fri, 19 Nov 2004 10:45:49 +0100, Pierre Maurette :
Hors debug, je pense qu'on peut faire l'économie d'une vérification au niveau de cette fonction. [...] C'est au niveau de ce parser qu'il faut décider
J'ai l'impression qu'on a des points de vue différents. On a ici une fonction qui doit réagir à des arguments. La méthode canonique est de vérifier les arguments, de façon à s'assurer que la fonction renvoie quelque chose de sensé. Si maintenant cette vérification pose des problèmes (par exemple, le profiler indique qu'elle ralentit sensiblement l'exécution du programme), alors seulement on peut se poser la question, et éventuellement supprimer la vérification.
-- ;-)
Fabien LE LEZ
On 19 Nov 2004 02:11:07 -0800, :
J'ai l'habitude des applications plus ou moins critiques. Où il y a toujours un système de back-up d'une sort ou d'une autre
Ça m'aide à comprendre ton point de vue. Je travaille généralement sur des applications "grand public", et la plupart des utilisateurs pensent que le mot "backup" désigne une tribu du Guatemala.
-- ;-)
On 19 Nov 2004 02:11:07 -0800, kanze@gabi-soft.fr:
J'ai l'habitude des applications plus
ou moins critiques. Où il y a toujours un système de back-up d'une sort
ou d'une autre
Ça m'aide à comprendre ton point de vue.
Je travaille généralement sur des applications "grand public", et la
plupart des utilisateurs pensent que le mot "backup" désigne une tribu
du Guatemala.
J'ai l'habitude des applications plus ou moins critiques. Où il y a toujours un système de back-up d'une sort ou d'une autre
Ça m'aide à comprendre ton point de vue. Je travaille généralement sur des applications "grand public", et la plupart des utilisateurs pensent que le mot "backup" désigne une tribu du Guatemala.
-- ;-)
drkm
Fabien LE LEZ writes:
On Thu, 18 Nov 2004 21:57:00 +0100, drkm :
Je ne te suis pas ...
C'est un cas d'école : on a un ensemble de données (ici, un tableau de pointeurs), auquel on ne doit accéder que via une fonction. Dans un tel cas, on met les données et la fonction dans une classe dont la seule fonction est de limiter l'accès aux données.
Bof. Si les éléments sont connus à la compilation et qu'une initialisation de tableau de la sorte :
int & f( int idx ) { static int datas[] = { a , b , ... } ; // ... }
est possible, je ne vois pas l'intérêt. Je vois bien même une TU de la forme :
Type & f( int idx ) { static Type datas[] = { // ... des centaines de valeurs, par exemple générées par un // petit script externe ou fournies par le consortium Unicode } ; // ... }
ou :
Value & f( Key const & k ) { typedef std::map< Key , Value > Map ; static Map::value_type const datas_init[] = { // ... des centaines de valeurs, par exemple générées par un // petit script externe ou fournies par le consortium Unicode } ; static Map const datas( beginOf( datas_init ) , endOf( datas_init ) ) ; // ... }
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
On Thu, 18 Nov 2004 21:57:00 +0100, drkm <usenet.fclcxx@fgeorges.org>:
Je ne te suis pas ...
C'est un cas d'école : on a un ensemble de données (ici, un tableau de
pointeurs), auquel on ne doit accéder que via une fonction. Dans un
tel cas, on met les données et la fonction dans une classe dont la
seule fonction est de limiter l'accès aux données.
Bof. Si les éléments sont connus à la compilation et qu'une
initialisation de tableau de la sorte :
int & f( int idx ) {
static int datas[] = { a , b , ... } ;
// ...
}
est possible, je ne vois pas l'intérêt. Je vois bien même une TU de
la forme :
Type & f( int idx ) {
static Type datas[] = {
// ... des centaines de valeurs, par exemple générées par un
// petit script externe ou fournies par le consortium Unicode
} ;
// ...
}
ou :
Value & f( Key const & k ) {
typedef std::map< Key , Value > Map ;
static Map::value_type const datas_init[] = {
// ... des centaines de valeurs, par exemple générées par un
// petit script externe ou fournies par le consortium Unicode
} ;
static Map const datas(
beginOf( datas_init ) ,
endOf( datas_init )
) ;
// ...
}
C'est un cas d'école : on a un ensemble de données (ici, un tableau de pointeurs), auquel on ne doit accéder que via une fonction. Dans un tel cas, on met les données et la fonction dans une classe dont la seule fonction est de limiter l'accès aux données.
Bof. Si les éléments sont connus à la compilation et qu'une initialisation de tableau de la sorte :
int & f( int idx ) { static int datas[] = { a , b , ... } ; // ... }
est possible, je ne vois pas l'intérêt. Je vois bien même une TU de la forme :
Type & f( int idx ) { static Type datas[] = { // ... des centaines de valeurs, par exemple générées par un // petit script externe ou fournies par le consortium Unicode } ; // ... }
ou :
Value & f( Key const & k ) { typedef std::map< Key , Value > Map ; static Map::value_type const datas_init[] = { // ... des centaines de valeurs, par exemple générées par un // petit script externe ou fournies par le consortium Unicode } ; static Map const datas( beginOf( datas_init ) , endOf( datas_init ) ) ; // ... }
--drkm
drkm
Fabien LE LEZ writes:
On Thu, 18 Nov 2004 20:44:49 +0000, PtitMat :
int lPc; lPc = getPc();
Ce genre de truc, c'est du C. En C++ on écrira plutôt int lPc= getPc();
[...]
int lPc; lPc = getPc();//Prend la valeur de Program Counter
;-)
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
On Thu, 18 Nov 2004 20:44:49 +0000, PtitMat <toto@toto.fr>:
int lPc;
lPc = getPc();
Ce genre de truc, c'est du C. En C++ on écrira plutôt
int lPc= getPc();
[...]
int lPc;
lPc = getPc();//Prend la valeur de Program Counter
