Partage via

#import, directive (C++)

  • Article

Spécifique À C++

Utilisé pour incorporer les informations d'une bibliothèque de types. Le contenu de la bibliothèque de types est converti en classes C++, qui décrivent principalement les interfaces COM.

Syntaxe

#import « filename » [attributs]
nom de<fichier> #import [attributs]

Paramètres

nom_fichier
Spécifie la bibliothèque de types à importer. Le nom de fichier peut être l’un des types suivants :

  • Nom d'un fichier qui contient une bibliothèque de types, par exemple un fichier .olb, .tlb ou .dll. Le mot clé, , file:peut précéder chaque nom de fichier.

  • Progid d'un contrôle dans la bibliothèque de types. Le mot clé, , progid:peut précéder chaque progid. Par exemple :

    #import "progid:my.prog.id.1.5"

    Pour plus d’informations sur les progids, consultez Spécification de l’ID de localisation et du numéro de version.

    Lorsque vous utilisez un compilateur croisé 32 bits sur un système d’exploitation 64 bits, le compilateur ne peut lire que la ruche de Registre 32 bits. Vous pouvez utiliser le compilateur 64 bits natif pour générer et inscrire une bibliothèque de types 64 bits.

  • ID de bibliothèque de la bibliothèque de types. Le mot clé, , libid:peut précéder chaque ID de bibliothèque. Par exemple :

    #import "libid:12341234-1234-1234-1234-123412341234" version("4.0") lcid("9")

    Si vous ne spécifiez version pas ou lcidsi les règles appliquées sont progid: également appliquées à libid:.

  • Fichier exécutable (.exe).

  • Fichier de bibliothèque (.dll) contenant une ressource de bibliothèque de types (par exemple, un fichier .ocx).

  • Document composite contenant une bibliothèque de types.

  • Tout autre format de fichier qui peut être compris par l’API LoadTypeLib .

attributes
Un ou plusieurs attributs #import. Sépare les attributs par un espace ou une virgule. Par exemple :

#import "..\drawctl\drawctl.tlb" no_namespace, raw_interfaces_only

-ou-

#import "..\drawctl\drawctl.tlb" no_namespace raw_interfaces_only

Notes

Ordre de recherche pour le nom de fichier

le nom de fichier est éventuellement précédé d’une spécification de répertoire. Le nom de fichier doit désigner un fichier existant. La différence entre les deux formes de syntaxe provient de l'ordre dans lequel le préprocesseur recherche les fichiers de bibliothèque de type lorsque le chemin d'accès est spécifié de manière incomplète.

Forme syntaxique Action
Forme avec guillemets Indique au préprocesseur de rechercher d’abord les fichiers de bibliothèque de types dans le répertoire du fichier qui contient l’instruction #import , puis dans les répertoires des fichiers inclus (#include) ce fichier. Le préprocesseur explore ensuite les chemins d’accès spécifiés ci-dessous.
Forme avec crochets pointus Indique au préprocesseur de rechercher les fichiers bibliothèques de types en utilisant les chemins d’accès suivants :

1. Liste de PATH chemins d’accès des variables d’environnement
2. Liste des LIB chemins d’accès des variables d’environnement
3. Chemin d’accès spécifié par l’option du compilateur /I , sauf qu’il recherche une bibliothèque de types référencée à partir d’une autre bibliothèque de types avec l’attribut no_registry .

Spécifier l’ID de localisation et le numéro de version

Lorsque vous spécifiez un progid, vous pouvez également spécifier l'ID de localisation et le numéro de version du progid. Par exemple :

#import "progid:my.prog.id" lcid("0") version("4.0)

Si vous ne spécifiez pas d’ID de localisation, un progid est choisi conformément aux règles suivantes :

  • S’il n’existe qu’un seul ID de localisation, celui-ci est utilisé.

  • S’il existe plusieurs ID de localisation, le premier avec le numéro de version 0, 9 ou 409 est utilisé.

  • S’il existe plusieurs ID de localisation et qu’aucun d’entre eux n’est 0, 9 ou 409, le dernier est utilisé.

  • Si vous ne spécifiez pas de numéro de version, la version la plus récente est utilisée.

Fichiers d’en-tête créés par l’importation

#import crée deux fichiers d’en-tête qui reconstruitnt le contenu de la bibliothèque de types dans le code source C++. Le fichier d’en-tête principal est similaire à celui produit par le compilateur MIDL (Microsoft Interface Definition Language), mais avec du code et des données générés par le compilateur supplémentaires. Le fichier d’en-tête principal a le même nom de base que la bibliothèque de types, plus un . Extension TLH. Le fichier d’en-tête secondaire possède le même nom de base que la bibliothèque de types, avec une extension .TLI. Il contient les implémentations des fonctions membres générées par le compilateur, et est inclus (#include) dans le fichier d'en-tête principal.

Si vous importez une propriété dispinterface qui utilise byref des paramètres, #import ne génère pas d’instruction __declspec(property) pour la fonction.

Les deux fichiers d’en-tête sont placés dans le répertoire de sortie spécifié par l’option /Fo (fichier objet name). Ils sont ensuite lus et compilés par le compilateur comme si le fichier d’en-tête principal a été nommé par une #include directive.

