le projet sur lequel je bosse en ce moment doit permettre le chargement
de plugins à l'exécution. Je suis en train de définir l'interface
qu'auront ces plugins et comment ceux ci devront communiquer avec mon
application principale (je crée un SDK quoi...). Et je me pose le
problème suivant : étant donné que la STL est basée sur des templates,
dois je retirer toute classe de la STL de mon interface ?
La raison pour laquelle je me pose ce problème est peut être fausse, je
n'en suis pas certain ; nous espérons mettre en place une communauté de
développeurs autour de notre logiciel pour développer les plugins.
Chaque développeur utilisera son compilateur, sa version de compilateur
ainsi que ses options de compilations, du moment qu'il respecte
l'interface mise à disposition. Mais la STL étant basée sur les
templates, cela veut dire que le code compilé par le développeur plugin
et celui compilé par le développeur de l'application pourront différer
légèrement (réorganisation des membres en mémoire, optimisations
diverses etc...), résultant en de probables bugs au runtime.
D'autre part, si la STL ne doit pas être retirée de l'interface, je me
pose le problème suivant : la STL étant plus une "spécification" qu'une
librairie, devrais je redistribuer une version de la STL utilisée dans
l'application aux développeurs de plugins pour qu'ils soient synchros ?
Pour finir, et un peu hors sujet, lorsqu'on compile sous windows, les
directives dllimport et dllexport permettent d'informer le compilateur
que les classes/membres seront exposées dans la dll et qu'il ne faut pas
les optimiser. Mais ce genre de directive, sauf erreur de ma part,
n'existe pas avec GCC pour créer des .so Qu'en est il alors de ce genre
de problèmes sous linux ?
Merci d'avance à tous,
Bonne journée
Yann Renard
--
Yann Renard - To send me an email, remove no-spam sectionS :)
connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? Dois je comprendre que personne ne peut y répondre (par un "oui voici"
bien entendu) ?
bcp ont pu se dire "oui" (mentalement).
Sylvain.
Loïc Joly
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
-- Loïc
pour ce dernier point, je connais déjà les dllimport et dllexport de
visual ; est ce que ces directives fonctionnent aussi avec les autres
compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous
d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous
linux m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?),
il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
-- Loïc
kanze
Loïc Joly wrote:
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique. Aussi, on peut dire lors du chargement même de ne rien importer sauf ce qu'on démande explicitement.
C'est une autre philosophie, et ça exige parfois une approche différente.
-- 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
Loïc Joly wrote:
pour ce dernier point, je connais déjà les dllimport et
dllexport de visual ; est ce que ces directives fonctionnent
aussi avec les autres compilateurs windows (gcc, borland c++
builder etc...) ? connaissez vous d'autres directives de ce
genre pour d'autres compilateurs ? (gcc sous linux
m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente
(laquelle ?), il permet de n'exporter que ce qui est déclaré,
mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il
tourne ? Sous Unix, il est habituel d'exporter tout lors de la
compilation, quitte à dire à l'éditeur de liens de ne pas
exporter certaines choses quand on crée l'objet dynamique.
Aussi, on peut dire lors du chargement même de ne rien importer
sauf ce qu'on démande explicitement.
C'est une autre philosophie, et ça exige parfois une approche
différente.
--
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
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique. Aussi, on peut dire lors du chargement même de ne rien importer sauf ce qu'on démande explicitement.
C'est une autre philosophie, et ça exige parfois une approche différente.
-- 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
Loïc Joly
Loïc Joly wrote:
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique.
Je ne crois pas. C'était suite à des remarques comme quoi, dans certains .so, la table des symboles devenait très grosse pour pas grand'chose, et ça avait un impact sur les perfs. Par contre, n'utilisant pas gcc moi-même, je n'en sais pas vraiment plus.
-- Loïc
Loïc Joly wrote:
Par défaut, gcc exporte tout. Depuis une version récente
(laquelle ?), il permet de n'exporter que ce qui est déclaré,
mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il
tourne ? Sous Unix, il est habituel d'exporter tout lors de la
compilation, quitte à dire à l'éditeur de liens de ne pas
exporter certaines choses quand on crée l'objet dynamique.
Je ne crois pas. C'était suite à des remarques comme quoi, dans certains
.so, la table des symboles devenait très grosse pour pas grand'chose, et
ça avait un impact sur les perfs. Par contre, n'utilisant pas gcc
moi-même, je n'en sais pas vraiment plus.
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique.
Je ne crois pas. C'était suite à des remarques comme quoi, dans certains .so, la table des symboles devenait très grosse pour pas grand'chose, et ça avait un impact sur les perfs. Par contre, n'utilisant pas gcc moi-même, je n'en sais pas vraiment plus.
-- Loïc
Gabriel Dos Reis
Loïc Joly writes:
| > Loïc Joly wrote: | | >>Par défaut, gcc exporte tout. Depuis une version récente | >>(laquelle ?), il permet de n'exporter que ce qui est déclaré, | >>mais je n'en sais pas plus. | > Est-ce que ça ne dépendrait pas du système sur lequel il | > tourne ? Sous Unix, il est habituel d'exporter tout lors de la | > compilation, quitte à dire à l'éditeur de liens de ne pas | > exporter certaines choses quand on crée l'objet dynamique. | | Je ne crois pas. C'était suite à des remarques comme quoi, dans | certains .so, la table des symboles devenait très grosse pour pas | grand'chose, et ça avait un impact sur les perfs.
et aussi pour limiter l'interface binaire au minimum.
C'est un exercice assez délicat vu le modèle de compilation de GCC à l'heure actuelle.
| > Loïc Joly wrote:
|
| >>Par défaut, gcc exporte tout. Depuis une version récente
| >>(laquelle ?), il permet de n'exporter que ce qui est déclaré,
| >>mais je n'en sais pas plus.
| > Est-ce que ça ne dépendrait pas du système sur lequel il
| > tourne ? Sous Unix, il est habituel d'exporter tout lors de la
| > compilation, quitte à dire à l'éditeur de liens de ne pas
| > exporter certaines choses quand on crée l'objet dynamique.
|
| Je ne crois pas. C'était suite à des remarques comme quoi, dans
| certains .so, la table des symboles devenait très grosse pour pas
| grand'chose, et ça avait un impact sur les perfs.
et aussi pour limiter l'interface binaire au minimum.
C'est un exercice assez délicat vu le modèle de compilation de GCC à
l'heure actuelle.
| > Loïc Joly wrote: | | >>Par défaut, gcc exporte tout. Depuis une version récente | >>(laquelle ?), il permet de n'exporter que ce qui est déclaré, | >>mais je n'en sais pas plus. | > Est-ce que ça ne dépendrait pas du système sur lequel il | > tourne ? Sous Unix, il est habituel d'exporter tout lors de la | > compilation, quitte à dire à l'éditeur de liens de ne pas | > exporter certaines choses quand on crée l'objet dynamique. | | Je ne crois pas. C'était suite à des remarques comme quoi, dans | certains .so, la table des symboles devenait très grosse pour pas | grand'chose, et ça avait un impact sur les perfs.
et aussi pour limiter l'interface binaire au minimum.
C'est un exercice assez délicat vu le modèle de compilation de GCC à l'heure actuelle.
-- Gaby
espie
In article , kanze wrote:
Loïc Joly wrote:
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique. Aussi, on peut dire lors du chargement même de ne rien importer sauf ce qu'on démande explicitement.
Non, c'est effectivement une modification recente. Le flag s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Et donc ca doit etre dans gcc 4.0 et ulterieur, et pas les precedents.
Certains gros projets C++, kde et mozilla en tete, s'en servent lorsqu'ils le detectent. Et ca doit faire une difference notable...
In article <1155722824.639728.167280@74g2000cwt.googlegroups.com>,
kanze <kanze@gabi-soft.fr> wrote:
Loïc Joly wrote:
pour ce dernier point, je connais déjà les dllimport et
dllexport de visual ; est ce que ces directives fonctionnent
aussi avec les autres compilateurs windows (gcc, borland c++
builder etc...) ? connaissez vous d'autres directives de ce
genre pour d'autres compilateurs ? (gcc sous linux
m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente
(laquelle ?), il permet de n'exporter que ce qui est déclaré,
mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il
tourne ? Sous Unix, il est habituel d'exporter tout lors de la
compilation, quitte à dire à l'éditeur de liens de ne pas
exporter certaines choses quand on crée l'objet dynamique.
Aussi, on peut dire lors du chargement même de ne rien importer
sauf ce qu'on démande explicitement.
Non, c'est effectivement une modification recente. Le flag
s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Et donc ca doit etre dans gcc 4.0 et ulterieur, et pas les precedents.
Certains gros projets C++, kde et mozilla en tete, s'en servent lorsqu'ils le
detectent. Et ca doit faire une difference notable...
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente (laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique. Aussi, on peut dire lors du chargement même de ne rien importer sauf ce qu'on démande explicitement.
Non, c'est effectivement une modification recente. Le flag s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Et donc ca doit etre dans gcc 4.0 et ulterieur, et pas les precedents.
Certains gros projets C++, kde et mozilla en tete, s'en servent lorsqu'ils le detectent. Et ca doit faire une difference notable...
Gabriel Dos Reis
(Marc Espie) writes:
| In article , | kanze wrote: | >Loïc Joly wrote: | >> > pour ce dernier point, je connais déjà les dllimport et | >> > dllexport de visual ; est ce que ces directives fonctionnent | >> > aussi avec les autres compilateurs windows (gcc, borland c++ | >> > builder etc...) ? connaissez vous d'autres directives de ce | >> > genre pour d'autres compilateurs ? (gcc sous linux | >> > m'intéresse particulièrement) ? | > | >> Par défaut, gcc exporte tout. Depuis une version récente | >> (laquelle ?), il permet de n'exporter que ce qui est déclaré, | >> mais je n'en sais pas plus. | > | >Est-ce que ça ne dépendrait pas du système sur lequel il | >tourne ? Sous Unix, il est habituel d'exporter tout lors de la | >compilation, quitte à dire à l'éditeur de liens de ne pas | >exporter certaines choses quand on crée l'objet dynamique. | >Aussi, on peut dire lors du chargement même de ne rien importer | >sauf ce qu'on démande explicitement. | | Non, c'est effectivement une modification recente. Le flag | s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Yup. C'est aussi requis par le système de Apple.
En tout cas, c'est une formidable pagaille en termes de sémantique de C+++.
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <1155722824.639728.167280@74g2000cwt.googlegroups.com>,
| kanze <kanze@gabi-soft.fr> wrote:
| >Loïc Joly wrote:
| >> > pour ce dernier point, je connais déjà les dllimport et
| >> > dllexport de visual ; est ce que ces directives fonctionnent
| >> > aussi avec les autres compilateurs windows (gcc, borland c++
| >> > builder etc...) ? connaissez vous d'autres directives de ce
| >> > genre pour d'autres compilateurs ? (gcc sous linux
| >> > m'intéresse particulièrement) ?
| >
| >> Par défaut, gcc exporte tout. Depuis une version récente
| >> (laquelle ?), il permet de n'exporter que ce qui est déclaré,
| >> mais je n'en sais pas plus.
| >
| >Est-ce que ça ne dépendrait pas du système sur lequel il
| >tourne ? Sous Unix, il est habituel d'exporter tout lors de la
| >compilation, quitte à dire à l'éditeur de liens de ne pas
| >exporter certaines choses quand on crée l'objet dynamique.
| >Aussi, on peut dire lors du chargement même de ne rien importer
| >sauf ce qu'on démande explicitement.
|
| Non, c'est effectivement une modification recente. Le flag
| s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Yup. C'est aussi requis par le système de Apple.
En tout cas, c'est une formidable pagaille en termes de sémantique de C+++.
| In article , | kanze wrote: | >Loïc Joly wrote: | >> > pour ce dernier point, je connais déjà les dllimport et | >> > dllexport de visual ; est ce que ces directives fonctionnent | >> > aussi avec les autres compilateurs windows (gcc, borland c++ | >> > builder etc...) ? connaissez vous d'autres directives de ce | >> > genre pour d'autres compilateurs ? (gcc sous linux | >> > m'intéresse particulièrement) ? | > | >> Par défaut, gcc exporte tout. Depuis une version récente | >> (laquelle ?), il permet de n'exporter que ce qui est déclaré, | >> mais je n'en sais pas plus. | > | >Est-ce que ça ne dépendrait pas du système sur lequel il | >tourne ? Sous Unix, il est habituel d'exporter tout lors de la | >compilation, quitte à dire à l'éditeur de liens de ne pas | >exporter certaines choses quand on crée l'objet dynamique. | >Aussi, on peut dire lors du chargement même de ne rien importer | >sauf ce qu'on démande explicitement. | | Non, c'est effectivement une modification recente. Le flag | s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Yup. C'est aussi requis par le système de Apple.
En tout cas, c'est une formidable pagaille en termes de sémantique de C+++.
-- Gaby
Yann Renard
Marc Espie wrote:
In article , kanze wrote:
Loïc Joly wrote:
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ? Par défaut, gcc exporte tout. Depuis une version récente
(laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus. Est-ce que ça ne dépendrait pas du système sur lequel il
tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique. Aussi, on peut dire lors du chargement même de ne rien importer sauf ce qu'on démande explicitement.
Non, c'est effectivement une modification recente. Le flag s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Et donc ca doit etre dans gcc 4.0 et ulterieur, et pas les precedents.
Certains gros projets C++, kde et mozilla en tete, s'en servent lorsqu'ils le detectent. Et ca doit faire une difference notable...
Effectivement, j'ai trouvé d'excellentes choses là :
ce qui fait donc mon affaire pour le moment, même si cela ne fait pas partie de la norme.
Merci Yann
Marc Espie wrote:
In article <1155722824.639728.167280@74g2000cwt.googlegroups.com>,
kanze <kanze@gabi-soft.fr> wrote:
Loïc Joly wrote:
pour ce dernier point, je connais déjà les dllimport et
dllexport de visual ; est ce que ces directives fonctionnent
aussi avec les autres compilateurs windows (gcc, borland c++
builder etc...) ? connaissez vous d'autres directives de ce
genre pour d'autres compilateurs ? (gcc sous linux
m'intéresse particulièrement) ?
Par défaut, gcc exporte tout. Depuis une version récente
(laquelle ?), il permet de n'exporter que ce qui est déclaré,
mais je n'en sais pas plus.
Est-ce que ça ne dépendrait pas du système sur lequel il
tourne ? Sous Unix, il est habituel d'exporter tout lors de la
compilation, quitte à dire à l'éditeur de liens de ne pas
exporter certaines choses quand on crée l'objet dynamique.
Aussi, on peut dire lors du chargement même de ne rien importer
sauf ce qu'on démande explicitement.
Non, c'est effectivement une modification recente. Le flag
s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Et donc ca doit etre dans gcc 4.0 et ulterieur, et pas les precedents.
Certains gros projets C++, kde et mozilla en tete, s'en servent lorsqu'ils le
detectent. Et ca doit faire une difference notable...
Effectivement, j'ai trouvé d'excellentes choses là :
pour ce dernier point, je connais déjà les dllimport et dllexport de visual ; est ce que ces directives fonctionnent aussi avec les autres compilateurs windows (gcc, borland c++ builder etc...) ? connaissez vous d'autres directives de ce genre pour d'autres compilateurs ? (gcc sous linux m'intéresse particulièrement) ? Par défaut, gcc exporte tout. Depuis une version récente
(laquelle ?), il permet de n'exporter que ce qui est déclaré, mais je n'en sais pas plus. Est-ce que ça ne dépendrait pas du système sur lequel il
tourne ? Sous Unix, il est habituel d'exporter tout lors de la compilation, quitte à dire à l'éditeur de liens de ne pas exporter certaines choses quand on crée l'objet dynamique. Aussi, on peut dire lors du chargement même de ne rien importer sauf ce qu'on démande explicitement.
Non, c'est effectivement une modification recente. Le flag s'appelle -fvisibility, ca date de juillet 2004, plus precisement.
Et donc ca doit etre dans gcc 4.0 et ulterieur, et pas les precedents.
Certains gros projets C++, kde et mozilla en tete, s'en servent lorsqu'ils le detectent. Et ca doit faire une difference notable...
Effectivement, j'ai trouvé d'excellentes choses là :
