Discussion :

[screetch]

[EDIT 3DArchi] Suite à cette discussion [/EDIT]

je n'ai pas compris... pourquoi ne pas exporter des classes ?

[Mac LAK]

je n'ai pas compris... pourquoi ne pas exporter des classes ?

Tu importes tes classes comment en VB, par exemple ? Ou en Delphi, ou Fortran, ou tout autre langage qui n'est pas du C++ ?
Autre point "rigolo" : GCC et Visual n'utilisent pas les mêmes conventions pour le mangling => tu résouds ça comment ?

Une DLL "correcte", c'est uniquement des fonctions à l'export, toutes en convention d'appel stdcall, et bien sûr sans aucune décoration. Tu noteras d'ailleurs que c'est le cas de quasiment toutes les DLL système de Windows.


EDIT : Et en plus, dans un cas pareil, tu peux assurer au maximum un link JIT de la DLL en question, greffer un stub en lieu et place si elle est absente, bref avoir une gestion correcte de la présence/absence de la DLL et/ou des évolutions de version.

[screetch]

ah ok je vois

[Médinoc]

Et si tu veux toujours faire de l'orienté objet avec ça, il reste l'option de faire une DLL COM.

[screetch]

et en portable ?

[Médinoc]

Il n'y a pas de DLL en portable de toute façon. Je ne sais pas comment les SO marchent, peut-être ont-ils un mécanisme similaire à l'importation statique retardée...

[Mac LAK]

et en portable ?

Pas de portabilité, là on parle d'éléments natifs du système. Le mot "portable" n'existe même pas à ce stade !

