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 ?
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 ?
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 ?
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 compilateur s
que je connais, il faut pour ça donner le nom décorré de l'objet, c e qui
est un peu rugueux.
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 compilateur s
que je connais, il faut pour ça donner le nom décorré de l'objet, c e qui
est un peu rugueux.
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 compilateur s
que je connais, il faut pour ça donner le nom décorré de l'objet, c e qui
est un peu rugueux.
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)
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 ?
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)
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 ?
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)
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 ?
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.
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.
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.
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.
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.
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 :
[...]
... 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é ?
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é ?
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é ?
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 ?
g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
même s'il n'y a rien dans le 'main' qui indique que l'objet
toto est utilisé ?
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 ?
g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
même s'il n'y a rien dans le 'main' qui indique que l'objet
toto est utilisé ?
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 ?
g++ -g -c -Wall libtoto.cpp
g++ -g -c -Wall main.cpp
g++ -g -Wall main.o libtoto.o -o tototest
même s'il n'y a rien dans le 'main' qui indique que l'objet
toto est utilisé ?