Les optimisations du compilateur suivantes sont fournies avec la directive #import :

  • Le fichier d'en-tête, une fois créé, porte le même horodatage que la bibliothèque de types.

  • Lorsque #import est traitée, le compilateur vérifie d’abord si l’en-tête existe et est à jour. Si oui, il n’a pas besoin d’être recréé.

La directive #import participe également à une reconstruction minimale et peut être placée dans un fichier d’en-tête précompilé. Pour plus d’informations, consultez Création de fichiers d’en-tête précompilés.

Fichier d’en-tête de bibliothèque de types primaire

Le fichier d'en-tête principal de bibliothèque de types se compose de sept sections :

  • Zones fixes de titre : se composent des commentaires, de l'instruction #include pour COMDEF.H (qui définit des macros standard utilisées dans l'en-tête) et d'autres informations de configuration diverses.

  • Références anticipées et typedefs : se composent de déclarations de structure comme struct IMyInterface et de définitions de types (typedefs).

  • Déclarations de pointeur intelligent : la classe _com_ptr_t de modèle est un pointeur intelligent. Il encapsule les pointeurs d’interface et élimine la nécessité d’appeler AddRef, Releaseet QueryInterface de fonctions. Il masque également l’appel lors de la CoCreateInstance création d’un objet COM. Cette section utilise l’instruction _COM_SMARTPTR_TYPEDEF macro pour établir des typesdefs d’interfaces COM en tant que spécialisations de modèle de la classe de modèle _com_ptr_t . Par exemple, pour l’interface IMyInterface, le . Le fichier TLH contient les éléments suivants :

    _COM_SMARTPTR_TYPEDEF(IMyInterface, __uuidof(IMyInterface));

    ce que le compilateur développe en :

    typedef _com_ptr_t<_com_IIID<IMyInterface, __uuidof(IMyInterface)> > IMyInterfacePtr;

    Le type IMyInterfacePtr peut alors être utilisé à la place du pointeur d'interface brut IMyInterface*. Par conséquent, il n’est pas nécessaire d’appeler les différentes IUnknown fonctions membres

  • Déclarations typeinfo : se compose principalement de définitions de classes et d’autres éléments exposant les éléments typeinfo individuels retournés par ITypeLib:GetTypeInfo. Dans cette section, chaque typeinfo de la bibliothèque de types est répercuté dans l'en-tête en fonction des informations de TYPEKIND.

  • Ancienne définition de GUID facultative : contient les initialisations des constantes GUID nommées. Ces noms ont le formulaire CLSID_CoClass et IID_Interface, comme ceux générés par le compilateur MIDL.

  • Instruction #include pour l'en-tête de bibliothèque de types secondaires.

  • Zones fixes de pied de page : incluent actuellement #pragma pack(pop).

Toutes les sections, à l’exception de la section réutilisable de titre et de pied de page, sont placées dans un espace de noms avec son nom spécifié par l’instruction library dans le fichier IDL d’origine. Vous pouvez utiliser les noms de l’en-tête de bibliothèque de types par une qualification explicite à l’aide du nom de l’espace de noms. Vous pouvez également inclure l’instruction suivante :

using namespace MyLib;

immédiatement après l’instruction #import dans le code source.

L’espace de noms peut être supprimé à l’aide de l’attribut no_namespace) de la directive #import . Toutefois, la suppression de l'espace de noms peut entraîner des collisions de noms. L’espace de noms peut également être renommé par l’attribut rename_namespace.

Le compilateur fournit le chemin d’accès complet à toute dépendance de bibliothèque de types requise par la bibliothèque de types qu’il traite actuellement. Le chemin d’accès est écrit, sous forme de commentaires, dans l’en-tête de bibliothèque de types (.TLH) que le compilateur génère pour chaque bibliothèque de types traitée.

Si une bibliothèque de types inclut des références aux types définis dans d'autres bibliothèques de types, le fichier .TLH inclura des commentaires du type suivant :

//
// Cross-referenced type libraries:
//
//  #import "c:\path\typelib0.tlb"
//

Le nom de fichier réel dans le commentaire #import est le chemin d’accès complet de la bibliothèque de types référencées croisée, tel qu’il est stocké dans le Registre. Si vous rencontrez des erreurs provoquées par des définitions de type manquantes, vérifiez les commentaires à la tête du . TLH pour voir quelles bibliothèques de types dépendantes peuvent être importées en premier. Les erreurs possibles sont des erreurs de syntaxe, par exemple C2143, C2146, C2321, C2501 (decl-specifiers absents) ou C2433 (« inline » non autorisé dans la déclaration de données) lors de la compilation du fichier .TLI.

Pour résoudre les erreurs de dépendance, déterminez les commentaires de dépendance qui ne sont pas fournis autrement par les en-têtes système, puis fournissez une directive #import à un moment donné avant la directive #import de la bibliothèque de types dépendants.

attributs #import

#import pouvez éventuellement inclure un ou plusieurs attributs. Ces attributs demandent au compilateur de modifier le contenu des en-têtes de bibliothèque de types. Une barre oblique inverse (\) peut être utilisée pour inclure des lignes supplémentaires dans une instruction #import unique. Par exemple :

#import "test.lib" no_namespace \
   rename("OldName", "NewName")

Pour plus d’informations, consultez #import attributs.

FIN C++ Spécifique

Voir aussi

Directives de préprocesseur
Prise en charge COM du compilateur