On Sat, 7 May 2005 12:13:31 +0200, "Etienne Rousee" :
Si je crée deux instances BMC1 et BMC2 de Base_MaClasse
Note que tu ne peux pas créer directement d'instances de cette classe (elles ne sont créées qu'en tant qu'instances de la classe de base que MaClasse).
, l'attribut statique est_premier_appel de chacun des constructeurs ne sera pas le même
Si tu appelles plusieurs fois la fonction f(), tu verras que s'affichera : oui non non non etc.
parce que la variable "est_premier_appel" est static.
Il en va de même si tu remplaces la fonction f() par la fonction Base_MaClasse::Base_MaClasse(). Si j'ai pris la peine de créer une classe de base au lieu de tout mettre dans MaClasse, c'est pour deux raisons : - pour m'assurer qu'il n'y a qu'un seul constructeur - pour m'assurer que InitialisationStatique() sera appelée avant toute autre initialisation (des membres de MaClasse).
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Sat, 7 May 2005 12:13:31 +0200, "Etienne Rousee"
<etienne.rousee@wanadoo.fr>:
Si je crée deux instances BMC1 et BMC2
de Base_MaClasse
Note que tu ne peux pas créer directement d'instances de cette classe
(elles ne sont créées qu'en tant qu'instances de la classe de base que
MaClasse).
, l'attribut statique
est_premier_appel de chacun des constructeurs
ne sera pas le même
Si tu appelles plusieurs fois la fonction f(), tu verras que
s'affichera :
oui
non
non
non
etc.
parce que la variable "est_premier_appel" est static.
Il en va de même si tu remplaces la fonction f() par la fonction
Base_MaClasse::Base_MaClasse().
Si j'ai pris la peine de créer une classe de base au lieu de tout
mettre dans MaClasse, c'est pour deux raisons :
- pour m'assurer qu'il n'y a qu'un seul constructeur
- pour m'assurer que InitialisationStatique() sera appelée avant
toute autre initialisation (des membres de MaClasse).
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Sat, 7 May 2005 12:13:31 +0200, "Etienne Rousee" :
Si je crée deux instances BMC1 et BMC2 de Base_MaClasse
Note que tu ne peux pas créer directement d'instances de cette classe (elles ne sont créées qu'en tant qu'instances de la classe de base que MaClasse).
, l'attribut statique est_premier_appel de chacun des constructeurs ne sera pas le même
Si tu appelles plusieurs fois la fonction f(), tu verras que s'affichera : oui non non non etc.
parce que la variable "est_premier_appel" est static.
Il en va de même si tu remplaces la fonction f() par la fonction Base_MaClasse::Base_MaClasse(). Si j'ai pris la peine de créer une classe de base au lieu de tout mettre dans MaClasse, c'est pour deux raisons : - pour m'assurer qu'il n'y a qu'un seul constructeur - pour m'assurer que InitialisationStatique() sera appelée avant toute autre initialisation (des membres de MaClasse).
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Etienne Rousee
"Fabien LE LEZ" ...
On Sat, 7 May 2005 12:13:31 +0200, "Etienne Rousee" :
Si je crée deux instances BMC1 et BMC2 de Base_MaClasse
Note que tu ne peux pas créer directement d'instances de cette classe (elles ne sont créées qu'en tant qu'instances de la classe de base que MaClasse).
Oui, effectivement.
, l'attribut statique est_premier_appel de chacun des constructeurs ne sera pas le même
Si tu appelles plusieurs fois la fonction f(), tu verras que s'affichera : oui non non non etc.
parce que la variable "est_premier_appel" est static.
Il en va de même si tu remplaces la fonction f() par la fonction Base_MaClasse::Base_MaClasse().
C'est ça le point qui m'avait échappé. Comme quoi j'aurais du commencer par le coder, au lieu de le faire après;)
Si j'ai pris la peine de créer une classe de base au lieu de tout mettre dans MaClasse, c'est pour deux raisons : - pour m'assurer qu'il n'y a qu'un seul constructeur
Ce qui est trompeur, c'est que d'habitude, quand on met le code d'une méthode dans la classe, comme c'est le cas pour le constructeur ici, cette méthode se comporte comme une fonction inline, avec duplication du code à chaque instance.
- pour m'assurer que InitialisationStatique() sera appelée avant toute autre initialisation (des membres de MaClasse).
Ok.
Etienne
"Fabien LE LEZ" <gramster@gramster.com> ...
On Sat, 7 May 2005 12:13:31 +0200, "Etienne Rousee"
<etienne.rousee@wanadoo.fr>:
Si je crée deux instances BMC1 et BMC2
de Base_MaClasse
Note que tu ne peux pas créer directement d'instances de cette classe
(elles ne sont créées qu'en tant qu'instances de la classe de base que
MaClasse).
Oui, effectivement.
, l'attribut statique
est_premier_appel de chacun des constructeurs
ne sera pas le même
Si tu appelles plusieurs fois la fonction f(), tu verras que
s'affichera :
oui
non
non
non
etc.
parce que la variable "est_premier_appel" est static.
Il en va de même si tu remplaces la fonction f() par la fonction
Base_MaClasse::Base_MaClasse().
C'est ça le point qui m'avait échappé.
Comme quoi j'aurais du commencer par le coder, au lieu de le faire après;)
Si j'ai pris la peine de créer une classe de base au lieu de tout
mettre dans MaClasse, c'est pour deux raisons :
- pour m'assurer qu'il n'y a qu'un seul constructeur
Ce qui est trompeur, c'est que d'habitude, quand on met
le code d'une méthode dans la classe, comme c'est le cas
pour le constructeur ici, cette méthode se comporte comme
une fonction inline, avec duplication du code à chaque instance.
- pour m'assurer que InitialisationStatique() sera appelée avant
toute autre initialisation (des membres de MaClasse).
On Sat, 7 May 2005 12:13:31 +0200, "Etienne Rousee" :
Si je crée deux instances BMC1 et BMC2 de Base_MaClasse
Note que tu ne peux pas créer directement d'instances de cette classe (elles ne sont créées qu'en tant qu'instances de la classe de base que MaClasse).
Oui, effectivement.
, l'attribut statique est_premier_appel de chacun des constructeurs ne sera pas le même
Si tu appelles plusieurs fois la fonction f(), tu verras que s'affichera : oui non non non etc.
parce que la variable "est_premier_appel" est static.
Il en va de même si tu remplaces la fonction f() par la fonction Base_MaClasse::Base_MaClasse().
C'est ça le point qui m'avait échappé. Comme quoi j'aurais du commencer par le coder, au lieu de le faire après;)
Si j'ai pris la peine de créer une classe de base au lieu de tout mettre dans MaClasse, c'est pour deux raisons : - pour m'assurer qu'il n'y a qu'un seul constructeur
Ce qui est trompeur, c'est que d'habitude, quand on met le code d'une méthode dans la classe, comme c'est le cas pour le constructeur ici, cette méthode se comporte comme une fonction inline, avec duplication du code à chaque instance.
- pour m'assurer que InitialisationStatique() sera appelée avant toute autre initialisation (des membres de MaClasse).
Ok.
Etienne
James Kanze
Matthieu Moy wrote:
(Bruno Causse) writes:
un initialiseur static java c'est du code :
Class maClass {
//initialiseur static static { //ici du code (comme une methode) .../... //ce code n'a pas besion d'etre appelé explicitement avant la 1er utilisation de la calsse }
.../... //suite de la classe }
Je connaissais pas ça en Java.
En C++, en général, les gens font quelque chose comme
class foo { static int forty_two; ... int init() { ... return 42; } }
int foo::forty_two = foo::init();
Je ne sais pas si il y a quelque chose de plus élégant.
En gros, pour avoir l'équivalent en C++, il faut déclarer et définir une classe embriquée, avec le code voulu dans son constructeur, et puis en déclarer et définir une instance statique de cette classe.
Mais il ne faut pas perdre de vue la différence dans la durée de vie de la classe (et je parle bien ici de la classe même, et non des instances) -- en Java, une classe sera chargée à un moment déterminé dans l'exécution, et c'est alors que cette initialisation statique s'exécute. En C++, on pourrait dire que la classe existe effectivement pendant toute l'exécution du code, étant donné qu'elle est résolue, en quelque sort, lors de l'édition de liens statiques. Et si c'est vrai que l'initialisation du bloc statique, implémenté comme décrit ci-dessus, se fait avant l'entrée dans main (dans les faits ; la norme donne encore moins de garanties), l'ordre des telles initialisations entre elles n'est pas définis.
Ce sont, en somme, deux langages différents, et il ne faut pas chercher trop à faire dans un exactement comment on a fait dans l'autre. Les rares fois que j'ai utilisé des initialisateurs statics de classe en Java, je me serais tiré très bien avec un objet static en C++.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
//initialiseur static
static {
//ici du code (comme une methode)
.../...
//ce code n'a pas besion d'etre appelé explicitement
avant la 1er utilisation de la calsse
}
.../... //suite de la classe
}
Je connaissais pas ça en Java.
En C++, en général, les gens font quelque chose comme
class foo {
static int forty_two;
...
int init() {
...
return 42;
}
}
int foo::forty_two = foo::init();
Je ne sais pas si il y a quelque chose de plus élégant.
En gros, pour avoir l'équivalent en C++, il faut déclarer et
définir une classe embriquée, avec le code voulu dans son
constructeur, et puis en déclarer et définir une instance
statique de cette classe.
Mais il ne faut pas perdre de vue la différence dans la durée de
vie de la classe (et je parle bien ici de la classe même, et non
des instances) -- en Java, une classe sera chargée à un moment
déterminé dans l'exécution, et c'est alors que cette
initialisation statique s'exécute. En C++, on pourrait dire que
la classe existe effectivement pendant toute l'exécution du
code, étant donné qu'elle est résolue, en quelque sort, lors de
l'édition de liens statiques. Et si c'est vrai que
l'initialisation du bloc statique, implémenté comme décrit
ci-dessus, se fait avant l'entrée dans main (dans les faits ; la
norme donne encore moins de garanties), l'ordre des telles
initialisations entre elles n'est pas définis.
Ce sont, en somme, deux langages différents, et il ne faut pas
chercher trop à faire dans un exactement comment on a fait dans
l'autre. Les rares fois que j'ai utilisé des initialisateurs
statics de classe en Java, je me serais tiré très bien avec un
objet static en C++.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
//initialiseur static static { //ici du code (comme une methode) .../... //ce code n'a pas besion d'etre appelé explicitement avant la 1er utilisation de la calsse }
.../... //suite de la classe }
Je connaissais pas ça en Java.
En C++, en général, les gens font quelque chose comme
class foo { static int forty_two; ... int init() { ... return 42; } }
int foo::forty_two = foo::init();
Je ne sais pas si il y a quelque chose de plus élégant.
En gros, pour avoir l'équivalent en C++, il faut déclarer et définir une classe embriquée, avec le code voulu dans son constructeur, et puis en déclarer et définir une instance statique de cette classe.
Mais il ne faut pas perdre de vue la différence dans la durée de vie de la classe (et je parle bien ici de la classe même, et non des instances) -- en Java, une classe sera chargée à un moment déterminé dans l'exécution, et c'est alors que cette initialisation statique s'exécute. En C++, on pourrait dire que la classe existe effectivement pendant toute l'exécution du code, étant donné qu'elle est résolue, en quelque sort, lors de l'édition de liens statiques. Et si c'est vrai que l'initialisation du bloc statique, implémenté comme décrit ci-dessus, se fait avant l'entrée dans main (dans les faits ; la norme donne encore moins de garanties), l'ordre des telles initialisations entre elles n'est pas définis.
Ce sont, en somme, deux langages différents, et il ne faut pas chercher trop à faire dans un exactement comment on a fait dans l'autre. Les rares fois que j'ai utilisé des initialisateurs statics de classe en Java, je me serais tiré très bien avec un objet static en C++.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
