Ich habe etwas C ++ / CLI-Code, der von den .NET-System-Namespace-Klassen abgeleitet ist.
Gibt es eine Möglichkeit, diesen Code für Universal Windows Platform Apps zu verwenden?
Ich kann keinen Verweis auf den System-Namespace in C ++ erhalten, obwohl dies in C # möglich ist. Es scheint, dass es nur Unterstützung für C ++ / Cx-Code und nicht für verwaltetes C ++ / CLI gibt.
Die Syntax und Schlüsselwörter der C ++ / CX-Erweiterung ähnelt C ++ / CLI sehr. Aber da hört die Ähnlichkeit auf, sie haben überhaupt nichts gemeinsam. C ++ / CX wird wie systemeigenes C ++ direkt in nativen Code kompiliert. Aber C ++ / CLI wird nach MSIL, der Zwischensprache von .NET, kompiliert. Ihre Syntax sieht so ähnlich aus, weil sie beide das gleiche Problem lösen und C ++ an ein fremdes System anbinden. .NET im Fall von C ++ / CLI, WinRT im Fall von C ++ / CX.
Was ist der Hauptgrund, warum Sie den System-Namespace nicht verwenden können, handelt es sich um einen .NET-Namespace. Sie verwenden stattdessen den Namespace std zusammen mit den Namespaces Platform und Windows für WinRT-spezifische Typen. Der Compiler kann keine .NET-Referenzassemblys mit der / ZW-Kompilierungsoption importieren, sondern nur WinRT-Metadatendateien mit der Dateinamenerweiterung .winmd. Dies sind Erweiterungen des COM-Dateiformats .tlb, die Sie zuvor mit der Anweisung #import importieren mussten.
Was an sich eine weitere Quelle für Verwirrung ist, basierte das interne .winmd-Dateiformat auf dem Format der .NET-Metadaten. Die meisten .NET-Dekompiler können Ihnen deshalb den Inhalt einer .winmd-Datei anzeigen. Aber wieder nur eine oberflächliche Ähnlichkeit, es ist völlig unabhängig von einer .NET-Assembly. Es kann nur Deklarationen enthalten, nicht Code. Am besten vergleichen Sie es mit einer .h-Datei, die Sie in einem nativen C ++ - Projekt verwenden würden. Oder eine TLB-Datei, wenn Sie zuvor COM ausgesetzt waren.
Zu wissen, wie COM funktioniert, kann sehr hilfreich sein, um herauszufinden, worum es geht. Es ist in der Tat COM, die im Kern von WinRT liegt, der Grund, warum Ihr C ++ / CX-Projekt kann leicht von einem Programm in einer völlig anderen Sprache wie Javascript oder VB.NET geschrieben verwendet werden. Eine WinRT-App ist eigentlich ein Out-of-Process-COM-Server. Eine Klassenbibliothek oder eine WinRT-Komponente ist ein prozessinterner COM-Server. COM-Objektfactorys funktionieren anders, der Bereich ist auf die im Paketmanifest angegebenen Dateien beschränkt. C ++ / CX ist Teil der Sprachprojektion , die COM verbirgt, zusammen mit den C ++ - Bibliotheken, die Sie verknüpfen, die die Platform-Namespaces implementieren. WinRT wäre noch geboren, wenn Programmierer traditionellen COM-Client-Code schreiben müssten. Sie können immer noch in nativem C ++, die WRL-Bibliothek tut wenig, um die Rohrleitungen zu verbergen.
WinRT unterstützt ohne weiteres Code, der in einer verwalteten Sprache wie C # oder VB.NET geschrieben wurde, die Sprachprojektion ist in das Framework integriert und stark unsichtbar. Aber nicht C ++ / CLI, eine strukturelle Einschränkung. Eine Store / Phone / Universal App zielt auf eine Teilmenge von .NET Framework namens .NETCore ab. In diesen Tagen besser bekannt als CoreCLR, die Teile, die Open-Source waren. Welche Modulinitialisierer, die für C ++ / CLI wichtig sind, werden nicht unterstützt.
Genug einleitend und zur Antwort: Nein, Sie haben keinen Nutzen für Ihren C ++ / CLI-Code und Sie müssen ihn umschreiben. Sie haben eine gute Chance, den nativen C ++ - Code zu portieren, mit dem Ihr C ++ / CLI-Wrapper verbunden war, solange er die API-Beschränkungen einhält. Sie sollten immer zuerst dort anfangen, da es einfach zu machen ist und Ihnen sofort sagt, ob Ihr nativer C ++ - Code verboten api-Funktionen verwendet, die eine Batterie zu schnell entladen oder die Sandbox-Beschränkungen verletzen.
Die ref class -Wrapper müssen jedoch erheblich optimiert werden. Es gibt wenig Grund anzunehmen, dass dies ein großes Hindernis sein wird, es könnte sich strukturell ähneln. Die größten Einschränkungen sind die fehlende Unterstützung für die Implementierungsvererbung, eine COM-Einschränkung und das Ersetzen des Codes, der .NET Framework-Typen verwendete, durch entsprechenden C ++ - Code. Das typische Aufhängen ist, dass es eine Menge davon gibt, der ursprüngliche Autor hätte normalerweise die sehr praktischen .NET-Typen gegenüber den Standard-C ++ - Bibliothekstypen bevorzugt. YMMV.
Tags und Links windows visual-c++ win-universal-app c++-cli