 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Snoopy
Guest
|
 Posted: Sat Jul 23, 2005 6:59 am Post subject: symbole non référencé dans une librairiestatique |
 |
|
Hello,
Il m'arrive de définir des objets que je me contente de stoquer dans une chaîne de pointeurs. Ces objets sont des membres statiques de classe et s'auto-inscrivent dans la chaîne à leur création. Mon problème est le suivant : Les objets n'etant jamais référancés directement, mon compilo (gcc 3.3.5) se permet de les supprimer !
détails :
---------
J'utilise un 'pseudo RTTI' pour construire des objets à partir d'un fichier de config. (et donc à partir de chaîne de char). Tous le code ci-dessous est dans une librairie statique (sinon, ca fonctionne normalement)
Mes objets ressemblent à ca :
-----------------------------
class obj : public objBase {
private:
static objFactory _factory;
};
L'usine d'objets ressemble à ça :
---------------------------------
typedef objBase (*objCtor)();
class objFactory {
public:
objFactory(string name, objCtor ctor) :
_name(name),
_ctor(ctor),
_next(_first) {
_first = this;
}
string _name;
objCtor _ctor;
objFactory* _next;
static objFactory* _first;
};
Implémentation de l'objet :
---------------------------
objBase* ctorForObj() {
return new obj;
}
objFactory obj::_factory("Obj", (objCtor) ctorForObj);
Fonction de construction via RTTI :
-----------------------------------
objBase* create(string name) {
objFactory* factory = objFactory::_first;
while (factory) {
if (factory->_name == name)
return factory->_ctor();
factory = factory->_next;
}
return NULL;
}
Conclusion :
-----------
Je me retrouve avec un objet non référencé à l'extérieur de la lib (obj) qui contient un objet statique encore moin référencé (obj::factory). à l'éddition des liens, ce dernier est supprimé.
Comment contourner le problème ?
Voyez-vous une autre méthode pour faire celà sans avoir de fonction d'initialisation de la librairie ?
Merci
--
sn00py
|
|
| Back to top |
|
 |