Tu peux avoir des librairies d'encapsulation de ces mécanismes, permettant d'avoir "tout comme", mais cela demande à utiliser ces mécanismes justement. Par exemple, POCO fournit une API de type plugin qui permet effectivement d'avoir des équivalents de DLL JIT, mais ça t'oblige à développer ta DLL suivant cette architecture (donc, mort pour les DLL déjà existantes dont tu n'as pas les sources).

Pour les SO, il existe dlopen qui joue le même rôle que LoadLibrary sous Windows.

[screetch]

nan mais je connais mais je ne vois pas bien le rapport la
je ne comprends pas

exporter des classes et non des fonctions depuis une dll, c'est s'exposer à de grandes déconvenues.

Qt exporte bien des classes, ca marche. Et c'est pas la seule bibliotheque C++ du monde quand meme. du coup je ne comprend pas bien vos reflexions sur les Dll

[bacelar]

Essayez d'utiliser une autre C-Runtime que celle utilisée lors de la compilation de la lib Qt.
Essayez d'utiliser un autre compilateur que celui utilisé lors de la compilation de la lib Qt.
etc....

[3DArchi]

Bonjour,
Une petite lecture qui pourra te guider : Calling conventions for different C++ compilers and operating systems de Agner Fog. Copenhagen University College of Engineering.

[screetch]

mais la c'est plus du tout le probleme original, le probleme original etait qu'une DLL ne se charge pas sous Vista mais se charge sous Xp.
Le langage de la DLL n'a rien a voir avec ca.... a mon avis

[3DArchi]

nan mais je connais mais je ne vois pas bien le rapport la
je ne comprends pas


Qt exporte bien des classes, ca marche. Et c'est pas la seule bibliotheque C++ du monde quand meme. du coup je ne comprend pas bien vos reflexions sur les Dll

mais la c'est plus du tout le probleme original, le probleme original etait qu'une DLL ne se charge pas sous Vista mais se charge sous Xp.
Le langage de la DLL n'a rien a voir avec ca.... a mon avis

[Mac LAK]

mais la c'est plus du tout le probleme original, le probleme original etait qu'une DLL ne se charge pas sous Vista mais se charge sous Xp.
Le langage de la DLL n'a rien a voir avec ca.... a mon avis

Les DLL système de Vista ne sont pas totalement les mêmes que celles d'XP, pour commencer, et tu peux encore plus rigoler si tu changes de compilateur, de runtimes C/C++, etc.

Bref, ça a tout à voir au contraire : tu ne peux garantir une importation correcte d'une classe QUE si tu compiles avec la même chaîne de développement la DLL et le programme qui l'utilise... Et que tu prévois, bien sûr, la portabilité au niveau des différentes versions de ton OS (ne pas appeler des fonctions spécifiques Vista et espérer que ça marche sous XP, par exemple, ou utiliser des fonctions "deprecated" sur un vieil OS et s'étonner que ça plante sur un nouveau OS).

[screetch]

Les DLL système de Vista ne sont pas totalement les mêmes que celles d'XP, pour commencer, et tu peux encore plus rigoler si tu changes de compilateur, de runtimes C/C++, etc.

les DLL de l'OS ne sont pas ecrites en C++ je ne vois pas ce que le langage de la DLL vient faire la dedans
a mon avis les DLL de visual studio n'ont pas été redistribuées, il faudrait s'inquieter de savoir pourquoi la DLL ne se charge pas dans un premier temps. Il y a plus de chances que ce soit un probleme de redistribution du runtime C++ (qui ne fait pas partie de l'OS)

encore une fois, le fait que ce soit une DLL en C++ qui ne se charge pas, raf

[Mac LAK]

les DLL de l'OS ne sont pas ecrites en C++ je ne vois pas ce que le langage de la DLL vient faire la dedans

La majorité des DLL de l'OS, pas "toutes".
Notamment, MSVCRT.DLL possède plusieurs exports C++ par exemple, tout comme COMSETUP.DLL, ADSLDPC.DLL, et sûrement pas mal d'autres (mais je n'ai cherché qu'une minute aussi).
Essaie de linker les éléments C++ de ces DLL avec, par exemple, un programme compilé avec GCC et tu comprendras mieux.

encore une fois, le fait que ce soit une DLL en C++ qui ne se charge pas, raf

Cela reste une très mauvaise pratique en soi d'exporter directement tes classes (ou des variables globales) depuis tes DLL. OK, ça modularise ton projet, mais ça ne rend en aucune façon tes DLL réellement réutilisables comme elles devraient l'être. Tu te coupes de la portabilité inter-langages, voire inter-compilateurs.

[screetch]

devoir coder en C pour la portabilité inter langage ca brise un peu le côté inter langage quand meme.

je veux avoir la preuve que cette DLL utilise des appels systemes de l'OS non supportés. comme cité plus haut, je parie a 99% que ca ne depend pas de l'OS mais qu'il manque une dépendance (le runtime Visual C++ 2005 a 98%)

MSVCRT.DLL est la DLL du runtime C++ de visual studio. Forcément, oui, elle contient un certain nombre d'appels au C++

[Médinoc]

Ce n'est pas "devoir coder en C", mais "avoir une interface C". Et encore, "avoir une interface VB" serait plus juste.

On peut tout-à-fait exposer des fonctions développées en C++, du moment qu'elles peuvent être appelées depuis le C (en clair, pas de types C++ en paramètre, déclaration extern "C"), et qu'elles utilisent la convention d'appel __stdcall (pour être compatible avec les autres langages). Ensuite, il est préférable que les noms ne soient pas décorés, mais s'ils ont une décoration C, ça n'est pas trop grave (.Net et VB ont les bonnes options pour contourner cela, et je pense que beaucoup d'autres langages aussi).

On peut aussi, si on le fait bien, exposer des fonctions retournant des pointeurs vers des classes C++ abstraites. C'est le cas pour les DLLs COM implémentées en C++...

[bacelar]

54 symbols C++ exporté sur 829, tous en lien direct ou indirect avec le RTTI.

Donc c'est fait par NECESSITE, pas pour simplification ou "utilisabilité".

[3DArchi]

Ce n'est pas "devoir coder en C", mais "avoir une interface C". Et encore, "avoir une interface VB" serait plus juste.

On peut tout-à-fait exposer des fonctions développées en C++, du moment qu'elles peuvent être appelées depuis le C (en clair, pas de types C++ en paramètre, déclaration extern "C"), et qu'elles utilisent la convention d'appel __stdcall (pour être compatible avec les autres langages). Ensuite, il est préférable que les noms ne soient pas décorés, mais s'ils ont une décoration C, ça n'est pas trop grave (.Net et VB ont les bonnes options pour contourner cela, et je pense que beaucoup d'autres langages aussi).

On peut aussi, si on le fait bien, exposer des fonctions retournant des pointeurs vers des classes C++ abstraites. C'est le cas pour les DLLs COM implémentées en C++...

Salut,
Le coeur du problème, c'est pas la convention d'appel ? La décoration n'étant qu'une difficulté supplémentaire mais peut être plus facilement contournable. Non ?

[Médinoc]

À ma connaissance, on ne peux pas changer le nom d'exportation d'une méthode de classe C++. Alors que sa convention d'appel, on peut la forcer.

Pour les fonctions isolées par contre, ce doit être l'inverse. En VB, on doit pouvoir contourner tout problème de nommage, mais la convention d'appel doit être __stdcall.

MSVCR90 a 65 symboles C++ sur 1451, tous liés à des trucs spécifiques au compilateur et qui ne peuvent être que là: RTTI, gestionnaires d'erreurs C++, etc.
Par contre, MSCVP90 contient la STL de Visual, et exporte 3110 symboles C++.

Dans tous les cas, ces deux DLLs sont spécifiques à Visual, et même à cette version de Visual, et n'ont jamais été censées être portables.