Bonjour à tous,
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 templ ates,
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 plug in
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 ?
Tu ne peux pas, parce que typiquement une version de la STL est liée
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 ?
Par défaut, tous les symboles présents sont exportés de la
Bonjour à tous,
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 templ ates,
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 plug in
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 ?
Tu ne peux pas, parce que typiquement une version de la STL est liée
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 ?
Par défaut, tous les symboles présents sont exportés de la
Bonjour à tous,
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 templ ates,
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 plug in
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 ?
Tu ne peux pas, parce que typiquement une version de la STL est liée
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 ?
Par défaut, tous les symboles présents sont exportés de la
Par défaut, tous les symboles présents sont exportés de la
librairie.
Par défaut, tous les symboles présents sont exportés de la
librairie.
Par défaut, tous les symboles présents sont exportés de la
librairie.
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 ?
Tu ne peux pas, parce que typiquement une version de la STL est liée
à un compilateur donné. De toute façon, comme une très grosse
partie de la STL est typiquement en template, le code se retrouve
inliné dans chaque module.
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 ?
Tu ne peux pas, parce que typiquement une version de la STL est liée
à un compilateur donné. De toute façon, comme une très grosse
partie de la STL est typiquement en template, le code se retrouve
inliné dans chaque module.
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 ?
Tu ne peux pas, parce que typiquement une version de la STL est liée
à un compilateur donné. De toute façon, comme une très grosse
partie de la STL est typiquement en template, le code se retrouve
inliné dans chaque module.
Tout ça pour dire que template et dll, c'est pas une bonne idée. Mais je
crois que Arnaud te l'avait fait comprendre :-)
Tout ça pour dire que template et dll, c'est pas une bonne idée. Mais je
crois que Arnaud te l'avait fait comprendre :-)
Tout ça pour dire que template et dll, c'est pas une bonne idée. Mais je
crois que Arnaud te l'avait fait comprendre :-)
Espérons que la prochaine mouture de la norme définira de manière formelle
la notion de module. Ca me semble une 1ère étape indispensable si on veut
espérer voire un jour des DLLs compatibles entre vendeurs/compilateurs avec
une API C++.
Espérons que la prochaine mouture de la norme définira de manière formelle
la notion de module. Ca me semble une 1ère étape indispensable si on veut
espérer voire un jour des DLLs compatibles entre vendeurs/compilateurs avec
une API C++.
Espérons que la prochaine mouture de la norme définira de manière formelle
la notion de module. Ca me semble une 1ère étape indispensable si on veut
espérer voire un jour des DLLs compatibles entre vendeurs/compilateurs avec
une API C++.
Arnaud Debaene wrote on 06/07/2006 20:27:
Espérons que la prochaine mouture de la norme définira de manière
formelle la notion de module. Ca me semble une 1ère étape indispensable
si on veut espérer voire un jour des DLLs compatibles entre
vendeurs/compilateurs avec une API C++.
je ne suis pas sur qu'elle le puisse (ou qu'elle intégre ce "souci" dans
son périmêtre) - les mêmes différences existent entre un fichier dll et so
qu'entre un exe (µcrosoft) et un binaire unix (binaire_s_).
par ailleurs, si un système normalisé de chargement dynamique existait, il
devrait (pourrait) ne pas être lié au langage source; .net prétends cela à
un prix discutable, OLE/COM était plus pragmatique mais n'a pas donné
grand chose (les autres approches type OpenDoc d'Apple non plus...).
Arnaud Debaene wrote on 06/07/2006 20:27:
Espérons que la prochaine mouture de la norme définira de manière
formelle la notion de module. Ca me semble une 1ère étape indispensable
si on veut espérer voire un jour des DLLs compatibles entre
vendeurs/compilateurs avec une API C++.
je ne suis pas sur qu'elle le puisse (ou qu'elle intégre ce "souci" dans
son périmêtre) - les mêmes différences existent entre un fichier dll et so
qu'entre un exe (µcrosoft) et un binaire unix (binaire_s_).
par ailleurs, si un système normalisé de chargement dynamique existait, il
devrait (pourrait) ne pas être lié au langage source; .net prétends cela à
un prix discutable, OLE/COM était plus pragmatique mais n'a pas donné
grand chose (les autres approches type OpenDoc d'Apple non plus...).
Arnaud Debaene wrote on 06/07/2006 20:27:
Espérons que la prochaine mouture de la norme définira de manière
formelle la notion de module. Ca me semble une 1ère étape indispensable
si on veut espérer voire un jour des DLLs compatibles entre
vendeurs/compilateurs avec une API C++.
je ne suis pas sur qu'elle le puisse (ou qu'elle intégre ce "souci" dans
son périmêtre) - les mêmes différences existent entre un fichier dll et so
qu'entre un exe (µcrosoft) et un binaire unix (binaire_s_).
par ailleurs, si un système normalisé de chargement dynamique existait, il
devrait (pourrait) ne pas être lié au langage source; .net prétends cela à
un prix discutable, OLE/COM était plus pragmatique mais n'a pas donné
grand chose (les autres approches type OpenDoc d'Apple non plus...).
Arnaud Debaene wrote on 06/07/2006 20:27:Espérons que la prochaine mouture de la norme définira de
manière formelle la notion de module. Ca me semble une 1ère
étape indispensable si on veut espérer voire un jour des
DLLs compatibles entre vendeurs/compilateurs avec une API
C++.
je ne suis pas sur qu'elle le puisse (ou qu'elle intégre ce
"souci" dans son périmêtre) - les mêmes différences existent
entre un fichier dll et so qu'entre un exe (µcrosoft) et un
binaire unix (binaire_s_).
par ailleurs, si un système normalisé de chargement dynamique
existait, il devrait (pourrait) ne pas être lié au langage
source;
.net prétends cela à un prix discutable, OLE/COM était
plus pragmatique mais n'a pas donné grand chose (les autres
approches type OpenDoc d'Apple non plus...).
Arnaud Debaene wrote on 06/07/2006 20:27:
Espérons que la prochaine mouture de la norme définira de
manière formelle la notion de module. Ca me semble une 1ère
étape indispensable si on veut espérer voire un jour des
DLLs compatibles entre vendeurs/compilateurs avec une API
C++.
je ne suis pas sur qu'elle le puisse (ou qu'elle intégre ce
"souci" dans son périmêtre) - les mêmes différences existent
entre un fichier dll et so qu'entre un exe (µcrosoft) et un
binaire unix (binaire_s_).
par ailleurs, si un système normalisé de chargement dynamique
existait, il devrait (pourrait) ne pas être lié au langage
source;
.net prétends cela à un prix discutable, OLE/COM était
plus pragmatique mais n'a pas donné grand chose (les autres
approches type OpenDoc d'Apple non plus...).
Arnaud Debaene wrote on 06/07/2006 20:27:Espérons que la prochaine mouture de la norme définira de
manière formelle la notion de module. Ca me semble une 1ère
étape indispensable si on veut espérer voire un jour des
DLLs compatibles entre vendeurs/compilateurs avec une API
C++.
je ne suis pas sur qu'elle le puisse (ou qu'elle intégre ce
"souci" dans son périmêtre) - les mêmes différences existent
entre un fichier dll et so qu'entre un exe (µcrosoft) et un
binaire unix (binaire_s_).
par ailleurs, si un système normalisé de chargement dynamique
existait, il devrait (pourrait) ne pas être lié au langage
source;
.net prétends cela à un prix discutable, OLE/COM était
plus pragmatique mais n'a pas donné grand chose (les autres
approches type OpenDoc d'Apple non plus...).
Bonjour à tous,
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
Bonjour à tous,
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
Bonjour à tous,
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 wrote:Bonjour à tous,
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
Bonjour à tous,
merci beaucoup pour toutes vos réponses. Il y a donc quelques
possibilités à ma disposition :
- forcer à recompiler l'ensemble (car le logiciel est opensource)
- maintenir l'interface C++ en forçant l'utilisation d'un compilateur
avec des options fixes pour recompiler les plugins pour l'applicatif
précompilé
- utiliser des méthodes propres à chaque compilateurs et donc non
normalisé pour avoir quelque chose de valable mais non portable.
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) ?
A+ tard,
Yann - en vacances donc pas de réponses dans les jours à venir
Yann Renard wrote:
Bonjour à tous,
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
Bonjour à tous,
merci beaucoup pour toutes vos réponses. Il y a donc quelques
possibilités à ma disposition :
- forcer à recompiler l'ensemble (car le logiciel est opensource)
- maintenir l'interface C++ en forçant l'utilisation d'un compilateur
avec des options fixes pour recompiler les plugins pour l'applicatif
précompilé
- utiliser des méthodes propres à chaque compilateurs et donc non
normalisé pour avoir quelque chose de valable mais non portable.
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) ?
A+ tard,
Yann - en vacances donc pas de réponses dans les jours à venir
Yann Renard wrote:Bonjour à tous,
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
Bonjour à tous,
merci beaucoup pour toutes vos réponses. Il y a donc quelques
possibilités à ma disposition :
- forcer à recompiler l'ensemble (car le logiciel est opensource)
- maintenir l'interface C++ en forçant l'utilisation d'un compilateur
avec des options fixes pour recompiler les plugins pour l'applicatif
précompilé
- utiliser des méthodes propres à chaque compilateurs et donc non
normalisé pour avoir quelque chose de valable mais non portable.
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) ?
A+ tard,
Yann - en vacances donc pas de réponses dans les jours à venir
connaissez vous d'autres directives
de ce genre pour d'autres compilateurs ?
je vois que mon dernier message n'a pas généré masse de réponses
connaissez vous d'autres directives
de ce genre pour d'autres compilateurs ?
je vois que mon dernier message n'a pas généré masse de réponses
connaissez vous d'autres directives
de ce genre pour d'autres compilateurs ?
je vois que mon dernier message n'a pas généré masse de réponses