je ne veux pas utiliser de donnée membre static comme marqueur pour savoir
une initialisation a eu lieu et tester si c'est le cas dans chaque appel de
constructeur.
j'ai eu l'idée de définir une classe template toute simple qui me permet
d'initialiser facilement des données membres static.
Plus concrètement :-)
voici la définition du modèle (le nom du modèle est un peu exagéré :-))
template<typename T>
class CAutoRun {
public :
CAutoRun(T const& t) { (*t)();}
~CAutoRun() {}
};
typedef CAutoRun<void(*)(void)> auto_run;
dans hpp
class X {
public :
static void init_map(void) { ...}
static std::map<...> objet_map;
};
dans cpp
void une_fonction(void) {
X::init_map();
...
}
auto_run init_static(une_fonction);
nota : X est pour moi une classe template et dans une_fonction, j'initialise
plusieurs modèles en même temps
L'idée est simplement qu'on ne peut pas faire exécuter du code dans cpp,
mais qu'on peut créer des objets "globaux".
Je crée donc un objet qui exécute le code que je veux et il n'est créé
qu'une fois et en plus dans le bon module (je veux dire que l'ordre de
compilation des modules n'a pas d'importance)
Je voudrais avoir votre avis sur le principe de ce modèle.
Est-ce stupide ou courant ?
je ne veux pas utiliser de donnée membre static comme marqueur pour savoir
une initialisation a eu lieu et tester si c'est le cas dans chaque appel de
constructeur.
j'ai eu l'idée de définir une classe template toute simple qui me permet
d'initialiser facilement des données membres static.
Plus concrètement :-)
voici la définition du modèle (le nom du modèle est un peu exagéré :-))
template<typename T>
class CAutoRun {
public :
CAutoRun(T const& t) { (*t)();}
~CAutoRun() {}
};
typedef CAutoRun<void(*)(void)> auto_run;
dans hpp
class X {
public :
static void init_map(void) { ...}
static std::map<...> objet_map;
};
dans cpp
void une_fonction(void) {
X::init_map();
...
}
auto_run init_static(une_fonction);
nota : X est pour moi une classe template et dans une_fonction, j'initialise
plusieurs modèles en même temps
L'idée est simplement qu'on ne peut pas faire exécuter du code dans cpp,
mais qu'on peut créer des objets "globaux".
Je crée donc un objet qui exécute le code que je veux et il n'est créé
qu'une fois et en plus dans le bon module (je veux dire que l'ordre de
compilation des modules n'a pas d'importance)
Je voudrais avoir votre avis sur le principe de ce modèle.
Est-ce stupide ou courant ?
je ne veux pas utiliser de donnée membre static comme marqueur pour savoir
une initialisation a eu lieu et tester si c'est le cas dans chaque appel de
constructeur.
j'ai eu l'idée de définir une classe template toute simple qui me permet
d'initialiser facilement des données membres static.
Plus concrètement :-)
voici la définition du modèle (le nom du modèle est un peu exagéré :-))
template<typename T>
class CAutoRun {
public :
CAutoRun(T const& t) { (*t)();}
~CAutoRun() {}
};
typedef CAutoRun<void(*)(void)> auto_run;
dans hpp
class X {
public :
static void init_map(void) { ...}
static std::map<...> objet_map;
};
dans cpp
void une_fonction(void) {
X::init_map();
...
}
auto_run init_static(une_fonction);
nota : X est pour moi une classe template et dans une_fonction, j'initialise
plusieurs modèles en même temps
L'idée est simplement qu'on ne peut pas faire exécuter du code dans cpp,
mais qu'on peut créer des objets "globaux".
Je crée donc un objet qui exécute le code que je veux et il n'est créé
qu'une fois et en plus dans le bon module (je veux dire que l'ordre de
compilation des modules n'a pas d'importance)
Je voudrais avoir votre avis sur le principe de ce modèle.
Est-ce stupide ou courant ?
Mais j'ai peut-etre raté quelque-chose...
non, tu n'as rien raté
Mais j'ai peut-etre raté quelque-chose...
non, tu n'as rien raté
Mais j'ai peut-etre raté quelque-chose...
non, tu n'as rien raté
Marc G wrote:je ne veux pas utiliser de donnée membre static comme marqueur pour
savoir une initialisation a eu lieu et tester si c'est le cas dans
chaque appel de constructeur.
j'ai eu l'idée de définir une classe template toute simple qui me
permet d'initialiser facilement des données membres static.
Plus concrètement :-)
voici la définition du modèle (le nom du modèle est un peu exagéré :-))
template<typename T>
class CAutoRun {
[snip]
dans hpp
class X {
public :
static void init_map(void) { ...}
static std::map<...> objet_map;
};
dans cpp
void une_fonction(void) {
X::init_map();
...
}
auto_run init_static(une_fonction);
nota : X est pour moi une classe template et dans une_fonction,
j'initialise plusieurs modèles en même temps
L'idée est simplement qu'on ne peut pas faire exécuter du code dans
cpp, mais qu'on peut créer des objets "globaux".
Je crée donc un objet qui exécute le code que je veux et il n'est créé
qu'une fois et en plus dans le bon module (je veux dire que l'ordre de
compilation des modules n'a pas d'importance)
Je voudrais avoir votre avis sur le principe de ce modèle.
Est-ce stupide ou courant ?
Ca ne me semble pas stupide, par contre je ne vois pas tres bien
l'avantage de la classe template CAutoRun vis-a-vis d'une solution
moins elaboree:
// dans cpp:
int une_fonction(void) {
X::init_map();
// ...
return 0;
}
int static_init = une_fonction();
Mais j'ai peut-etre raté quelque-chose...
Marc G wrote:
je ne veux pas utiliser de donnée membre static comme marqueur pour
savoir une initialisation a eu lieu et tester si c'est le cas dans
chaque appel de constructeur.
j'ai eu l'idée de définir une classe template toute simple qui me
permet d'initialiser facilement des données membres static.
Plus concrètement :-)
voici la définition du modèle (le nom du modèle est un peu exagéré :-))
template<typename T>
class CAutoRun {
[snip]
dans hpp
class X {
public :
static void init_map(void) { ...}
static std::map<...> objet_map;
};
dans cpp
void une_fonction(void) {
X::init_map();
...
}
auto_run init_static(une_fonction);
nota : X est pour moi une classe template et dans une_fonction,
j'initialise plusieurs modèles en même temps
L'idée est simplement qu'on ne peut pas faire exécuter du code dans
cpp, mais qu'on peut créer des objets "globaux".
Je crée donc un objet qui exécute le code que je veux et il n'est créé
qu'une fois et en plus dans le bon module (je veux dire que l'ordre de
compilation des modules n'a pas d'importance)
Je voudrais avoir votre avis sur le principe de ce modèle.
Est-ce stupide ou courant ?
Ca ne me semble pas stupide, par contre je ne vois pas tres bien
l'avantage de la classe template CAutoRun vis-a-vis d'une solution
moins elaboree:
// dans cpp:
int une_fonction(void) {
X::init_map();
// ...
return 0;
}
int static_init = une_fonction();
Mais j'ai peut-etre raté quelque-chose...
Marc G wrote:je ne veux pas utiliser de donnée membre static comme marqueur pour
savoir une initialisation a eu lieu et tester si c'est le cas dans
chaque appel de constructeur.
j'ai eu l'idée de définir une classe template toute simple qui me
permet d'initialiser facilement des données membres static.
Plus concrètement :-)
voici la définition du modèle (le nom du modèle est un peu exagéré :-))
template<typename T>
class CAutoRun {
[snip]
dans hpp
class X {
public :
static void init_map(void) { ...}
static std::map<...> objet_map;
};
dans cpp
void une_fonction(void) {
X::init_map();
...
}
auto_run init_static(une_fonction);
nota : X est pour moi une classe template et dans une_fonction,
j'initialise plusieurs modèles en même temps
L'idée est simplement qu'on ne peut pas faire exécuter du code dans
cpp, mais qu'on peut créer des objets "globaux".
Je crée donc un objet qui exécute le code que je veux et il n'est créé
qu'une fois et en plus dans le bon module (je veux dire que l'ordre de
compilation des modules n'a pas d'importance)
Je voudrais avoir votre avis sur le principe de ce modèle.
Est-ce stupide ou courant ?
Ca ne me semble pas stupide, par contre je ne vois pas tres bien
l'avantage de la classe template CAutoRun vis-a-vis d'une solution
moins elaboree:
// dans cpp:
int une_fonction(void) {
X::init_map();
// ...
return 0;
}
int static_init = une_fonction();
Mais j'ai peut-etre raté quelque-chose...
Mais j'ai peut-etre raté quelque-chose...
non, tu n'as rien raté
la réponse est bien connue :
1 ) pourquoi faire simple quand on peut faire compliqué.
2) et puis comme je découvre les template depuis 3-4 mois, j'en use et j'en
abuse (dans le cas présent, c'est pas trop grave)
Mais c'est vrai que c'est le genre de petite astuce qui gagne à être connue.
J'ai souvent vu des initialisations "compliquées" avec des données membres
static du style
static bool already_initialized;
puis un test dans le constructeur.
C'est pas trop élégant et très inefficace si c'est un petit objet souvent
créé.
En tout cas, merci pour ta réponse.
Mais j'ai peut-etre raté quelque-chose...
non, tu n'as rien raté
la réponse est bien connue :
1 ) pourquoi faire simple quand on peut faire compliqué.
2) et puis comme je découvre les template depuis 3-4 mois, j'en use et j'en
abuse (dans le cas présent, c'est pas trop grave)
Mais c'est vrai que c'est le genre de petite astuce qui gagne à être connue.
J'ai souvent vu des initialisations "compliquées" avec des données membres
static du style
static bool already_initialized;
puis un test dans le constructeur.
C'est pas trop élégant et très inefficace si c'est un petit objet souvent
créé.
En tout cas, merci pour ta réponse.
Mais j'ai peut-etre raté quelque-chose...
non, tu n'as rien raté
la réponse est bien connue :
1 ) pourquoi faire simple quand on peut faire compliqué.
2) et puis comme je découvre les template depuis 3-4 mois, j'en use et j'en
abuse (dans le cas présent, c'est pas trop grave)
Mais c'est vrai que c'est le genre de petite astuce qui gagne à être connue.
J'ai souvent vu des initialisations "compliquées" avec des données membres
static du style
static bool already_initialized;
puis un test dans le constructeur.
C'est pas trop élégant et très inefficace si c'est un petit objet souvent
créé.
En tout cas, merci pour ta réponse.
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
Marc G wrote:Mais j'ai peut-etre raté quelque-chose...
Mais c'est vrai que c'est le genre de petite astuce qui
gagne à être connue.
dans le code que j'ai proposé, j'ai modifié "void une_fontion()" en " int
une_fonction()", la valeur de retour ne servant qu'a initialiser l'objet
global. Si tu ne veux/peux pas modifier le prototype de la fonction, tu
peux aussi faire ceci:
void une_fonction() { ... }
bool static_init = ( une_fonction(), true );
Mais je ne suis pas sur que l'usage de l'operateur virgule + les
parentheses rende le tout plus propre...
J'ai souvent vu des initialisations "compliquées" avec des données membres
static du style
static bool already_initialized;
puis un test dans le constructeur.
C'est pas trop élégant et très inefficace si c'est un petit objet souvent
créé.
Et ca deviendra interessant avec des threads...
Marc G wrote:
Mais j'ai peut-etre raté quelque-chose...
Mais c'est vrai que c'est le genre de petite astuce qui
gagne à être connue.
dans le code que j'ai proposé, j'ai modifié "void une_fontion()" en " int
une_fonction()", la valeur de retour ne servant qu'a initialiser l'objet
global. Si tu ne veux/peux pas modifier le prototype de la fonction, tu
peux aussi faire ceci:
void une_fonction() { ... }
bool static_init = ( une_fonction(), true );
Mais je ne suis pas sur que l'usage de l'operateur virgule + les
parentheses rende le tout plus propre...
J'ai souvent vu des initialisations "compliquées" avec des données membres
static du style
static bool already_initialized;
puis un test dans le constructeur.
C'est pas trop élégant et très inefficace si c'est un petit objet souvent
créé.
Et ca deviendra interessant avec des threads...
Marc G wrote:Mais j'ai peut-etre raté quelque-chose...
Mais c'est vrai que c'est le genre de petite astuce qui
gagne à être connue.
dans le code que j'ai proposé, j'ai modifié "void une_fontion()" en " int
une_fonction()", la valeur de retour ne servant qu'a initialiser l'objet
global. Si tu ne veux/peux pas modifier le prototype de la fonction, tu
peux aussi faire ceci:
void une_fonction() { ... }
bool static_init = ( une_fonction(), true );
Mais je ne suis pas sur que l'usage de l'operateur virgule + les
parentheses rende le tout plus propre...
J'ai souvent vu des initialisations "compliquées" avec des données membres
static du style
static bool already_initialized;
puis un test dans le constructeur.
C'est pas trop élégant et très inefficace si c'est un petit objet souvent
créé.
Et ca deviendra interessant avec des threads...
L'ordre des initialisation des statiques plus le fait que si personne
n'utilise la map, elle sera quand même inclue à cause de cette utilis ation.
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
L'ordre des initialisation des statiques plus le fait que si personne
n'utilise la map, elle sera quand même inclue à cause de cette utilis ation.
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
L'ordre des initialisation des statiques plus le fait que si personne
n'utilise la map, elle sera quand même inclue à cause de cette utilis ation.
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
une question subsidiaire pour moi
la fonction init_map, elle n'est appelée qu'une fois, lors de la première
initialisation de la variable static initialized ?
ou elle est appelée à chaque fois ?
dans mon cas, l'objet map est "très" utilisé donc il doit être construit de
toutes façons.
mais ta réponse est intéressante.
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
une question subsidiaire pour moi
la fonction init_map, elle n'est appelée qu'une fois, lors de la première
initialisation de la variable static initialized ?
ou elle est appelée à chaque fois ?
dans mon cas, l'objet map est "très" utilisé donc il doit être construit de
toutes façons.
mais ta réponse est intéressante.
Une solution classique est:
class X {
public:
//fonction retournant le singleton de class
static std::map<...>& getMap();
private:
//fonction d'initialisation
static bool init_map(std::map<...>& m);
};
std::map<...>& X::getMap()
{
//build at first call
static std::map<...> objet_map;
//called once
static bool initialized=init_map(&objet_map);
return objet_map;
}
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
une question subsidiaire pour moi
la fonction init_map, elle n'est appelée qu'une fois, lors de la première
initialisation de la variable static initialized ?
ou elle est appelée à chaque fois ?
dans mon cas, l'objet map est "très" utilisé donc il doit être construit de
toutes façons.
mais ta réponse est intéressante.
On Mar 13, 9:33 pm, Michael DOUBEZ wrote:
[...]L'ordre des initialisation des statiques plus le fait que si personne
n'utilise la map, elle sera quand même inclue à cause de cette utilisation.
Une solution classique est:
class X {
[snip]..
};
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
C'est assez proche du singleton. Pourquoi pas en faire une
véritable singleton :
std::map<...>&
X::get()
{
static::map<...>* theOneAndOnly = createMap() ;
return *theOneAndOnly ;
}
avec :
std::map<...>*
createMap()
{
std::map<...>* result = new std::map<...> ;
// initialisation du map...
return result ;
}
Ça a aussi l'avantage d'éliminer les risques dues à l'ordre de
destruction. (J'avoue ne jamais avoir eu de problèmes de cette
côté-là, mais en principe, elles existent.)
Enfin, il faut faire gaffe aux threads dans ces cas-là. La
construction des statiques locales n'est pas thread safe, au
moins dans les compilateurs courants. Du coup, il faudrait soit
s'assurer que la fonction est appelée au moins une fois avant le
démarrage des threads, soit y introduire des locks.
On Mar 13, 9:33 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
[...]
L'ordre des initialisation des statiques plus le fait que si personne
n'utilise la map, elle sera quand même inclue à cause de cette utilisation.
Une solution classique est:
class X {
[snip]..
};
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
C'est assez proche du singleton. Pourquoi pas en faire une
véritable singleton :
std::map<...>&
X::get()
{
static::map<...>* theOneAndOnly = createMap() ;
return *theOneAndOnly ;
}
avec :
std::map<...>*
createMap()
{
std::map<...>* result = new std::map<...> ;
// initialisation du map...
return result ;
}
Ça a aussi l'avantage d'éliminer les risques dues à l'ordre de
destruction. (J'avoue ne jamais avoir eu de problèmes de cette
côté-là, mais en principe, elles existent.)
Enfin, il faut faire gaffe aux threads dans ces cas-là. La
construction des statiques locales n'est pas thread safe, au
moins dans les compilateurs courants. Du coup, il faudrait soit
s'assurer que la fonction est appelée au moins une fois avant le
démarrage des threads, soit y introduire des locks.
On Mar 13, 9:33 pm, Michael DOUBEZ wrote:
[...]L'ordre des initialisation des statiques plus le fait que si personne
n'utilise la map, elle sera quand même inclue à cause de cette utilisation.
Une solution classique est:
class X {
[snip]..
};
Ensuite, au lieu d'appeler X::objet_map, appeler X::getMap().
C'est assez proche du singleton. Pourquoi pas en faire une
véritable singleton :
std::map<...>&
X::get()
{
static::map<...>* theOneAndOnly = createMap() ;
return *theOneAndOnly ;
}
avec :
std::map<...>*
createMap()
{
std::map<...>* result = new std::map<...> ;
// initialisation du map...
return result ;
}
Ça a aussi l'avantage d'éliminer les risques dues à l'ordre de
destruction. (J'avoue ne jamais avoir eu de problèmes de cette
côté-là, mais en principe, elles existent.)
Enfin, il faut faire gaffe aux threads dans ces cas-là. La
construction des statiques locales n'est pas thread safe, au
moins dans les compilateurs courants. Du coup, il faudrait soit
s'assurer que la fonction est appelée au moins une fois avant le
démarrage des threads, soit y introduire des locks.
On Mar 13, 9:33 pm, Michael DOUBEZ wrote:
[...]
C'est assez proche du singleton. Pourquoi pas en faire une
véritable singleton :
C'est un singleton avec une fonction custom d'initalisation à cause
de l'initialisation statique des variables.
std::map<...>&
X::get()
{
static::map<...>* theOneAndOnly = createMap() ;
return *theOneAndOnly ;
}
avec :
std::map<...>*
createMap()
{
std::map<...>* result = new std::map<...> ;
// initialisation du map...
return result ;
}
Oui, c'est beaucoup plus clair et peut être avec un auto_ptr<> pour ê tre
100% propre.
Ça a aussi l'avantage d'éliminer les risques dues à l'ordre de
destruction. (J'avoue ne jamais avoir eu de problèmes de cette
côté-là, mais en principe, elles existent.)
Enfin, il faut faire gaffe aux threads dans ces cas-là. La
construction des statiques locales n'est pas thread safe, au
moins dans les compilateurs courants. Du coup, il faudrait soit
s'assurer que la fonction est appelée au moins une fois avant le
démarrage des threads, soit y introduire des locks.
J'attends avec impatience le prochain standard qui je l'espère apportera
des solutions élégantes aux statiques partagées.
Il me semble que gcc 4.x inclut automatiquement un lock pour protégé
l'initialisation des statiques.
On Mar 13, 9:33 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
[...]
C'est assez proche du singleton. Pourquoi pas en faire une
véritable singleton :
C'est un singleton avec une fonction custom d'initalisation à cause
de l'initialisation statique des variables.
std::map<...>&
X::get()
{
static::map<...>* theOneAndOnly = createMap() ;
return *theOneAndOnly ;
}
avec :
std::map<...>*
createMap()
{
std::map<...>* result = new std::map<...> ;
// initialisation du map...
return result ;
}
Oui, c'est beaucoup plus clair et peut être avec un auto_ptr<> pour ê tre
100% propre.
Ça a aussi l'avantage d'éliminer les risques dues à l'ordre de
destruction. (J'avoue ne jamais avoir eu de problèmes de cette
côté-là, mais en principe, elles existent.)
Enfin, il faut faire gaffe aux threads dans ces cas-là. La
construction des statiques locales n'est pas thread safe, au
moins dans les compilateurs courants. Du coup, il faudrait soit
s'assurer que la fonction est appelée au moins une fois avant le
démarrage des threads, soit y introduire des locks.
J'attends avec impatience le prochain standard qui je l'espère apportera
des solutions élégantes aux statiques partagées.
Il me semble que gcc 4.x inclut automatiquement un lock pour protégé
l'initialisation des statiques.
On Mar 13, 9:33 pm, Michael DOUBEZ wrote:
[...]
C'est assez proche du singleton. Pourquoi pas en faire une
véritable singleton :
C'est un singleton avec une fonction custom d'initalisation à cause
de l'initialisation statique des variables.
std::map<...>&
X::get()
{
static::map<...>* theOneAndOnly = createMap() ;
return *theOneAndOnly ;
}
avec :
std::map<...>*
createMap()
{
std::map<...>* result = new std::map<...> ;
// initialisation du map...
return result ;
}
Oui, c'est beaucoup plus clair et peut être avec un auto_ptr<> pour ê tre
100% propre.
Ça a aussi l'avantage d'éliminer les risques dues à l'ordre de
destruction. (J'avoue ne jamais avoir eu de problèmes de cette
côté-là, mais en principe, elles existent.)
Enfin, il faut faire gaffe aux threads dans ces cas-là. La
construction des statiques locales n'est pas thread safe, au
moins dans les compilateurs courants. Du coup, il faudrait soit
s'assurer que la fonction est appelée au moins une fois avant le
démarrage des threads, soit y introduire des locks.
J'attends avec impatience le prochain standard qui je l'espère apportera
des solutions élégantes aux statiques partagées.
Il me semble que gcc 4.x inclut automatiquement un lock pour protégé
l'initialisation des statiques.