Alors "bool calcule();" ou "bool calcule() const;"?
class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
m->stocke(resultat);
}
Alors "bool calcule();" ou "bool calcule() const;"?
class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
m->stocke(resultat);
}
Alors "bool calcule();" ou "bool calcule() const;"?
class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
m->stocke(resultat);
}
D'une manière générale, si tu peux mettre "const" sans que le
compilateur ne râle, alors mets-le.
D'une manière générale, si tu peux mettre "const" sans que le
compilateur ne râle, alors mets-le.
D'une manière générale, si tu peux mettre "const" sans que le
compilateur ne râle, alors mets-le.
On Fri, 13 Jun 2008 15:43:49 -0700 (PDT), bylybob :Alors "bool calcule();" ou "bool calcule() const;"?
D'une manière générale, si tu peux mettre "const" sans que le
compilateur ne râle, alors mets-le.
La question se pose parfois quand rajouter "const" oblige à utiliser
"mutable", mais ce n'est pas le cas ici.class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
m->stocke(resultat);
}
Ici, la situation est claire : "calculateur" est une classe à qui
l'utilisateur donne l'autorisation de modifier le paramètre passé au
constructeur. L'objet de type "maillage" n'appartient pas à
"calculateur" ; le membre de "calculateur" est un pointeur passé par
le code utilisateur. Ainsi, sémantiquement parlant, une modification
de *m n'implique pas une modification de l'objet "calculateur".
On Fri, 13 Jun 2008 15:43:49 -0700 (PDT), bylybob <byly...@gmail.com>:
Alors "bool calcule();" ou "bool calcule() const;"?
D'une manière générale, si tu peux mettre "const" sans que le
compilateur ne râle, alors mets-le.
La question se pose parfois quand rajouter "const" oblige à utiliser
"mutable", mais ce n'est pas le cas ici.
class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
m->stocke(resultat);
}
Ici, la situation est claire : "calculateur" est une classe à qui
l'utilisateur donne l'autorisation de modifier le paramètre passé au
constructeur. L'objet de type "maillage" n'appartient pas à
"calculateur" ; le membre de "calculateur" est un pointeur passé par
le code utilisateur. Ainsi, sémantiquement parlant, une modification
de *m n'implique pas une modification de l'objet "calculateur".
On Fri, 13 Jun 2008 15:43:49 -0700 (PDT), bylybob :Alors "bool calcule();" ou "bool calcule() const;"?
D'une manière générale, si tu peux mettre "const" sans que le
compilateur ne râle, alors mets-le.
La question se pose parfois quand rajouter "const" oblige à utiliser
"mutable", mais ce n'est pas le cas ici.class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
m->stocke(resultat);
}
Ici, la situation est claire : "calculateur" est une classe à qui
l'utilisateur donne l'autorisation de modifier le paramètre passé au
constructeur. L'objet de type "maillage" n'appartient pas à
"calculateur" ; le membre de "calculateur" est un pointeur passé par
le code utilisateur. Ainsi, sémantiquement parlant, une modification
de *m n'implique pas une modification de l'objet "calculateur".
On Jun 13, 4:23 pm, Fabien LE LEZ wrote:On Fri, 13 Jun 2008 15:43:49 -0700 (PDT), bylybob :
Mon doute venait du probleme d'interface suivant:
class calculateur_abstrait {
public:
maillage* get_maillage();
const maillage* get_maillage() const;
bool calcule() const {
// Check pre-condition(s)
bool ok = do_calcule();
// Check post-condition(s)
}
protected:
calculateur_abstrait(maillage* m, <parametre de calcul...>);
virtual bool do_calcule() const = 0;
};
class calculateur_concret : public calculateur_abstrait {
public:
calculateur_concret(maillage* m, <parametre de calcul...>);
virtual bool do_calcule() const {
// Calcule des trucs...
get_maillage()->stocke(resultat); // Pas possible, appel
"get_maillage() const" renvoie un "const maillage*"
//...
}
};
Comment resoudriez vous le probleme?
On Jun 13, 4:23 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Fri, 13 Jun 2008 15:43:49 -0700 (PDT), bylybob <byly...@gmail.com>:
Mon doute venait du probleme d'interface suivant:
class calculateur_abstrait {
public:
maillage* get_maillage();
const maillage* get_maillage() const;
bool calcule() const {
// Check pre-condition(s)
bool ok = do_calcule();
// Check post-condition(s)
}
protected:
calculateur_abstrait(maillage* m, <parametre de calcul...>);
virtual bool do_calcule() const = 0;
};
class calculateur_concret : public calculateur_abstrait {
public:
calculateur_concret(maillage* m, <parametre de calcul...>);
virtual bool do_calcule() const {
// Calcule des trucs...
get_maillage()->stocke(resultat); // Pas possible, appel
"get_maillage() const" renvoie un "const maillage*"
//...
}
};
Comment resoudriez vous le probleme?
On Jun 13, 4:23 pm, Fabien LE LEZ wrote:On Fri, 13 Jun 2008 15:43:49 -0700 (PDT), bylybob :
Mon doute venait du probleme d'interface suivant:
class calculateur_abstrait {
public:
maillage* get_maillage();
const maillage* get_maillage() const;
bool calcule() const {
// Check pre-condition(s)
bool ok = do_calcule();
// Check post-condition(s)
}
protected:
calculateur_abstrait(maillage* m, <parametre de calcul...>);
virtual bool do_calcule() const = 0;
};
class calculateur_concret : public calculateur_abstrait {
public:
calculateur_concret(maillage* m, <parametre de calcul...>);
virtual bool do_calcule() const {
// Calcule des trucs...
get_maillage()->stocke(resultat); // Pas possible, appel
"get_maillage() const" renvoie un "const maillage*"
//...
}
};
Comment resoudriez vous le probleme?
Bonjour a tous, je suis pris d'un doute sur le bon usage du
qualificateur "const" pour les fonctions membres dans certains
cas particuliers: objects transitoires dont le but est
simplement de calculer des informations sur un autre object.
Prenons l'exemple de calcul scientifique, typiquement il y a
un "maillage" (par exemple un ensemble de triangles munis de
proprietes geometriques et mecaniques) et un "calculateur"
(par exemple elements finis munis de parametres de calculs).
Le "calculateur" calcule (!) et stocke les resultats sur la
grille.
Le "calculateur" a naturellement une fonction "bool
calcule();" qui ne change pas les parametres de calcul mais va
rajouter certainnes proprietes (le resultat du calcul) sur le
maillage.
Alors "bool calcule();" ou "bool calcule() const;"?
class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
//- Calcule des trucs...
m->stocke(resultat);
//...
}
private:
struct Impl; // Details
//...
};
Bonjour a tous, je suis pris d'un doute sur le bon usage du
qualificateur "const" pour les fonctions membres dans certains
cas particuliers: objects transitoires dont le but est
simplement de calculer des informations sur un autre object.
Prenons l'exemple de calcul scientifique, typiquement il y a
un "maillage" (par exemple un ensemble de triangles munis de
proprietes geometriques et mecaniques) et un "calculateur"
(par exemple elements finis munis de parametres de calculs).
Le "calculateur" calcule (!) et stocke les resultats sur la
grille.
Le "calculateur" a naturellement une fonction "bool
calcule();" qui ne change pas les parametres de calcul mais va
rajouter certainnes proprietes (le resultat du calcul) sur le
maillage.
Alors "bool calcule();" ou "bool calcule() const;"?
class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
//- Calcule des trucs...
m->stocke(resultat);
//...
}
private:
struct Impl; // Details
//...
};
Bonjour a tous, je suis pris d'un doute sur le bon usage du
qualificateur "const" pour les fonctions membres dans certains
cas particuliers: objects transitoires dont le but est
simplement de calculer des informations sur un autre object.
Prenons l'exemple de calcul scientifique, typiquement il y a
un "maillage" (par exemple un ensemble de triangles munis de
proprietes geometriques et mecaniques) et un "calculateur"
(par exemple elements finis munis de parametres de calculs).
Le "calculateur" calcule (!) et stocke les resultats sur la
grille.
Le "calculateur" a naturellement une fonction "bool
calcule();" qui ne change pas les parametres de calcul mais va
rajouter certainnes proprietes (le resultat du calcul) sur le
maillage.
Alors "bool calcule();" ou "bool calcule() const;"?
class calculateur {
public:
calculateur(maillage* m, <parametre de calcul...>);
bool calcule() const { // Const ou pas const?
//- Calcule des trucs...
m->stocke(resultat);
//...
}
private:
struct Impl; // Details
//...
};
Maillage::calcule( Calculateur /* const? */ & calc ) ;
[...] (C'est peut-être
ce dilemme qui a amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
Maillage::calcule( Calculateur /* const? */ & calc ) ;
[...] (C'est peut-être
ce dilemme qui a amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
Maillage::calcule( Calculateur /* const? */ & calc ) ;
[...] (C'est peut-être
ce dilemme qui a amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
:
[...]
La question de l'op était de savoir si Calculateur::calcule()
devait être const ou pas. Et cette question a une réponse exacte:
soit calcule() modifie l'état observable de l'objet Calculateur,
soit elle ne la modifie pas.
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:
[...]
La question de l'op était de savoir si Calculateur::calcule()
devait être const ou pas. Et cette question a une réponse exacte:
soit calcule() modifie l'état observable de l'objet Calculateur,
soit elle ne la modifie pas.
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
:
[...]
La question de l'op était de savoir si Calculateur::calcule()
devait être const ou pas. Et cette question a une réponse exacte:
soit calcule() modifie l'état observable de l'objet Calculateur,
soit elle ne la modifie pas.
A ce propos, questions subsidiaires aux experts:
J'ai trouvé dans des grammaires BNF que mutable est un
storage-qualifier et pas un type-modifier ?
Il ne serait donc pas vraiment le contraire de const ?
Pourtant je l'utilise exclusivement dans ce sens et avec succès...
Il est vrai (c'est la seconde question) que j'expérimente ceci:
J'aime bien formuler mes déclarations en plaçant les
type-modifiers systématiquement à droite, plutôt qu'à gauche pour le
premier. Donc ils ne sont jamais mêlés aux
storage-qualifiers.
Ca se passe très bien *a priori* et je trouve que ce schéma systématique est
plus logique (et facilite la génération automatique de code):
plutôt que:
const int ki;
const int * const kpki;
int * const * const kpkpi;
je préfère:
int const ki;
int const * const kpki;
int * const * const kpkpi;
Y a-t-il des compilos modernes que ça peut gêner ?
A ce propos, questions subsidiaires aux experts:
J'ai trouvé dans des grammaires BNF que mutable est un
storage-qualifier et pas un type-modifier ?
Il ne serait donc pas vraiment le contraire de const ?
Pourtant je l'utilise exclusivement dans ce sens et avec succès...
Il est vrai (c'est la seconde question) que j'expérimente ceci:
J'aime bien formuler mes déclarations en plaçant les
type-modifiers systématiquement à droite, plutôt qu'à gauche pour le
premier. Donc ils ne sont jamais mêlés aux
storage-qualifiers.
Ca se passe très bien *a priori* et je trouve que ce schéma systématique est
plus logique (et facilite la génération automatique de code):
plutôt que:
const int ki;
const int * const kpki;
int * const * const kpkpi;
je préfère:
int const ki;
int const * const kpki;
int * const * const kpkpi;
Y a-t-il des compilos modernes que ça peut gêner ?
A ce propos, questions subsidiaires aux experts:
J'ai trouvé dans des grammaires BNF que mutable est un
storage-qualifier et pas un type-modifier ?
Il ne serait donc pas vraiment le contraire de const ?
Pourtant je l'utilise exclusivement dans ce sens et avec succès...
Il est vrai (c'est la seconde question) que j'expérimente ceci:
J'aime bien formuler mes déclarations en plaçant les
type-modifiers systématiquement à droite, plutôt qu'à gauche pour le
premier. Donc ils ne sont jamais mêlés aux
storage-qualifiers.
Ca se passe très bien *a priori* et je trouve que ce schéma systématique est
plus logique (et facilite la génération automatique de code):
plutôt que:
const int ki;
const int * const kpki;
int * const * const kpkpi;
je préfère:
int const ki;
int const * const kpki;
int * const * const kpkpi;
Y a-t-il des compilos modernes que ça peut gêner ?
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
:Maillage::calcule( Calculateur /* const? */ & calc ) ;
[...] (C'est peut-être
ce dilemme qui a amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
Il me semble qu'on est assez loin du problème initial. Ton
Maillage::calcule, de même que for_each ou accumulate, peut
très bien appeler une fonction membre de Calculateur plusieurs
fois. Et effectivement, avoir un état peut s'avérer utile.
La question de l'op était de savoir si Calculateur::calcule()
devait être const ou pas. Et cette question a une réponse
exacte : soit calcule() modifie l'état observable de l'objet
Calculateur, soit elle ne la modifie pas.
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
<james.ka...@gmail.com>:
Maillage::calcule( Calculateur /* const? */ & calc ) ;
[...] (C'est peut-être
ce dilemme qui a amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
Il me semble qu'on est assez loin du problème initial. Ton
Maillage::calcule, de même que for_each ou accumulate, peut
très bien appeler une fonction membre de Calculateur plusieurs
fois. Et effectivement, avoir un état peut s'avérer utile.
La question de l'op était de savoir si Calculateur::calcule()
devait être const ou pas. Et cette question a une réponse
exacte : soit calcule() modifie l'état observable de l'objet
Calculateur, soit elle ne la modifie pas.
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
:Maillage::calcule( Calculateur /* const? */ & calc ) ;
[...] (C'est peut-être
ce dilemme qui a amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
Il me semble qu'on est assez loin du problème initial. Ton
Maillage::calcule, de même que for_each ou accumulate, peut
très bien appeler une fonction membre de Calculateur plusieurs
fois. Et effectivement, avoir un état peut s'avérer utile.
La question de l'op était de savoir si Calculateur::calcule()
devait être const ou pas. Et cette question a une réponse
exacte : soit calcule() modifie l'état observable de l'objet
Calculateur, soit elle ne la modifie pas.