dans une classe Singleton implémentée avec un membre statique Singleton*
m_Instance et une fonction membre statique Singleton* GetInstance() qui
crée le Singleton (avec un new) lors de son premier appel, qui doit avoir
la responsabilité de delete le singleton ?
Merci,
--
Vincent Jacques
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème."
Devise Shadok
On Wed, 28 Jun 2006 19:55:48 +0200, Vincent Jacques :
qui doit avoir la responsabilité de delete le singleton ?
Typiquement, personne. L'objet n'est jamais détruit ; la mémoire est libérée par l'OS à la sortie du programme.
Michael
Fabien LE LEZ wrote in news::
On Wed, 28 Jun 2006 19:55:48 +0200, Vincent Jacques :
qui doit avoir la responsabilité de delete le singleton ?
Typiquement, personne. L'objet n'est jamais détruit ; la mémoire est libérée par l'OS à la sortie du programme.
Néanmoins il existe des solutions, dont une développée par Alexandrescu dans son bouquin sur les patterns, via la fonction std::atexit si j'ai bonne mémoire
Fabien LE LEZ <gramster@gramster.com> wrote in
news:72i5a29b3r55gsgv7a93078flh9h2aepkh@4ax.com:
On Wed, 28 Jun 2006 19:55:48 +0200, Vincent Jacques
<vincent.jacques@student.ecp.fr>:
qui doit avoir
la responsabilité de delete le singleton ?
Typiquement, personne. L'objet n'est jamais détruit ; la mémoire est
libérée par l'OS à la sortie du programme.
Néanmoins il existe des solutions, dont une développée par Alexandrescu dans
son bouquin sur les patterns, via la fonction std::atexit si j'ai bonne
mémoire
On Wed, 28 Jun 2006 19:55:48 +0200, Vincent Jacques :
qui doit avoir la responsabilité de delete le singleton ?
Typiquement, personne. L'objet n'est jamais détruit ; la mémoire est libérée par l'OS à la sortie du programme.
Néanmoins il existe des solutions, dont une développée par Alexandrescu dans son bouquin sur les patterns, via la fonction std::atexit si j'ai bonne mémoire
Hamiral
Michael <michael.at.gmail.dot.com> wrote:
Typiquement, personne. L'objet n'est jamais détruit ; la mémoire est libérée par l'OS à la sortie du programme.
Néanmoins il existe des solutions, dont une développée par Alexandrescu dans son bouquin sur les patterns, via la fonction std::atexit si j'ai bonne mémoire
Cet article trouvé sur le net, peut éventuellement être utile : http://flure.free.fr/dotclear/index.php?2006/04/21/6-static-pimpl-singleton
-- Hamiral
Michael <michael.at.gmail.dot.com> wrote:
Typiquement, personne. L'objet n'est jamais détruit ; la mémoire est
libérée par l'OS à la sortie du programme.
Néanmoins il existe des solutions, dont une développée par Alexandrescu
dans son bouquin sur les patterns, via la fonction std::atexit si j'ai
bonne mémoire
Cet article trouvé sur le net, peut éventuellement être utile :
http://flure.free.fr/dotclear/index.php?2006/04/21/6-static-pimpl-singleton
Typiquement, personne. L'objet n'est jamais détruit ; la mémoire est libérée par l'OS à la sortie du programme.
Néanmoins il existe des solutions, dont une développée par Alexandrescu dans son bouquin sur les patterns, via la fonction std::atexit si j'ai bonne mémoire
Cet article trouvé sur le net, peut éventuellement être utile : http://flure.free.fr/dotclear/index.php?2006/04/21/6-static-pimpl-singleton
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Devise Shadok
kanze
Vincent Jacques wrote:
dans une classe Singleton implémentée avec un membre statique Singleton* m_Instance et une fonction membre statique Singleton* GetInstance() qui crée le Singleton (avec un new) lors de son premier appel, qui doit avoir la responsabilité de delete le singleton ?
Typiquement, personne. On ne veut pas qu'il soit détruit, afin d'être sûr que personne s'en serve après sa destruction (dans le destructeur d'un objet statique, par exemple).
Si ça ne gène pas qu'il soit détruit, la solution classique, c'est de ne pas utiliser de pointeur, et de le déclarer comme variable statique locale :
Du coup, c'est le compilateur qui s'occupe de sa destruction. (Mais attention aux problèmes de thread avec cette solution.)
Sinon, affecter le pointeur à un auto_ptr (ou un boost::shared_ptr) fait aussi l'affaire.
-- James Kanze GABI Software 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
Vincent Jacques wrote:
dans une classe Singleton implémentée avec un membre statique
Singleton* m_Instance et une fonction membre statique
Singleton* GetInstance() qui crée le Singleton (avec un new)
lors de son premier appel, qui doit avoir la responsabilité de
delete le singleton ?
Typiquement, personne. On ne veut pas qu'il soit détruit, afin
d'être sûr que personne s'en serve après sa destruction (dans le
destructeur d'un objet statique, par exemple).
Si ça ne gène pas qu'il soit détruit, la solution classique,
c'est de ne pas utiliser de pointeur, et de le déclarer comme
variable statique locale :
dans une classe Singleton implémentée avec un membre statique Singleton* m_Instance et une fonction membre statique Singleton* GetInstance() qui crée le Singleton (avec un new) lors de son premier appel, qui doit avoir la responsabilité de delete le singleton ?
Typiquement, personne. On ne veut pas qu'il soit détruit, afin d'être sûr que personne s'en serve après sa destruction (dans le destructeur d'un objet statique, par exemple).
Si ça ne gène pas qu'il soit détruit, la solution classique, c'est de ne pas utiliser de pointeur, et de le déclarer comme variable statique locale :
Vincent Jacques wrote: http://flure.free.fr/dotclear/index.php?2006/04/21/6-static-pimpl-singleton
Tiens, une erreur 503, pas courant, ça.
Effectivement ! Ça marchait avant que je poste, puis ça ne marchait plus. Mais il semblerait que tout soit rentré dans l'ordre maintenant ...
Vi. Pas mal, cet article, merci, -- Vincent Jacques
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Devise Shadok
kanze
Vincent Jacques wrote:
Hamiral wrote:
Vincent Jacques wrote: http://flure.free.fr/dotclear/index.php?2006/04/21/6-static-pimpl-singl eton
Tiens, une erreur 503, pas courant, ça.
Effectivement ! Ça marchait avant que je poste, puis ça ne marchait plus. Mais il semblerait que tout soit rentré dans l'ordre maintenant ...
Vi. Pas mal, cet article, merci,
Si je ne me trompe pas, ça correspond à peu près à comment j'implémentais les singletons avant le livre des « Design Patterns ». Sauf que je n'utilisais pas de compteur de référence (et je ne detruisait jamais l'objet même).
Un des principes fondamentaux d'un singleton, c'est qu'il n'est créé qu'une fois, et qu'il existe alors jusqu'à la fin du programme. Ce n'est pas le cas de la solution proposée dans l'article, où son objet (réel) risque d'être créé et detruit souvent. Prenons, par exemple, une des utilisations fréquentes d'un singleton, c'est pour la configuration -- avec la solution proposée, on va probablement créer l'objet une première fois pour lire le fichier de configuration, puis le détruire, puis le créer de nouveau quand on veut lire la configuration.
En somme, c'est bien beau, mais ce n'est pas un singleton.
Aussi : avant le livre, on se servait bien de mes singletons en en définissant une instance. J'utilisais effectivement une variante de l'idiome pimpl, mais avec un pointeur static, et le constructeur qui ne construisait l'objet d'implémentation que si c'était nul. J'ai changé surtout parce que personne ne connaît mon idiome, tandis que dès qu'on voit une classe avec une fonction statique « instance() » et pas de constructeurs publics, on reconnaît un singleton. Et si c'est un peu plus verbieux que ce que je faisais avant, c'est plus « honnête » ; on ne construit pas des « instances » qui n'en sont pas dans les faits.
-- James Kanze GABI Software 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
Vincent Jacques wrote:
Hamiral wrote:
Vincent Jacques wrote:
http://flure.free.fr/dotclear/index.php?2006/04/21/6-static-pimpl-singl eton
Tiens, une erreur 503, pas courant, ça.
Effectivement ! Ça marchait avant que je poste, puis ça ne
marchait plus. Mais il semblerait que tout soit rentré dans
l'ordre maintenant ...
Vi. Pas mal, cet article, merci,
Si je ne me trompe pas, ça correspond à peu près à comment
j'implémentais les singletons avant le livre des « Design
Patterns ». Sauf que je n'utilisais pas de compteur de
référence (et je ne detruisait jamais l'objet même).
Un des principes fondamentaux d'un singleton, c'est qu'il n'est
créé qu'une fois, et qu'il existe alors jusqu'à la fin du
programme. Ce n'est pas le cas de la solution proposée dans
l'article, où son objet (réel) risque d'être créé et detruit
souvent. Prenons, par exemple, une des utilisations fréquentes
d'un singleton, c'est pour la configuration -- avec la solution
proposée, on va probablement créer l'objet une première fois
pour lire le fichier de configuration, puis le détruire, puis le
créer de nouveau quand on veut lire la configuration.
En somme, c'est bien beau, mais ce n'est pas un singleton.
Aussi : avant le livre, on se servait bien de mes singletons en
en définissant une instance. J'utilisais effectivement une
variante de l'idiome pimpl, mais avec un pointeur static, et le
constructeur qui ne construisait l'objet d'implémentation que si
c'était nul. J'ai changé surtout parce que personne ne connaît
mon idiome, tandis que dès qu'on voit une classe avec une
fonction statique « instance() » et pas de constructeurs
publics, on reconnaît un singleton. Et si c'est un peu plus
verbieux que ce que je faisais avant, c'est plus
« honnête » ; on ne construit pas des « instances » qui
n'en sont pas dans les faits.
--
James Kanze GABI Software
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
Vincent Jacques wrote: http://flure.free.fr/dotclear/index.php?2006/04/21/6-static-pimpl-singl eton
Tiens, une erreur 503, pas courant, ça.
Effectivement ! Ça marchait avant que je poste, puis ça ne marchait plus. Mais il semblerait que tout soit rentré dans l'ordre maintenant ...
Vi. Pas mal, cet article, merci,
Si je ne me trompe pas, ça correspond à peu près à comment j'implémentais les singletons avant le livre des « Design Patterns ». Sauf que je n'utilisais pas de compteur de référence (et je ne detruisait jamais l'objet même).
Un des principes fondamentaux d'un singleton, c'est qu'il n'est créé qu'une fois, et qu'il existe alors jusqu'à la fin du programme. Ce n'est pas le cas de la solution proposée dans l'article, où son objet (réel) risque d'être créé et detruit souvent. Prenons, par exemple, une des utilisations fréquentes d'un singleton, c'est pour la configuration -- avec la solution proposée, on va probablement créer l'objet une première fois pour lire le fichier de configuration, puis le détruire, puis le créer de nouveau quand on veut lire la configuration.
En somme, c'est bien beau, mais ce n'est pas un singleton.
Aussi : avant le livre, on se servait bien de mes singletons en en définissant une instance. J'utilisais effectivement une variante de l'idiome pimpl, mais avec un pointeur static, et le constructeur qui ne construisait l'objet d'implémentation que si c'était nul. J'ai changé surtout parce que personne ne connaît mon idiome, tandis que dès qu'on voit une classe avec une fonction statique « instance() » et pas de constructeurs publics, on reconnaît un singleton. Et si c'est un peu plus verbieux que ce que je faisais avant, c'est plus « honnête » ; on ne construit pas des « instances » qui n'en sont pas dans les faits.
-- James Kanze GABI Software 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
kUfa
Comme cite plus haut, je conseille le bouquin "Modern C++ Design" d'Andrei Alexandrescu et les articles associes (il y en a pas mal). Loki (sur sourceforge) possede ses singletons, qui sont tres utiles (sachant que l'ordre de destruction des singletons peut etre defini), enfin a mon avis. Le code n'est pas si difficile a comprendre si tu maitrise les templates.
/k
Comme cite plus haut, je conseille le bouquin "Modern C++ Design"
d'Andrei Alexandrescu et les articles associes (il y en a pas mal).
Loki (sur sourceforge) possede ses singletons, qui sont tres utiles
(sachant que l'ordre de destruction des singletons peut etre defini),
enfin a mon avis. Le code n'est pas si difficile a comprendre si tu
maitrise les templates.
Comme cite plus haut, je conseille le bouquin "Modern C++ Design" d'Andrei Alexandrescu et les articles associes (il y en a pas mal). Loki (sur sourceforge) possede ses singletons, qui sont tres utiles (sachant que l'ordre de destruction des singletons peut etre defini), enfin a mon avis. Le code n'est pas si difficile a comprendre si tu maitrise les templates.
