Question sur les DLL de l'Exportation/l'Importation et à l'Externe sur Windows

Hey les gars, j'ai quelques questions rapides sur les dll de windows.

Fondamentalement, je suis en utilisant le ifdefs pour gérer la dllexport et dllimport, ma question est en fait concernant le placement de la dllexports et dllimports ainsi que le mot-clé extern.

Je suis en train de monter le dllimports/dllexports sur les fichiers d'en-tête, mais dois-je mettre le dllexport et dllimports sur le actuellement à la définition?

Ce sujet pour les typedefs?

Dois-je mettre la dllimport/dllexport en face? comme dans

dllexport typedef map<string, int> st_map

Également en ce qui concerne le mot-clé extern j'ai vu qu'il est utilisé comme ceci:

extern "C" {

dllexport void func1();

}

J'ai également vu qu'il est utilisé comme ceci:

extern dllexport func1();

L'on inclut le "C" et l'autre pas, ma question est quelle est la différence et dois-je l'utiliser? Si je ne dois-je utiliser à la fois pour dllexport et dllimport aussi dois-je utiliser à la fois sur le fichier d'en-tête les déclarations et les définitions?

Mon projet est d'aller à la bibliothèque partagée, il contient plusieurs fichiers de classe qui je veux exporter, certains typdefs je veux exporter et certaines fonctions globales qui je veux également d'exporter le tout dans une dll.

Quelqu'un m'éclairer s'il vous plaît?

EDIT:

Bon, je pense que je vais poster un petit extrait de ce que j'ai fait, également remarquer que je suis la construction de la bibliothèque pour linux et windows, je fais vérifier que:

mydll.h

#ifdef WINDOWS
#   ifdef PSTRUCT_EXPORT
#   define WINLIB __declspec(dllexport)
#   else
#   define WINLIB __declspec(dllimport)
#   endif
#else
#  define WINLIB
#endif

WINLIB void funct1();

Maintenant dans le code source:

mydll.cpp

#define PSTRUCT_EXPORT

void funct1() <---- do i need to add WINLIB in front of it? 
                      Or is doing it in the header enough?

OriginalL'auteur iQ. | 2009-09-17

  1. 7

    Tout d'abord, vous n'avez pas besoin d'importer ou d'exporter des typedefs. Tant qu'ils sont dans les fichiers d'en-tête que les deux côtés de l'utilisation, vous êtes bon. Vous avez besoin d'importer/exporter des fonctions et des définitions de classe.

    Sans doute vous utilisez le même en-tête des fichiers pour l'importation et l'exportation de code, de sorte que vous pourrait faire un makefile magie de définir une macro préprocesseur de chaque côté, puis faire quelque chose comme ceci:

    #if defined( LIBRARY_CODE )
#define MYAPI __declspec(dllexport)
#else
#define MYAPI __declspec(dllimport)
#endif

extern MYAPI void func1();
class MYAPI MyClass {
    ...
};

    Concernant C vs C++ fonctions, vous pouvez le faire:

    #if defined( __cplusplus__ ) //always defined by C++ compilers, never by C
#define _croutine "C"
#else
#define _croutine
#endif

extern _croutine void function_with_c_linkage();

    Assurez-vous que vous importez ce fichier d'en-tête de votre fichier source C++ (qui contient l'implémentation de cette fonction) ou le compilateur ne sait pas à lui donner une liaison C.

    Bon j'ai quelque chose de très similaire, à l'exception de la le mot-clé extern peu. J'ai similaires macros définies dans tous mes fichiers de classe. Donc, l'externe est utilisé pour fournir un soutien pour les compilateurs C? Mon projet est principalement en C++
    dois-je aussi ajouter le dllimport/exportation des états dans la définition?
    La seule raison pour laquelle vous avez besoin de la extern "C" truc c'est que si vous êtes en essayant de lier une fonction C++ à partir du code C. Fondamentalement, vous pouvez ignorer la extern "C" choses jusqu'à ce que vous obtenez des erreurs d'édition de liens.
    Vous pouvez soit #inclure le fichier d'en-tête dans le fichier source ou mettre le dllexport/importer des trucs sur la définition de la fonction. J'ai l'habitude de #inclure le fichier d'en-tête.

    OriginalL'auteur Graeme Perrow

  2. 2
    1. typedefs n'avez PAS besoin d'un dllimport/dllexport, c'est juste une définition
    2. dllimport/dllexport ne sont pas standard, pensez à la définition d'une macro pour d'autres plates-formes/compilateurs
    3. aussi prendre soin de la convention d'appel (cdecl,stdcall,...) utilisés autrement, vous allez rencontrer des problèmes (si vous avez besoin d'être interopérable avec Visual basic utiliser stdcall)
    4. enfermer dans extern "C" de sorte que votre lib peut être utilisé dans les programmes C++, l'utilisation des #ifdef __cplusplus de le garder visible uniquement pour C++.

    Ont un oeil à différentes OpenSource libs. Vous y trouverez de nombreux exemples sur la façon de faire un bon en-tête de la bibliothèque. Il pourrait y avoir des problèmes avec la décoration de nom dans le cas de C++ sans le extern "C".

    La plupart des choses que je suis en train de monter dans le dll sont des classes donc je veux que ce soit compilé principalement en c++ donc je devrais éviter exter "c"?
    Dans ce cas, oui, vous ne devez pas utiliser extern "C". MAIS il faut être conscient qu'en raison de la décoration de nom vous de forcer les autres à utiliser le même compilateur d'utiliser votre lib. Pour éviter cela, vous pouvez fournir une bibliothèque C et un wrapper C++ pour ce qui peut être intégrée en tant que code source du client de projets

    OriginalL'auteur jdehaan