Loïc Joly
Guest
|
| Posted: Sat Jul 23, 2005 8:24 am Post subject: Re: symbole non référencé dans une librairie statique |
|
|
Snoopy a écrit :
| Quote: | Hello,
Il m'arrive de définir des objets que je me contente de stoquer dans
une chaîne de pointeurs. Ces objets sont des membres statiques de
classe et s'auto-inscrivent dans la chaîne à leur création. Mon
problème est le suivant : Les objets n'etant jamais référancés
directement, mon compilo (gcc 3.3.5) se permet de les supprimer !
[...]
Comment contourner le problème ? Voyez-vous une autre méthode pour
faire celà sans avoir de fonction d'initialisation de la librairie ?
|
Il doit être possible par une option du linker de lui dire de ne pas
supprimer une référence à un objet d'une bibliothèque, même si cet objet
n'a pas l'air utilisé dans le programme principal. Avec les compilateurs
que je connais, il faut pour ça donner le nom décorré de l'objet, ce qui
est un peu rugueux.
--
Loïc
|
|
| Back to top |
|
|
Snoopy
Guest
|
| Posted: Sat Jul 23, 2005 9:27 am Post subject: Re: symbole non référencé dans unelibrairie statique |
|
|
Loïc Joly <loic.actarus.joly (AT) wanadoo (DOT) fr> wrote:
| Quote: | Snoopy a écrit :
Hello,
Il m'arrive de définir des objets que je me contente de stoquer dans
une chaîne de pointeurs. Ces objets sont des membres statiques de
classe et s'auto-inscrivent dans la chaîne à leur création. Mon
problème est le suivant : Les objets n'etant jamais référancés
directement, mon compilo (gcc 3.3.5) se permet de les supprimer !
[...]
Comment contourner le problème ? Voyez-vous une autre méthode pour
faire celà sans avoir de fonction d'initialisation de la librairie ?
Il doit être possible par une option du linker de lui dire de ne pas
supprimer une référence à un objet d'une bibliothèque, même si cet objet
n'a pas l'air utilisé dans le programme principal. Avec les compilateurs
que je connais, il faut pour ça donner le nom décorré de l'objet, ce qui
est un peu rugueux.
|
Oui, j'y avait pensé, et avec gcc il faut effectivement lister tous les objets, ce qui s'avère encore plus contraingant que de créer une fonction d'initialisation de la librairie.
Ce qui me parait étrange c'est que je déclare une instance de cet objet.. Je veux bien que le compilo supprimer des symboles non définits, mais pourquoi supprimerait-il des instances d'objets ?
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sat Jul 23, 2005 11:21 am Post subject: Re: symbole non référencé dans une librairie statique |
|
|
Snoopy wrote:
| Quote: | Il m'arrive de définir des objets que je me contente de
stoquer dans une chaîne de pointeurs. Ces objets sont des
membres statiques de classe et s'auto-inscrivent dans la
chaîne à leur création. Mon problème est le suivant : Les
objets n'etant jamais référancés directement, mon compilo (gcc
3.3.5) se permet de les supprimer !
|
Seulement si c'est ce que tu lui as démandé.
| Quote: | détails :
---------
J'utilise un 'pseudo RTTI' pour construire des objets à partir
d'un fichier de config. (et donc à partir de chaîne de char).
Tous le code ci-dessous est dans une librairie statique
(sinon, ca fonctionne normalement)
|
Précisement. Par définition, une bibliothèque sert à contenir
des objets qui ne sont incorporés au programme que
conditionnellement, s'ils résoudent une référence externe non
résolue. C'est la définition même d'une bibliothèque (et en
fait, les DLL de Windows ne sont pas de bibliothèques, mais des
objets chargés dynamiquement). Si ce n'est pas le comportement
voulu, la réponse est facile, n'utilise pas une bibliothèque.
[... l'idiome est très connu]
| Quote: | Conclusion :
-----------
Je me retrouve avec un objet non référencé à l'extérieur de la
lib (obj) qui contient un objet statique encore moin référencé
(obj::factory). à l'éddition des liens, ce dernier est
supprimé.
|
Il n'est pas supprimé. Il n'a jamais fait partie du programme
pour commencer.
| Quote: | Comment contourner le problème ?
|
La solution classique, c'est de ne pas utiliser une
bibliothèque:-). Mais il y a bien d'autres moyens de tricher.
| Quote: | Voyez-vous une autre méthode pour faire celà sans avoir de
fonction d'initialisation de la librairie ?
|
Tu n'as pas besoin d'une fonction. Tu as simplement besoin d'un
symbole externe qui déclenche une chaîne d'externes
non-résolues. Par exemple, quand tu construis la bibliothèque,
tu as bien une liste des fichiers qu'elle contient. C'est assez
facile alors de :
-- définir un symbole dans le namespace globale, selon une
convention (nommage, type, etc.) que tu établis,
-- lors de la création de la bibliothèque, parcourir tous les
sources, en extrayant ces symboles pour en créer une source
supplémentaire qui contient un tableau de pointeurs à ces
éléments, et
-- s'arranger qu'une des unités de compilation avec un symbole
externe qui sert réelement prend l'adresse de ce tableau.
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
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
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sat Jul 23, 2005 11:22 am Post subject: Re: symbole non référencé dans une librairie statique |
|
|
Loïc Joly wrote:
| Quote: | Snoopy a écrit :
Il m'arrive de définir des objets que je me contente de
stoquer dans une chaîne de pointeurs. Ces objets sont des
membres statiques de classe et s'auto-inscrivent dans la
chaîne à leur création. Mon problème est le suivant : Les
objets n'etant jamais référancés directement, mon compilo
(gcc 3.3.5) se permet de les supprimer !
[...]
Comment contourner le problème ? Voyez-vous une autre méthode
pour faire celà sans avoir de fonction d'initialisation de la
librairie ?
Il doit être possible par une option du linker de lui dire de
ne pas supprimer une référence à un objet d'une bibliothèque,
même si cet objet n'a pas l'air utilisé dans le programme
principal. Avec les compilateurs que je connais, il faut pour
ça donner le nom décorré de l'objet, ce qui est un peu
rugueux.
|
Si c'est un objet (mettons un tableau avec des pointeur à tous
ce dont on veut forcer l'incorporation), le nom n'est pas
décoré, au moins avec les compilateurs que je connais (dont
g++).
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
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
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sat Jul 23, 2005 11:26 am Post subject: Re: symbole non référencé dans une librairie statique |
|
|
Snoopy wrote:
| Quote: | Loïc Joly <loic.actarus.joly (AT) wanadoo (DOT) fr> wrote:
Oui, j'y avait pensé, et avec gcc il faut effectivement lister
tous les objets, ce qui s'avère encore plus contraingant que
de créer une fonction d'initialisation de la librairie. Ce qui
me parait étrange c'est que je déclare une instance de cet
objet. Je veux bien que le compilo supprimer des symboles non
définits, mais pourquoi supprimerait-il des instances d'objets
?
|
Premièrement, le compilateur ne supprime rien. En mettant les
fichiers objet dans une bibliothèque, tu as dis à l'éditeur de
liens de ne les incorporés au programme que si l'objet résoud un
symbole externe non encore résolu. Tout ce qui se passe, c'est
que l'éditeur de liens fait ce que tu lui as dit.
Deuxièmement, tu as bien une liste de tous les fichiers quelque
part, ne serait-ce que dans le fichier de make pour la
bibliothèque. À partir de là, rien de plus trivial que de
générer un tableau avec tous les externes non résolus que tu
veux. Ensuite, fait en sorte que ce tableau fasse partie de ton
programme, et l'éditeur de liens ferait la reste.
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
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
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Sat Jul 23, 2005 4:54 pm Post subject: Re: symbole non référencé dans une librairie statique |
|
|
James Kanze <kanze@none> writes:
| Quote: | Loïc Joly wrote:
Snoopy a écrit :
Il m'arrive de définir des objets que je me contente de
stoquer dans une chaîne de pointeurs. Ces objets sont des
membres statiques de classe et s'auto-inscrivent dans la
chaîne à leur création. Mon problème est le suivant : Les
objets n'etant jamais référancés directement, mon compilo
(gcc 3.3.5) se permet de les supprimer !
[...]
Comment contourner le problème ? Voyez-vous une autre méthode
pour faire celà sans avoir de fonction d'initialisation de la
librairie ?
Il doit être possible par une option du linker de lui dire de
ne pas supprimer une référence à un objet d'une bibliothèque,
même si cet objet n'a pas l'air utilisé dans le programme
principal. Avec les compilateurs que je connais, il faut pour
ça donner le nom décorré de l'objet, ce qui est un peu
rugueux.
Si c'est un objet (mettons un tableau avec des pointeur à tous
ce dont on veut forcer l'incorporation), le nom n'est pas
décoré, au moins avec les compilateurs que je connais (dont
g++).
|
merlin[11:54]% cat jk.C && g++ -S jk.C | cat jk.s && (cat jk.s | c++filt )
struct foo {
static int* bar[];
};
int* foo::bar[42];
.file "jk.C"
..globl _ZN3foo3barE
.bss
.align 32
.type _ZN3foo3barE, @object
.size _ZN3foo3barE, 168
_ZN3foo3barE:
.zero 168
.ident "GCC: (GNU) 4.1.0 20050721 (experimental)"
.section .note.GNU-stack,"",@progbits
.file "jk.C"
..globl foo::bar
.bss
.align 32
.type foo::bar, @object
.size foo::bar, 168
foo::bar:
.zero 168
.ident "GCC: (GNU) 4.1.0 20050721 (experimental)"
.section .note.GNU-stack,"",@progbits
-- Gaby
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Sat Jul 23, 2005 7:52 pm Post subject: Re: symbole non référencé dans une librairie statique |
|
|
Snoopy <sn00py.2 (AT) laposte (DOT) net> writes:
| Quote: | Loïc Joly <loic.actarus.joly (AT) wanadoo (DOT) fr> wrote:
Snoopy a écrit :
Hello,
Il m'arrive de définir des objets que je me contente de stoquer dans
une chaîne de pointeurs. Ces objets sont des membres statiques de
classe et s'auto-inscrivent dans la chaîne à leur création. Mon
problème est le suivant : Les objets n'etant jamais référancés
directement, mon compilo (gcc 3.3.5) se permet de les supprimer !
[...]
Comment contourner le problème ? Voyez-vous une autre méthode pour
faire celà sans avoir de fonction d'initialisation de la librairie ?
Il doit être possible par une option du linker de lui dire de ne pas
supprimer une référence à un objet d'une bibliothèque, même si cet objet
n'a pas l'air utilisé dans le programme principal. Avec les compilateurs
que je connais, il faut pour ça donner le nom décorré de l'objet, ce qui
est un peu rugueux.
Oui, j'y avait pensé, et avec gcc il faut effectivement lister tous
les objets, ce qui s'avère encore plus contraingant que de créer une
fonction d'initialisation de la librairie.
Ce qui me parait étrange c'est que je déclare une instance de cet
objet. Je veux bien que le compilo supprimer des symboles non
définits, mais pourquoi supprimerait-il des instances d'objets ?
|
Je n'ai pas l'impression que tu as définis cet objet...
-- Gaby
|
|
| Back to top |
|
|
plouf79@yahoo.fr
Guest
|
| Posted: Sun Jul 24, 2005 4:22 pm Post subject: Re: symbole non référencé dans une librairie statique |
|
|
| Quote: | Tu n'as pas besoin d'une fonction. Tu as simplement besoin d'un
symbole externe qui déclenche une chaîne d'externes
non-résolues. Par exemple, quand tu construis la bibliothèque,
tu as bien une liste des fichiers qu'elle contient. C'est assez
facile alors de :
-- définir un symbole dans le namespace globale, selon une
convention (nommage, type, etc.) que tu établis,
-- lors de la création de la bibliothèque, parcourir tous les
sources, en extrayant ces symboles pour en créer une source
supplémentaire qui contient un tableau de pointeurs à ces
éléments, et
-- s'arranger qu'une des unités de compilation avec un symbole
externe qui sert réelement prend l'adresse de ce tableau.
|
Une petite question, juste pour être sûr :
Si on a les 3 fichiers suivants :
/// main.cpp ///
int main()
{
return 0;
}
/// libtoto.h ///
#include <iostream>
using namespace std;
class toto
{
public:
toto()
{
cout << "Toto is used" << endl ;
}
};
/// libtoto.cpp ///
#include "libtoto.h"
toto T;
/// Fin des fichiers ///
.... et qu'on fait :
g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
Alors on a bien de manière certaine "tototest"
qui affiche "Toto is used" à l'execution ?
C'est bien garanti par la norme ça ? même s'il
n'y a rien dans le 'main' qui indique que l'objet
toto est utilisé ?
--
P.
|
|
| Back to top |
|
|
Snoopy
Guest
|
| Posted: Sun Jul 24, 2005 6:13 pm Post subject: Re: symbole non référencé dans unelibrairie statique |
|
|
| Quote: | Une petite question, juste pour être sûr :
Si on a les 3 fichiers suivants :
[...]
... et qu'on fait :
g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
Alors on a bien de manière certaine "tototest"
qui affiche "Toto is used" à l'execution ?
C'est bien garanti par la norme ça ? même s'il
n'y a rien dans le 'main' qui indique que l'objet
toto est utilisé ?
|
Dans mon cas j'utilise une bibliothèque statique, pas un .o qui s'appellelibxxxx :
g++ -g -c -Wall libtoto.cpp
ar cru libtoto.a libtoto.o
ranlib libtoto.a
g++ -g -Wall main.c libtoto.a -o tototest
Et dans ce cas on n'a pas de message "Toto is used".
L'explication donnée par James est très logique, malheureusement pour moi !
--
sn00py
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Jul 24, 2005 8:47 pm Post subject: Re: symbole non référencé dans une librairie statique |
|
|
[email]plouf79 (AT) yahoo (DOT) fr[/email] wrote:
| Quote: | Tu n'as pas besoin d'une fonction. Tu as simplement besoin
d'un symbole externe qui déclenche une chaîne d'externes
non-résolues. Par exemple, quand tu construis la bibliothèque,
tu as bien une liste des fichiers qu'elle contient. C'est
assez facile alors de :
-- définir un symbole dans le namespace globale, selon une
convention (nommage, type, etc.) que tu établis,
-- lors de la création de la bibliothèque, parcourir tous les
sources, en extrayant ces symboles pour en créer une source
supplémentaire qui contient un tableau de pointeurs à ces
éléments, et
-- s'arranger qu'une des unités de compilation avec un symbole
externe qui sert réelement prend l'adresse de ce tableau.
Une petite question, juste pour être sûr :
Si on a les 3 fichiers suivants :
/// main.cpp ///
int main()
{
return 0;
}
/// libtoto.h ///
#include
using namespace std;
class toto
{
public:
toto()
{
cout << "Toto is used" << endl ;
}
};
/// libtoto.cpp ///
#include "libtoto.h"
toto T;
/// Fin des fichiers ///
... et qu'on fait :
g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
Alors on a bien de manière certaine "tototest" qui affiche
"Toto is used" à l'execution ?
|
Oui.
| Quote: | C'est bien garanti par la norme ça ?
|
Pas vraiment. Il y a deux questions ici vis-à-vis de la norme.
-- La première, c'est que la norme donne deux alternatifs pour
l'initialisation des statiques : ou bien, ils sont
initialisés avant d'entrer en main, ou bien, ils sont
initialisés avant la première utilisation de l'unité de
compilation qui les contient.
En fait, toutes les implémentations utilisent le permier, et
pour deux raisons. D'abord, il y a de plus en plus de code
qu'y compte, et qu'on ne veut pas casser, et deuxièmement,
le deuxième alternatif n'est pas implémentable s'il y a des
cycles (et la norme dit que si on le choisit, il faut qu'il
marche -- sans exception pour des cycles).
Dans la pratique, je crois qu'on peut dire que dans
l'absence des objets linkés dynamiquement, les statiques
sont initialisés avant l'entrée dans main.
-- La norme ne s'adresse pas à la question : comment invoquer
le compilateur, et donc, comment spécifier qu'une source (ou
l'objet qui en dérive) fasse partie du programme. Dans les
faits, la définition d'une bibliothèque est assez générale ;
on voit mal un compilateur oser faire autre chose. (Bien
que... VC++ parle des bibliothèques par rapport aux DLL, et
le comportement d'une DLL ne correspond pas au comportement
traditionnel d'une bibliothèque.) Donc, le fait de spécifier
un objet sur la ligne de commande fait partie de
l'invocation de g++ ; rien n'interdirait (sauf la tradition)
de dire qu'il traite cet objet comme faisant partie d'une
bibliothèque.
Ici, aussi, on a en fait une très longue et très forte
tradition. Tous les éditeurs de liens que je connais (et ça
rémonte prèsque 35 ans dans le temps) ont une façon de
spécifier une liste de fichiers objets, et une façon de
spécifier une liste de fichiers bibliothèques. Et tous
incorpore tous les fichiers objets dans le programme, mais
seulement les objets des bibliothèques qui résolvent un
externe non encore résolu. Ils diffèrent beaucoup dans la
façon de spécifier ces objets et ces bibliothèques (encore
que la ligne de commande soit assez généralisée
aujourd'hui), et ils diffèrent beaucoup dans la façon
(surtout l'ordre) qu'ils traitent les différents éléments.
Ils ont aussi des variations sur des possibilités
supplémentaires. Mais la distinction fichier objet/fichier
bibliothèque est tellement universelle que je crois qu'on
peut y compter.
Donc, si ta question est : est-ce qu'il est garanti par la norme
que, donné les sources ci-dessus, les commandes :
| Quote: | g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
|
génèreront un programme qui affiche "toto is used", la résponse
est certainement non -- ces commandes-là, elles ne feront
absolument rien avec VC++, par exemple. Mais, et je crois que
c'est ce qui t'intéresse, tu peux compter que pour tout
compilateur C++, il y a une suite équivalente des commandes, et
que cette suite équivalente donnera bien un programme qui
affiche "toto is used".
| Quote: | même s'il n'y a rien dans le 'main' qui indique que l'objet
toto est utilisé ?
|
La question n'est pas si toto est utilisé. La question, c'est
d'abord et surtout si libtoto.cpp fait partie de ton programme.
Si libtoto.cpp fait partie du programme, l'objet qu'il contient
doit être initialisé.
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
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
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Sun Jul 24, 2005 9:29 pm Post subject: Re: symbole non référencé dans une librairie statique |
|
|
James Kanze <kanze@none> writes:
[...]
| Quote: | C'est bien garanti par la norme ça ?
Pas vraiment. Il y a deux questions ici vis-à-vis de la norme.
-- La première, c'est que la norme donne deux alternatifs pour
l'initialisation des statiques : ou bien, ils sont
initialisés avant d'entrer en main, ou bien, ils sont
initialisés avant la première utilisation de l'unité de
compilation qui les contient.
En fait, toutes les implémentations utilisent le permier, et
pour deux raisons. D'abord, il y a de plus en plus de code
qu'y compte, et qu'on ne veut pas casser, et deuxièmement,
le deuxième alternatif n'est pas implémentable s'il y a des
cycles (et la norme dit que si on le choisit, il faut qu'il
marche -- sans exception pour des cycles).
Dans la pratique, je crois qu'on peut dire que dans
l'absence des objets linkés dynamiquement, les statiques
sont initialisés avant l'entrée dans main.
|
Sauf que dans la pratique, il y a de plus en plus d'objets dynamiquement
liés.
-- Gaby
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon Jul 25, 2005 8:01 am Post subject: Re: symbole non référencé dans une librairie statique |
|
|
Gabriel Dos Reis wrote:
| Quote: | James Kanze <kanze@none> writes:
[...]
| > C'est bien garanti par la norme ça ?
| Pas vraiment. Il y a deux questions ici vis-à-vis de la norme.
| -- La première, c'est que la norme donne deux alternatifs pour
| l'initialisation des statiques : ou bien, ils sont
| initialisés avant d'entrer en main, ou bien, ils sont
| initialisés avant la première utilisation de l'unité de
| compilation qui les contient.
| En fait, toutes les implémentations utilisent le permier, et
| pour deux raisons. D'abord, il y a de plus en plus de code
| qu'y compte, et qu'on ne veut pas casser, et deuxièmement,
| le deuxième alternatif n'est pas implémentable s'il y a des
| cycles (et la norme dit que si on le choisit, il faut qu'il
| marche -- sans exception pour des cycles).
| Dans la pratique, je crois qu'on peut dire que dans
| l'absence des objets linkés dynamiquement, les statiques
| sont initialisés avant l'entrée dans main.
Sauf que dans la pratique, il y a de plus en plus d'objets
dynamiquement liés.
|
Un peu trop, même, à mon avis:-). Reste que la norme exige que
l'édition de liens ait lieu avant l'exécution. Quand tu fais
l'édition de liens dynamiques, tu es en dehors de la norme
(actuel). (Sauf, éventuellement, si l'édition de liens
dynamiques a lieu automatiquement, avant d'entrer en main. En
tout cas, selon la norme, tu n'as un « exécutable » qu'après
tout est lié. Et sans exécutable, pas d'exécution.)
De toute façon, aucune implémentation des objets dynamiquement
liés implémente correctement la deuxième phrase de §3.6/3, qui
exigerait un tri topologique de l'objet dynamique (et qui sera
impossible dans le cas des cycles de dépendance).
Dans l'ensemble, l'édition de liens dynamique est une autre
question, qu'il faut bien prendre en compte. Ou non, selon les
exigeances de l'application. Mais je crois que tu as raison ;
j'aurais dû au moins l'évoquer. Techniquement, il ne fait pas
partie du C++, et il ne s'agit pas non plus des bibliothèques,
mais pratiquement, c'est effectivement possible que le poster
doit le prendre en compte, quel que soit sa position vis-à-vis
de la norme, et indifférement de comment on l'appelle. Même s'il
n'intervenait pas dans son exemple.
Dans la pratique, je crois qu'on peut dire que les constructeurs
des objets statiques dans un objet dynamique sont appelés quand
l'objet est chargé : pendant l'appel à dlopen ou son équivalent
sous Windows. Dans un ordre indéfini, sauf pour les objets à
l'intérieur d'une même unité de compilation. (Maintenant, tu vas
me dire que j'ai oublié la question des threads, et ce qui se
passe si deux threads différents appellent dlopen en
parallel:-).)
--
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
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon Jul 25, 2005 9:55 am Post subject: Re: symbole non référencé dans une librairie statique |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
[...]
| Quote: | Dans la pratique, je crois qu'on peut dire que les constructeurs
des objets statiques dans un objet dynamique sont appelés quand
l'objet est chargé : pendant l'appel à dlopen ou son équivalent
sous Windows. Dans un ordre indéfini, sauf pour les objets à
l'intérieur d'une même unité de compilation. (Maintenant, tu vas
me dire que j'ai oublié la question des threads, et ce qui se
passe si deux threads différents appellent dlopen en
parallel:-).)
|
Exact (pour tout  )
-- Gaby
|
|
| Back to top |
|
|
plouf
Guest
|
| Posted: Tue Jul 26, 2005 12:01 am Post subject: Re: symbole non référencé dans une librairie statique |
|
|
| Quote: | ...
En fait, toutes les implémentations utilisent le permier, et
pour deux raisons. D'abord, il y a de plus en plus de code
qu'y compte, et qu'on ne veut pas casser, et deuxièmement,
le deuxième alternatif n'est pas implémentable s'il y a des
cycles (et la norme dit que si on le choisit, il faut qu'il
marche -- sans exception pour des cycles).
Dans la pratique, je crois qu'on peut dire que dans
l'absence des objets linkés dynamiquement, les statiques
sont initialisés avant l'entrée dans main.
|
C'est ce qui m'interesse. Donc ça va.
| Quote: |
-- La norme ne s'adresse pas à la question : comment invoquer
le compilateur, et donc, comment spécifier qu'une source (ou
l'objet qui en dérive) fasse partie du programme. Dans les
.....
Ils ont aussi des variations sur des possibilités
supplémentaires. Mais la distinction fichier objet/fichier
bibliothèque est tellement universelle que je crois qu'on
peut y compter.
(surtout l'ordre) qu'ils traitent les différents éléments.
Ils ont aussi des variations sur des possibilités
supplémentaires. Mais la distinction fichier objet/fichier
bibliothèque est tellement universelle que je crois qu'on
peut y compter.
|
Je ne pensais pas que la tradition était aussi importante.
J'aurais cru que les norme étaient plus précise. C'est bon
à savoir.
C'est assez étonnant. Peut-être que la norme incorporera un
jour ces éléments. Puisque celà semble être un standard
de fait ?
| Quote: |
Donc, si ta question est : est-ce qu'il est garanti par la norme
que, donné les sources ci-dessus, les commandes :
g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
génèreront un programme qui affiche "toto is used", la résponse
est certainement non -- ces commandes-là, elles ne feront
absolument rien avec VC++, par exemple.
D'accord, j'ai pris gcc comme exemple car c'est assez répandu  |
| Quote: | Mais, et je crois que
c'est ce qui t'intéresse, tu peux compter que pour tout
compilateur C++, il y a une suite équivalente des commandes, et
que cette suite équivalente donnera bien un programme qui
affiche "toto is used".
Merci beaucoup pour toutes ces précisions. |
| Quote: | même s'il n'y a rien dans le 'main' qui indique que l'objet
toto est utilisé ?
La question n'est pas si toto est utilisé. La question, c'est
d'abord et surtout si libtoto.cpp fait partie de ton programme.
Si libtoto.cpp fait partie du programme, l'objet qu'il contient
doit être initialisé.
J'ai bien saisi la différence fichier objet/Bibliotheque, |
j'avais tendance à ne pas trop la faire avant. C'est vrai
que dans beaucoup de cas ça ne change rien au fonctionnement
du programme.
Par contre j'ai fait un programme qui utilise assez massivement
l'initialisation d'objets qui ne sont pas utilisés dans le 'main'
pour faire de choses avant l'execution du 'main' et ça m'aurait
vraiment embêter d'apprendre que ça ne marche qu'avec gcc sous
linux (par exemple).
C'est parfois très pratique ce comportement.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
