// Ici, lorsque MY_PROP est initialis=E9e, PROP_A ne l'est (peut-=EAtre)
// pas encore, et l'ex=E9cution plante (en particulier, l'affectation
// du std::string).
A::prop B::MY_PROP(A::prop::PROP_A);
Program received signal SIGSEGV, Segmentation fault.
0xb7f8cce0 in std::basic_string<char, std::char_traits<char>, std::allocato=
r<char> >::basic_string () from /usr/lib/libstdc++.so.6
(gdb) bt
#0 0xb7f8cce0 in std::basic_string<char, std::char_traits<char>, std::allo=
cator<char> >::basic_string () from /usr/lib/libstdc++.so.6
#1 0x080488b6 in prop (this=3D0x8049d4c, p=3D@0x8049d44) at a.hpp:11
#2 0x08048853 in __static_initialization_and_destruction_0 (__initialize_p=
=3D1, __priority=3D65535) at b.cpp:6
#3 0x0804889d in global constructors keyed to _ZN1B7MY_PROPE () at b.cpp:7
#4 0x080489c5 in __do_global_ctors_aux ()
#5 0x080484a1 in _init ()
#6 0x080488fb in __libc_csu_init ()
#7 0xb7dbe925 in __libc_start_main () from /lib/tls/libc.so.6
#8 0x08048571 in _start () at ../sysdeps/i386/elf/start.S:102
Comment r=E9soudre ce probl=E8me (initialisation de MY_PROP) ? Sachant que =
je
ne souhaite/peux pas imposer d'ordre sur la compilation des fichiers (ce
qui, je pense, r=E9soudrait le probl=E8me)...
(Note: avec la ligne de compilation "g++ -g -o test b.cpp a.cpp test.cpp",
o=F9 b.cpp est sp=E9cifi=E9 avant a.cpp, il n'y a aucun probl=E8me).
Merci d'avance pour votre aide.
Vincent
--=20
Une biblioth=E8que mail pour C++ sous licence GNU GPL
http://www.vmime.org/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc Bourguet
Vincent Richard writes:
Je suis face à un petit soucis avec l'ordre d'initialisation des constructeurs globaux dans des unités de compilation différentes.
Le problème est classique. La solution traditionnelle est plutôt que d'utiliser des variables globales, d'utiliser des fonctions d'accès s'assurant que la variable est initialisée. Rechercher aussi "singleton" pour voir comment cette solution s'étend pour un problème plus général.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Richard <chere-loque@plop.wanadoo.fr.invalid> writes:
Je suis face à un petit soucis avec l'ordre
d'initialisation des constructeurs globaux dans des unités
de compilation différentes.
Le problème est classique. La solution traditionnelle est
plutôt que d'utiliser des variables globales, d'utiliser des
fonctions d'accès s'assurant que la variable est
initialisée. Rechercher aussi "singleton" pour voir comment
cette solution s'étend pour un problème plus général.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je suis face à un petit soucis avec l'ordre d'initialisation des constructeurs globaux dans des unités de compilation différentes.
Le problème est classique. La solution traditionnelle est plutôt que d'utiliser des variables globales, d'utiliser des fonctions d'accès s'assurant que la variable est initialisée. Rechercher aussi "singleton" pour voir comment cette solution s'étend pour un problème plus général.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Richard
Le problème est classique. La solution traditionnelle est plutôt que d'utiliser des variables globales, d'utiliser des fonctions d'accès s'assurant que la variable est initialisée.
Je voulais justement éviter cette solution...
Mais après quelques recherches sur le net, j'ai l'impression qu'il n'y a pas d'autre solution.
Merci.
Vincent
Le problème est classique. La solution traditionnelle est
plutôt que d'utiliser des variables globales, d'utiliser des
fonctions d'accès s'assurant que la variable est
initialisée.
Je voulais justement éviter cette solution...
Mais après quelques recherches sur le net, j'ai l'impression qu'il
n'y a pas d'autre solution.
Le problème est classique. La solution traditionnelle est plutôt que d'utiliser des variables globales, d'utiliser des fonctions d'accès s'assurant que la variable est initialisée.
Je voulais justement éviter cette solution...
Mais après quelques recherches sur le net, j'ai l'impression qu'il n'y a pas d'autre solution.
Merci.
Vincent
kanze
Alexandre wrote:
Le problème est classique. La solution traditionnelle est plutôt que d'utiliser des variables globales, d'utiliser des fonctions d'accès s'assurant que la variable est initialisée.
Je voulais justement éviter cette solution...
pourquoi ? Elle est de loin plus efficace que des variables globales qui sont, la plupart du temps, source de problèmes.
Efficace, ça dépend. Dans un environement multi-thread, il faut acquérir un lock à chaque appel, ce qui n'est pas gratuit.
Mais après quelques recherches sur le net, j'ai l'impression qu'il n'y a pas d'autre solution.
surement que si ;-) mais le singleton avec test d'initialisation me parait le + simple...
La plus simple, c'est l'initialisation statique. Mais ce n'est pas toujours possible.
Qq chose comme :
class Single { private: static Single* pInstance; Single(); Single(const Single&){} public: static Single& GetInstance(){if(pInstance==NULL) pInstance=new
Single; return *pInstance;} };
Single* Single::pInstance=NULL;
et quand tu en as besoin, tu fais juste Single().La_methode_que_tu_veux();
Tu veux dire : Single::instance().laFonctionQueTuVeux() ;
la première fois ça s'initialise, et après terminé !
Reste à régler, bien sur, le problème du "delete" que je n'ai pas mis ici.
D'après mes expériences, la plupart du temps, je ne veux pas de delete, du tout. Si je le veux, la solution la plus simple consiste à utiliser une variable statique dans Single::instance(), dont le destructeur sera appelé automatiquement.
-- 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
Alexandre wrote:
Le problème est classique. La solution traditionnelle est
plutôt que d'utiliser des variables globales, d'utiliser
des fonctions d'accès s'assurant que la variable est
initialisée.
Je voulais justement éviter cette solution...
pourquoi ? Elle est de loin plus efficace que des variables
globales qui sont, la plupart du temps, source de problèmes.
Efficace, ça dépend. Dans un environement multi-thread, il faut
acquérir un lock à chaque appel, ce qui n'est pas gratuit.
Mais après quelques recherches sur le net, j'ai l'impression
qu'il n'y a pas d'autre solution.
surement que si ;-) mais le singleton avec test
d'initialisation me parait le + simple...
La plus simple, c'est l'initialisation statique. Mais ce n'est
pas toujours possible.
Qq chose comme :
class Single
{
private:
static Single* pInstance;
Single();
Single(const Single&){}
public:
static Single& GetInstance(){if(pInstance==NULL)
pInstance=new
Single; return *pInstance;}
};
Single* Single::pInstance=NULL;
et quand tu en as besoin, tu fais juste
Single().La_methode_que_tu_veux();
Tu veux dire : Single::instance().laFonctionQueTuVeux() ;
la première fois ça s'initialise, et après terminé !
Reste à régler, bien sur, le problème du "delete" que je n'ai
pas mis ici.
D'après mes expériences, la plupart du temps, je ne veux pas de
delete, du tout. Si je le veux, la solution la plus simple
consiste à utiliser une variable statique dans
Single::instance(), dont le destructeur sera appelé
automatiquement.
--
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
Le problème est classique. La solution traditionnelle est plutôt que d'utiliser des variables globales, d'utiliser des fonctions d'accès s'assurant que la variable est initialisée.
Je voulais justement éviter cette solution...
pourquoi ? Elle est de loin plus efficace que des variables globales qui sont, la plupart du temps, source de problèmes.
Efficace, ça dépend. Dans un environement multi-thread, il faut acquérir un lock à chaque appel, ce qui n'est pas gratuit.
Mais après quelques recherches sur le net, j'ai l'impression qu'il n'y a pas d'autre solution.
surement que si ;-) mais le singleton avec test d'initialisation me parait le + simple...
La plus simple, c'est l'initialisation statique. Mais ce n'est pas toujours possible.
Qq chose comme :
class Single { private: static Single* pInstance; Single(); Single(const Single&){} public: static Single& GetInstance(){if(pInstance==NULL) pInstance=new
Single; return *pInstance;} };
Single* Single::pInstance=NULL;
et quand tu en as besoin, tu fais juste Single().La_methode_que_tu_veux();
Tu veux dire : Single::instance().laFonctionQueTuVeux() ;
la première fois ça s'initialise, et après terminé !
Reste à régler, bien sur, le problème du "delete" que je n'ai pas mis ici.
D'après mes expériences, la plupart du temps, je ne veux pas de delete, du tout. Si je le veux, la solution la plus simple consiste à utiliser une variable statique dans Single::instance(), dont le destructeur sera appelé automatiquement.
-- 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