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 ?
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 ?
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
:amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
N'était-il pas possible de faire deux versions de chaque
algorithme, une avec passage du foncteur par référence non
const, et une autre avec passage du foncteur par référence
const ?
Accessoirement, le code ci-dessous permet-il de passer une
référence non-const à un algorithme ?
template <class Iter, class Function>
void for_each_reference (Iterfirst if, Iterlast il, Function& f)
{
std::for_each<Iter, Function&> (if, il, f);
}
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
<james.ka...@gmail.com>:
amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
N'était-il pas possible de faire deux versions de chaque
algorithme, une avec passage du foncteur par référence non
const, et une autre avec passage du foncteur par référence
const ?
Accessoirement, le code ci-dessous permet-il de passer une
référence non-const à un algorithme ?
template <class Iter, class Function>
void for_each_reference (Iterfirst if, Iterlast il, Function& f)
{
std::for_each<Iter, Function&> (if, il, f);
}
On Sat, 14 Jun 2008 13:21:47 -0700 (PDT), James Kanze
:amené la STL à passer des objets fonctionnels
par valeur, plutôt que par référence.)
N'était-il pas possible de faire deux versions de chaque
algorithme, une avec passage du foncteur par référence non
const, et une autre avec passage du foncteur par référence
const ?
Accessoirement, le code ci-dessous permet-il de passer une
référence non-const à un algorithme ?
template <class Iter, class Function>
void for_each_reference (Iterfirst if, Iterlast il, Function& f)
{
std::for_each<Iter, Function&> (if, il, f);
}
On Jun 15, 10:47 am, "Patrick 'Zener' Brunet"
wrote:
[...]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 ?
Pas du tout. Il ne s'applique aux objets (membres). On ne
peut pas avoir un pointeur vers un mutable, par exemple
(qui n'aurait évidemment pas de sens, étant donné que si le
pointeur n'est pas pointeur vers const, on peut bien effectuer
des mutations à travers lui).Pourtant je l'utilise exclusivement dans ce sens et avec
succès...
Tu fais des :
int mutable* pMutableInt ;
?
[...]
Il y a bien une différence :
const int* pi ; // C'est l'int qui est const
mutable int* pi ; // C'est le pointeur qui est mutable
[...]
en C original, quelque chose comme :
int const short static unsigned i = 43 ;
est parfaitement légal. (Il me semble avoir lu quelque part
que la présence d'un « storage class », c-à-d le static ici,
en dehors du debut est deprécié. En C ; je ne crois pas
que c'est le cas en C++.)
On Jun 15, 10:47 am, "Patrick 'Zener' Brunet"
<use.link.in.signat...@ddress.invalid> wrote:
[...]
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 ?
Pas du tout. Il ne s'applique aux objets (membres). On ne
peut pas avoir un pointeur vers un mutable, par exemple
(qui n'aurait évidemment pas de sens, étant donné que si le
pointeur n'est pas pointeur vers const, on peut bien effectuer
des mutations à travers lui).
Pourtant je l'utilise exclusivement dans ce sens et avec
succès...
Tu fais des :
int mutable* pMutableInt ;
?
[...]
Il y a bien une différence :
const int* pi ; // C'est l'int qui est const
mutable int* pi ; // C'est le pointeur qui est mutable
[...]
en C original, quelque chose comme :
int const short static unsigned i = 43 ;
est parfaitement légal. (Il me semble avoir lu quelque part
que la présence d'un « storage class », c-à-d le static ici,
en dehors du debut est deprécié. En C ; je ne crois pas
que c'est le cas en C++.)
On Jun 15, 10:47 am, "Patrick 'Zener' Brunet"
wrote:
[...]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 ?
Pas du tout. Il ne s'applique aux objets (membres). On ne
peut pas avoir un pointeur vers un mutable, par exemple
(qui n'aurait évidemment pas de sens, étant donné que si le
pointeur n'est pas pointeur vers const, on peut bien effectuer
des mutations à travers lui).Pourtant je l'utilise exclusivement dans ce sens et avec
succès...
Tu fais des :
int mutable* pMutableInt ;
?
[...]
Il y a bien une différence :
const int* pi ; // C'est l'int qui est const
mutable int* pi ; // C'est le pointeur qui est mutable
[...]
en C original, quelque chose comme :
int const short static unsigned i = 43 ;
est parfaitement légal. (Il me semble avoir lu quelque part
que la présence d'un « storage class », c-à-d le static ici,
en dehors du debut est deprécié. En C ; je ne crois pas
que c'est le cas en C++.)
Mais comme tu le précises:[...]
Il y a bien une différence :
const int* pi ; // C'est l'int qui est const
mutable int* pi ; // C'est le pointeur qui est mutable
Donc on ne peut pas a priori faire le même genre d'acrobaties
qu'avec const:
int * const kpi;
int const * pki;
mais pas (dans une classe):
int * mutable mpi; // passerait comme attendu
int mutable * pmi; // là c'est râté...
Ce qui ne présenterait d'ailleurs qu'un intérêt théorique...
Pour des raisons d'optimisation entre dans les relations
privées entre des classes intimement liées, j'utilise des
accès directs par références, mais là...
Je n'arrive pas à trouver un exemple réaliste dans lequel un
objet aurait à trifouiller ainsi dans un autre à travers un
pointeur ou une référence qui de plus passe outre un modifieur
const.
Donc dans la notation "à droite", mutable ne doit apparaître
qu'à la position la plus à droite, sinon c'est de la
tromperie.
[...]
en C original, quelque chose comme :
int const short static unsigned i = 43 ;
est parfaitement légal. (Il me semble avoir lu quelque part
que la présence d'un « storage class », c-à-d le static ici,
en dehors du debut est deprécié. En C ; je ne crois pas
que c'est le cas en C++.)
C'est limite sabotage tout de même... Si i est persistant,
donc non réinitialisé à chaque appel, il vaut mieux que ça se
voie bien :o)
Mais comme tu le précises:
[...]
Il y a bien une différence :
const int* pi ; // C'est l'int qui est const
mutable int* pi ; // C'est le pointeur qui est mutable
Donc on ne peut pas a priori faire le même genre d'acrobaties
qu'avec const:
int * const kpi;
int const * pki;
mais pas (dans une classe):
int * mutable mpi; // passerait comme attendu
int mutable * pmi; // là c'est râté...
Ce qui ne présenterait d'ailleurs qu'un intérêt théorique...
Pour des raisons d'optimisation entre dans les relations
privées entre des classes intimement liées, j'utilise des
accès directs par références, mais là...
Je n'arrive pas à trouver un exemple réaliste dans lequel un
objet aurait à trifouiller ainsi dans un autre à travers un
pointeur ou une référence qui de plus passe outre un modifieur
const.
Donc dans la notation "à droite", mutable ne doit apparaître
qu'à la position la plus à droite, sinon c'est de la
tromperie.
[...]
en C original, quelque chose comme :
int const short static unsigned i = 43 ;
est parfaitement légal. (Il me semble avoir lu quelque part
que la présence d'un « storage class », c-à-d le static ici,
en dehors du debut est deprécié. En C ; je ne crois pas
que c'est le cas en C++.)
C'est limite sabotage tout de même... Si i est persistant,
donc non réinitialisé à chaque appel, il vaut mieux que ça se
voie bien :o)
Mais comme tu le précises:[...]
Il y a bien une différence :
const int* pi ; // C'est l'int qui est const
mutable int* pi ; // C'est le pointeur qui est mutable
Donc on ne peut pas a priori faire le même genre d'acrobaties
qu'avec const:
int * const kpi;
int const * pki;
mais pas (dans une classe):
int * mutable mpi; // passerait comme attendu
int mutable * pmi; // là c'est râté...
Ce qui ne présenterait d'ailleurs qu'un intérêt théorique...
Pour des raisons d'optimisation entre dans les relations
privées entre des classes intimement liées, j'utilise des
accès directs par références, mais là...
Je n'arrive pas à trouver un exemple réaliste dans lequel un
objet aurait à trifouiller ainsi dans un autre à travers un
pointeur ou une référence qui de plus passe outre un modifieur
const.
Donc dans la notation "à droite", mutable ne doit apparaître
qu'à la position la plus à droite, sinon c'est de la
tromperie.
[...]
en C original, quelque chose comme :
int const short static unsigned i = 43 ;
est parfaitement légal. (Il me semble avoir lu quelque part
que la présence d'un « storage class », c-à-d le static ici,
en dehors du debut est deprécié. En C ; je ne crois pas
que c'est le cas en C++.)
C'est limite sabotage tout de même... Si i est persistant,
donc non réinitialisé à chaque appel, il vaut mieux que ça se
voie bien :o)
Je ne sais pas. J'avoue que les règles ici sont trop compliquées
pour moi.
Je ne sais pas. J'avoue que les règles ici sont trop compliquées
pour moi.
Je ne sais pas. J'avoue que les règles ici sont trop compliquées
pour moi.
Je crois que toute la subtilité se trouve en effet dans cette définition de
"l'état observable", à ne pas confondre avec l'implémentation technique.
[...]
Evidemment le cache est déclaré mutable car techniquement on le fait.
Je crois que toute la subtilité se trouve en effet dans cette définition de
"l'état observable", à ne pas confondre avec l'implémentation technique.
[...]
Evidemment le cache est déclaré mutable car techniquement on le fait.
Je crois que toute la subtilité se trouve en effet dans cette définition de
"l'état observable", à ne pas confondre avec l'implémentation technique.
[...]
Evidemment le cache est déclaré mutable car techniquement on le fait.
Écrire qu'une fonction est "const" est à considérer avant tout comme
de la documentation
Écrire qu'une fonction est "const" est à considérer avant tout comme
de la documentation
Écrire qu'une fonction est "const" est à considérer avant tout comme
de la documentation
