Il y a peu de temps, je ne me posais pas cette question...Envoyé par David.Schris
Thierry
Il y a peu de temps, je ne me posais pas cette question...Envoyé par David.Schris
Thierry
Bizarre, très bizarre...
Quelle version du compilateur et du linker ?
N'oublions pas que la série des Visual C++ ne date pas d'hier...
De plus, il est possible que ça survienne qu'en C++, mais il me semble que les fonctions C sont quand même préfixées avec __imp_ dans la bibliothèque statique d'importation...
Edit: Tu es sûr que ça marche ? Tes commandes ne créent pas test.obj...
Edit2: Mince, j'ai testé en corrigeant les commandes et ça marche quand même (VS2005)
Edit3: Avec Visual 6 aussi.
Conclusion : Il est possible que ce soit un héritage des anciens Visual, ou bien que ça n'ait qu'une fonction documentaire: Si l'édition de lien échoue, le nom de la fonction montrera parfaitement que c'est une lib statique d'importation qui manque et non une lib statique classique.
Edit: Ou encore ça devient problématique en C++.
J'ai utilisé le compilateur de Visual C++ 2005 Professionnal, et j'ai testé plusieurs fois. De toute manière, cela ne me pose aucun problème de le mettre, je l'ai toujours fait et ne m'étais jamais posé ces questions avant. Il semble que l'éditeur de liens repère automatiquement si il a à faire avec une bibliothèque statique ou une bibliothèque d'importation.Envoyé par Médinoc
Thierry
Du nouveau en faveur de l'utilité en C++ :
Edit: Je viens de tester la compilation des sources en tant que C++ (visual 6), et pour les fonctions, ça marche toujours sans DllImport.Envoyé par MSDN
Il faudra essayer avec des classes quand on aura le temps...
Ce poste est à nouveau ouvert afin de discuter de la nécessité de __declspec(dllimport) lors de l'utilisation d'une DLL, des mécanismes sous-jascents, etc.
Meilleures salutations
Thierry
Ce que je sais pour sûr, c'est que le nom décoré n'est pas le même :
Avec dllimport, la fonction C __cdecl aucarre() s'appelle __imp_aucarre() au lieu de _aucarre().
De plus, un coup d'éditeux hexa sur le .lib indique qu'il contient les deux noms, en plusieurs exemplaires. Mais de là à savoir à quoi ils correspondent exactement, sachant que le nom dans la DLL n'est pas modifié : c'est toujours _aucarre() (voire même aucarre() j'ai eu l'impression, pour certains programmes où j'utiliais GetProcAddress() sur des DLLs perso).
S'il est possible de générer du code assembleur, cela doit être facile à vérifier. Je n'ai malheureusement accès à aucun système Windows dans l'immédiat pour y jeter un coup d'oeil... D'autres avis sur le sujet seront bienvenus, parce que là, je sèche!Envoyé par Médinoc
Thierry
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager