OVH Cloud OVH Cloud

Constructeurs globaux

3 réponses
Avatar
Vincent Richard
Bonjour,

Je suis face =E0 un petit soucis avec l'ordre d'initialisation des
constructeurs globaux dans des unit=E9s de compilation diff=E9rentes.

Je vous expose mon probl=E8me, avec du code pour que =E7a soit plus parlant=
:

-----------------------------------------------------------------------

a.hpp
=3D=3D=3D=3D=3D

#include <string>

struct A
{
struct prop
{
static const prop PROP_A;
static const prop PROP_B;

prop(const std::string& s) : str(s) { }
prop(const prop& p) : str(p.str) { }

std::string str;
};
};

a.cpp
=3D=3D=3D=3D=3D

#include "a.hpp"

const A::prop A::prop::PROP_A("a");
const A::prop A::prop::PROP_B("b");

b.hpp
=3D=3D=3D=3D=3D

#include "a.hpp"

struct B
{
static A::prop MY_PROP;
};

b.cpp
=3D=3D=3D=3D=3D

#include "b.hpp"

// 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);

test.cpp
=3D=3D=3D=3D=3D=3D=3D=3D

#include "b.hpp"

int main()
{
A a;
B b;
}

-----------------------------------------------------------------------

[vincent@sherlock] /tmp/init $ g++ -g -o test a.cpp b.cpp test.cpp
[vincent@sherlock] /tmp/init $ ./test=20
Segmentation fault

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/

3 réponses

Avatar
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

Avatar
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

Avatar
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