Je comprends comment COM peut atteindre le code Compiler Agnostic C ++, puisqu'il définit un ABI en faisant prudence quelles caractéristiques de la langue C ++ à utiliser. Ce n'est que du code C ++ parlant au code C ++ de manière vraiment intelligente. Cependant, je ne comprends toujours pas comment il peut autoriser la langue interopt avec C # ou JavaScript par exemple.
Où est la limite? La seule explication que j'ai en ce moment est que le compilateur de langue lui-même doit avoir une prise en charge spéciale pour COM afin de générer le code de montage approprié pour permettre une communication précise entre les appelants / callees.
3 Réponses :
La "bibliothèque de types" est ce qui permet d'interoper des composants COM entre différentes langues.
https: // docs .microsoft.com / fr-US / Windows / Bureau / MIDL / COM-DCOM-and-TYPE-Bibliothèques
Une bibliothèque de type (.TLB) est un fichier binaire qui stocke des informations sur un Propriétés et méthodes d'objet COM ou DCOM dans une forme qui est Accessible à d'autres applications au moment de l'exécution. En utilisant une bibliothèque de type, un L'application ou le navigateur peut déterminer quelles interfaces un objet prend en charge et invoquer des méthodes d'interface d'un objet. Cela peut se produire Même si les applications d'objet et de client ont été écrites dans différents langages de programmation. L'environnement d'exécution COM / DCOM peut également utiliser une bibliothèque de type pour fournir un croisement automatique, un processus croisé, et le maréchalage croisé pour les interfaces décrites dans le type Bibliothèques.
L'autre approche pour la langue Interop (par exemple, C ++ Projection d'objets à JavaScript) est qu'un objet COM peut implémenter Idispatch .
Techniquement, COM ne nécessite pas de type type de tactile, qui sont facultatifs, il s'agit simplement d'un contrat binaire (par conséquent, parfaitement adapté à la langue Interop). Vous n'avez besoin que d'une définition, d'un contrat, dans n'importe quel formulaire qui définit la mise en page des structures binaires (Tablevis) et des ID d'interface. Les langues pouvant lire un fichier .h ou .idl (C / C ++ ou d'autres) n'ont pas besoin d'utiliser une typelib. Vous pouvez également définir les structures et les identifiants à la main, c'est ce que nous faisons avec C # p / invoke. Cela dépend donc vraiment de la langue et de son outil associé.
Je ne comprends toujours pas comment l'appel réel est fait ou pourquoi cela fonctionne pour des langues autres que c et C ++. Par exemple, l'interface est définie dans les métadonnées (fichier .idl ou ces typelibs) et il est tellement générique que toute la langue de l'OOP peut la mettre en œuvre. Maintenant quoi? Comment mon appel C ++ a-t-il généré C # code?
@Simonmourier Je connais des fichiers TLB via l'automatisation dans Visual Studio pour des choses telles que l'exposition C # Classes à C ++, mais sans écrire manuellement des contrats binaires ad-hoc pour la consommation C / C ++. Existe-t-il un exemple de guide ou de code que vous suggérez-vous simplement et concis?
@kayleefrye_ondeck - Vous définissez généralement un .idl manuellement et obtenez un .h et un .tlb de sa compilation. Ensuite, à partir de C / C ++, vous pouvez utiliser cela .h normalement ou utilisez la directive de Visual Studio de Studio depuis le .TLB. Cette directive (ré) créera (RE) de créer tous les en-têtes nécessaires (et éventuellement des pointeurs / emballages / emballages). Peut-être que vous devriez poser une autre question.
Ce n'est pas la magie, bien sûr.
COM consacre des règles pour la langue Interop. C'est juste un contrat, avec un outillade utile. Chaque langue qui veut soutenir COM doit trouver un moyen de respecter ses règles. Ils doivent tous fournir leur propre mécanisme compatible d'une manière ou d'une autre.
Dans le cas de C ++, les règles semblent être gratuites que vous avez mentionnées, mais soyez conscient qu'il existe une mise en garde: la norme de langue ne spécifie pas la disposition et le mécanisme des classes et des fonctions virtuelles. La méthode imite par COM est une implémentation extrêmement courante de l'appel virtuel ("The Tabled"), et celle suivie la mise en page exacte utilisée par le compilateur Microsoft. Mais vous pouvez avoir un compilateur C ++ parfaitement valide où les classes avec des fonctions virtuelles ne seraient pas compatibles avec la mise en page COM. C'est juste que personne ne le fait, du moins pas dans les compilateurs de Windows. Donc, même en C ++, il y a une "réunion au milieu" par le compilateur.
en C, vous devez faire tout le tout à la main. D'autres langues pourraient vous permettre de faire la même chose (assembleur bien sûr).
Pour aider à compiler les informations d'échange de langues sur des contrats spécifiques, COM fournit des bibliothèques de type et des mécanismes pour les lire. Un compilateur ou une langue qui souhaite en tirer parti doit également "se rencontrer au milieu" et apprendre à les traiter (par exemple, la directive Microsoft C ++ Aucune langue ne soutiendra tout ce que vous pouvez faire dans COM, car il existe un point (dans des fonctionnalités plus obscures) où le retour sur investissement dans la mise en œuvre de l'assistance dans la langue ne panne pas. Chaque langue doit choisir ses propres limitations. Il y a beaucoup de choses que vous pouvez faire dans com (lire les spécifications IDL) que VB6 ne peut pas faire.
Parce que suivre les règles COM dans une langue semblable à un script est entreprimée et impossible, COM offre une approche de niveau supérieur (Automatisation) plus prépayable pour les langues dynamiques, même si elle est plus limitée. Mais une mise en œuvre de la langue qui souhaite fournir un support client à l'automatisation doit mettre en œuvre une compréhension de l'interface IDISPATCH, un mécanisme d'activation et une traduction dans les installations appropriées de son langage. Et un langage de script souhaitant fournir une prise en charge de la création de serveurs COM doit travailler encore plus difficile à mettre en œuvre une implémentation d'Idispatch valide et un moteur hôte autonome pour le compte des scripts utilisateur. Même Vbscript ne pouvait pas faire cela au début, jusqu'à ce que Microsoft ait ajouté la prise en charge de l'hôte de script Windows. "Réunion au milieu" à nouveau.
Si une langue veut supporter à la fois pure COM et Automation, elles doivent travailler à deux jours; La prise en charge d'un seul ne vous donne pas automatiquement de support pour l'autre.
Pour .NET Langues comme C #, la plupart des travaux sont effectués à la fois pour l'automatisation native et l'automatisation à l'intérieur de l'exécution .NET, qui fournit la mise en œuvre des wrappers appelables appelables (CCW) et des wrappers appelables d'exécution (RCW) nécessaires à Interagir avec COM et manipuler les conflits entre l'approche de comptage de référence de COM et l'approche GC de .NET. Microsoft a fait tout le travail au même endroit afin que les concepteurs de langue .NET ne soient pas obligés.
Donc, oui, la mise en œuvre de la langue doit travailler supplémentaire pour donner le support spécial linguisme à COM: suivre les règles de présentation binaire, mettre en œuvre une couche de traduction si nécessaire, et / ou éventuellement fournir des outillages pour lire les bibliothèques de type.
Langue Interop nécessite les deux côtés (l'appelant et la callee) pour "se rencontrer au milieu" quelque part. Com n'est qu'une spécification qui donne aux concepteurs que le terrain du centre, "un endroit où tout peut rencontrer". #Import ; le menu Bibliothèques VB6).
Depuis que vous avez étiqueté votre question avec WinRT, je suppose que vous demandez spécifiquement comment cela est réalisé par des projections de langue WinRT. Dans ce cas, toutes les langues doivent avoir un moyen de cartographier leurs constructions de langue naturelle sur le COM ABI que WinRT définit. Cet abi est dérivé de métadonnées codées dans la norme ECMA 335 et les règles spéciales sont appliquées pour transformer les métadonnées abstraites en ABI concret. Il y a des moyens naturellement différents pour y parvenir. Le CLR lui-même a été mis à jour pour prendre en charge WinRT en C #. Le compilateur Visual C ++ était (malheureusement) mis à jour avec des extensions de langue pour prendre en charge WinRT via C ++ / CX. L'approche C ++ / WinRT est très différente en ce sens qu'elle ne nécessite qu'un compilateur C ++ standard et toutes les connaissances sur WinRT sont livrées via une bibliothèque d'en-tête C ++ standard. D'autres langues pourraient prendre différentes approches, mais à la fin de la journée, ils doivent être d'accord sur la manière dont les types exprimés en métadonnées sont transformés en objets et en des appels de fonction virtuelle sur l'ABI basé sur COM.
Et pendant que ce processus n'est pas bien documenté pour le moment, C ++ / WinRT est l'une des seules projections de langue open source et sert donc de mise en œuvre utile de référence pour ceux qui doivent comprendre comment WinRT fonctionne sous la hotte.
Merci pour la clarification. J'ai traversé l'exemple Python dans le Repo Xlang et j'ai découvert la pièce manquante dans ma compréhension. Je n'ai pas compris comment le code Python / WinRt C ++ pourrait appeler la mise en œuvre de Python, alors après avoir lu la documentation pour le tutoriel, on dirait que c'est obtenu à l'aide du module d'extension native Python.
.NET CORE est également open-source et a des liaisons pour appeler les API WinRT, mais c'est un projet légèrement plus grand, donc l'utiliser comme une référence pourrait être plus difficile :)
Toute cette chose xlang entourant CPPWinrt est jolie nouvelle, n'est-ce pas ?. Y a-t-il des présentations décentes au-delà du repo GitHub?