Bonjour,
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme.
Il peut arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation).
Il me semble normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
J'aimerais connaître la stratégie des uns et des autres face à ce
petit problème.
Solution possible :
Bonjour,
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme.
Il peut arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation).
Il me semble normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
J'aimerais connaître la stratégie des uns et des autres face à ce
petit problème.
Solution possible :
Bonjour,
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme.
Il peut arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation).
Il me semble normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
J'aimerais connaître la stratégie des uns et des autres face à ce
petit problème.
Solution possible :
Pierre Maurette wrote:
Bonjour,
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme.
Il peut arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation).
Il me semble normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
J'aimerais connaître la stratégie des uns et des autres face à ce
petit problème.
Solution possible :
- Encapsuler ces variables dans une (des) classe(s) en les déclarant 'private' ;
- Modification uniquement par des fonctions membres de la classe (peut-être
uniquement le constructeur) ;
- Les accéder par des fonctions membres qualifiées 'const' et qui renvoient
les contenues de ces variables soit par valeur, soit par référence sur 'const'.
Le cas échéant, ces classes devraient être des singletons.
Merci.
Pierre Maurette wrote:
Bonjour,
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme.
Il peut arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation).
Il me semble normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
J'aimerais connaître la stratégie des uns et des autres face à ce
petit problème.
Solution possible :
- Encapsuler ces variables dans une (des) classe(s) en les déclarant 'private' ;
- Modification uniquement par des fonctions membres de la classe (peut-être
uniquement le constructeur) ;
- Les accéder par des fonctions membres qualifiées 'const' et qui renvoient
les contenues de ces variables soit par valeur, soit par référence sur 'const'.
Le cas échéant, ces classes devraient être des singletons.
Merci.
Pierre Maurette wrote:
Bonjour,
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme.
Il peut arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation).
Il me semble normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
J'aimerais connaître la stratégie des uns et des autres face à ce
petit problème.
Solution possible :
- Encapsuler ces variables dans une (des) classe(s) en les déclarant 'private' ;
- Modification uniquement par des fonctions membres de la classe (peut-être
uniquement le constructeur) ;
- Les accéder par des fonctions membres qualifiées 'const' et qui renvoient
les contenues de ces variables soit par valeur, soit par référence sur 'const'.
Le cas échéant, ces classes devraient être des singletons.
Merci.
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme. Il peut arriver que ces
"constantes" soient modifiables "exceptionnellement" par un
utilisateur identifié (on peut alors se ramener au précédent, par
clôture/initialisation). Il me semble normal de conserver le statut
const à ces variables. Pour l'instant, j'utilise quelques cast, et ça
roule.
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme. Il peut arriver que ces
"constantes" soient modifiables "exceptionnellement" par un
utilisateur identifié (on peut alors se ramener au précédent, par
clôture/initialisation). Il me semble normal de conserver le statut
const à ces variables. Pour l'instant, j'utilise quelques cast, et ça
roule.
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme. Il peut arriver que ces
"constantes" soient modifiables "exceptionnellement" par un
utilisateur identifié (on peut alors se ramener au précédent, par
clôture/initialisation). Il me semble normal de conserver le statut
const à ces variables. Pour l'instant, j'utilise quelques cast, et ça
roule.
Pierre Maurette wrote in message
news:...Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme. Il peut arriver que ces
"constantes" soient modifiables "exceptionnellement" par un
utilisateur identifié (on peut alors se ramener au précédent, par
clôture/initialisation). Il me semble normal de conserver le statut
const à ces variables. Pour l'instant, j'utilise quelques cast, et ça
roule.
Je suis curieux comment. Si j'écris :
extern int const i = 0 ;
et j'essaie plus tard à modifier la variable, au moyen de :
const_cast< int& >( i ) = 1 ;
j'ai un comportement indéfini, qui en fait ne marche pas toujours.
Je faisais parfois des trucs comme:
En ce qui concerne les variables initialisées à partir des fichiers de
configuration (.ini ou d'autres -- aussi depuis la registry sous
Windows), j'utilise une classe singleton qui contient la
configuration -- c-à-d que je lis le fichier une fois, et le maintient
dans un std::set (ou un tableau haché). Normalement, l'interface du
singleton ne donne pas d'accès en écriture aux éléments dans ce
tableau ; pour le modifier, il faut appeler une fonction spécial avec le
nom du fichier.
Pour les INI, j'utilise la classe TIniFile (avec l'avantage d'avoir
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<jr6d80d3obj9eudc10gnvt56jhlaq8j52h@4ax.com>...
Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme. Il peut arriver que ces
"constantes" soient modifiables "exceptionnellement" par un
utilisateur identifié (on peut alors se ramener au précédent, par
clôture/initialisation). Il me semble normal de conserver le statut
const à ces variables. Pour l'instant, j'utilise quelques cast, et ça
roule.
Je suis curieux comment. Si j'écris :
extern int const i = 0 ;
et j'essaie plus tard à modifier la variable, au moyen de :
const_cast< int& >( i ) = 1 ;
j'ai un comportement indéfini, qui en fait ne marche pas toujours.
Je faisais parfois des trucs comme:
En ce qui concerne les variables initialisées à partir des fichiers de
configuration (.ini ou d'autres -- aussi depuis la registry sous
Windows), j'utilise une classe singleton qui contient la
configuration -- c-à-d que je lis le fichier une fois, et le maintient
dans un std::set (ou un tableau haché). Normalement, l'interface du
singleton ne donne pas d'accès en écriture aux éléments dans ce
tableau ; pour le modifier, il faut appeler une fonction spécial avec le
nom du fichier.
Pour les INI, j'utilise la classe TIniFile (avec l'avantage d'avoir
Pierre Maurette wrote in message
news:...Il est fréquent que des variables (de tous types) soient initialisées
par la lecture d'un fichier INI par exemple, voire un calcul ou
l'appel d'une fonction en début de programme. Il peut arriver que ces
"constantes" soient modifiables "exceptionnellement" par un
utilisateur identifié (on peut alors se ramener au précédent, par
clôture/initialisation). Il me semble normal de conserver le statut
const à ces variables. Pour l'instant, j'utilise quelques cast, et ça
roule.
Je suis curieux comment. Si j'écris :
extern int const i = 0 ;
et j'essaie plus tard à modifier la variable, au moyen de :
const_cast< int& >( i ) = 1 ;
j'ai un comportement indéfini, qui en fait ne marche pas toujours.
Je faisais parfois des trucs comme:
En ce qui concerne les variables initialisées à partir des fichiers de
configuration (.ini ou d'autres -- aussi depuis la registry sous
Windows), j'utilise une classe singleton qui contient la
configuration -- c-à-d que je lis le fichier une fois, et le maintient
dans un std::set (ou un tableau haché). Normalement, l'interface du
singleton ne donne pas d'accès en écriture aux éléments dans ce
tableau ; pour le modifier, il faut appeler une fonction spécial avec le
nom du fichier.
Pour les INI, j'utilise la classe TIniFile (avec l'avantage d'avoir
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Pierre Maurette wrote:Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
const int tt = 0;
int main()
{
*const_cast<int*>(&tt) = 20;
// ou simplement
//const_cast<int&>(tt) = 21;
return 0;
}
chez moi, ça passe la compilation sans broncher (gcc 3.3.1 Cygwin
sous Windows 2000) - le const_cast est là pour dire au compilo
de la fermer !
Par contre, à l'exécution, ce programme m'affiche "Signal 11"
(sous Linux: "Memory fault") sans qu'il y ait un std::cout
ou printf dedans - magique non ?
1 - Au temps pour moi, les seuls tests "réels" que j'ai fait sont en
Pierre Maurette wrote:
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
const int tt = 0;
int main()
{
*const_cast<int*>(&tt) = 20;
// ou simplement
//const_cast<int&>(tt) = 21;
return 0;
}
chez moi, ça passe la compilation sans broncher (gcc 3.3.1 Cygwin
sous Windows 2000) - le const_cast est là pour dire au compilo
de la fermer !
Par contre, à l'exécution, ce programme m'affiche "Signal 11"
(sous Linux: "Memory fault") sans qu'il y ait un std::cout
ou printf dedans - magique non ?
1 - Au temps pour moi, les seuls tests "réels" que j'ai fait sont en
Pierre Maurette wrote:Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
const int tt = 0;
int main()
{
*const_cast<int*>(&tt) = 20;
// ou simplement
//const_cast<int&>(tt) = 21;
return 0;
}
chez moi, ça passe la compilation sans broncher (gcc 3.3.1 Cygwin
sous Windows 2000) - le const_cast est là pour dire au compilo
de la fermer !
Par contre, à l'exécution, ce programme m'affiche "Signal 11"
(sous Linux: "Memory fault") sans qu'il y ait un std::cout
ou printf dedans - magique non ?
1 - Au temps pour moi, les seuls tests "réels" que j'ai fait sont en
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Dans news:, PierreJe faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Pour être clair et précis : un const_cast qui enlève un
const n'est correct (i.e. pas « undefined ») seulement
si on sait que l'objet n'est pas const au départ.
Voila...
Dans news:q09f80d9lhfh2fcd4rmemmrl5qpm4rjpoh@4ax.com, Pierre
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Pour être clair et précis : un const_cast qui enlève un
const n'est correct (i.e. pas « undefined ») seulement
si on sait que l'objet n'est pas const au départ.
Voila...
Dans news:, PierreJe faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Pour être clair et précis : un const_cast qui enlève un
const n'est correct (i.e. pas « undefined ») seulement
si on sait que l'objet n'est pas const au départ.
Voila...
typa:Pierre Maurette wrote in message
news:...Il est fréquent que des variables (de tous types) soient
initialisées par la lecture d'un fichier INI par exemple, voire un
calcul ou l'appel d'une fonction en début de programme. Il peut
arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation). Il me semble
normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
Je suis curieux comment. Si j'écris :
extern int const i = 0 ;
et j'essaie plus tard à modifier la variable, au moyen de :
const_cast< int& >( i ) = 1 ;
j'ai un comportement indéfini, qui en fait ne marche pas toujours.
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
kanze@gabi-soft.fr typa:
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<jr6d80d3obj9eudc10gnvt56jhlaq8j52h@4ax.com>...
Il est fréquent que des variables (de tous types) soient
initialisées par la lecture d'un fichier INI par exemple, voire un
calcul ou l'appel d'une fonction en début de programme. Il peut
arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation). Il me semble
normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
Je suis curieux comment. Si j'écris :
extern int const i = 0 ;
et j'essaie plus tard à modifier la variable, au moyen de :
const_cast< int& >( i ) = 1 ;
j'ai un comportement indéfini, qui en fait ne marche pas toujours.
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
typa:Pierre Maurette wrote in message
news:...Il est fréquent que des variables (de tous types) soient
initialisées par la lecture d'un fichier INI par exemple, voire un
calcul ou l'appel d'une fonction en début de programme. Il peut
arriver que ces "constantes" soient modifiables
"exceptionnellement" par un utilisateur identifié (on peut alors se
ramener au précédent, par clôture/initialisation). Il me semble
normal de conserver le statut const à ces variables. Pour
l'instant, j'utilise quelques cast, et ça roule.
Je suis curieux comment. Si j'écris :
extern int const i = 0 ;
et j'essaie plus tard à modifier la variable, au moyen de :
const_cast< int& >( i ) = 1 ;
j'ai un comportement indéfini, qui en fait ne marche pas toujours.
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
"Michel Michaud" typa:Dans news:, PierreJe faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Pour être clair et précis : un const_cast qui enlève un
const n'est correct (i.e. pas « undefined ») seulement
si on sait que l'objet n'est pas const au départ.
Voila...
Par exemple, celui-là est correct, je ne l'avais pas posté, parce
qu'un peu gag:
int Nom_a_la_con_pour_ecrire = 123;
const int* P = &Nom_a_la_con_pour_ecrire;
#define Param (*P)
// bla bla
//Param = 5; // Refusé
std::cout << Param << std::endl;
"Michel Michaud" <mm@gdzid.com> typa:
Dans news:q09f80d9lhfh2fcd4rmemmrl5qpm4rjpoh@4ax.com, Pierre
Je faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Pour être clair et précis : un const_cast qui enlève un
const n'est correct (i.e. pas « undefined ») seulement
si on sait que l'objet n'est pas const au départ.
Voila...
Par exemple, celui-là est correct, je ne l'avais pas posté, parce
qu'un peu gag:
int Nom_a_la_con_pour_ecrire = 123;
const int* P = &Nom_a_la_con_pour_ecrire;
#define Param (*P)
// bla bla
//Param = 5; // Refusé
std::cout << Param << std::endl;
"Michel Michaud" typa:Dans news:, PierreJe faisais parfois des trucs comme:
const int tt = 0;
*const_cast<int*>(&tt) = 20;
*(int*)(&tt) = 21;
Ça passe sans avertir sur mes compilos.
Peut-être "par hasard" ? ;-)
Mais peu importe, voir ma réponse au post de Falk.
Pour être clair et précis : un const_cast qui enlève un
const n'est correct (i.e. pas « undefined ») seulement
si on sait que l'objet n'est pas const au départ.
Voila...
Par exemple, celui-là est correct, je ne l'avais pas posté, parce
qu'un peu gag:
int Nom_a_la_con_pour_ecrire = 123;
const int* P = &Nom_a_la_con_pour_ecrire;
#define Param (*P)
// bla bla
//Param = 5; // Refusé
std::cout << Param << std::endl;