Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

C++/CLI Managed/Unmanaged Code aufrufen

Werbeanzeige

Helgon

Frischling

  • »Helgon« ist der Autor dieses Themas

Beiträge: 5

  • Private Nachricht senden

1

28.12.2012, 06:32

C++/CLI Managed/Unmanaged Code aufrufen

Edit: Sry, ist schon spät/früh :dead: - ausversehen falsches Unterforum erwischt, bitte verschieben
Hi,

ich hab ein 'kleines' Problemchen. Situation ist folgende. Ich möchte einen kleinen Editor mit GUI. Da für mich nur Windows relevant ist und an die Vielfalt und Optik nichts herankommt hab ich mich für Windows Forms entschieden.
Also war erstes Problem überhaupt in ein Windows Form das DirectX Frame rein zu rendern.
Mit bisschen Recherche etwas gefunden das mich auf eine C++/CLI Lösung gebracht hat. Schien sogar recht gut zu funktionieren, aber als ich dann anfangen wollte die ersten kleinen Sachen zu implementieren bin ich auf ein für mich unlösbares Problem gestoßen.
Anzumerken sei, dass ich für den ganzen Mathe kram xnamath.h verwende. Also wie gewohnt den header eingebunden und ich fang an. Jedoch hats auf einmal sobald ich etwas aus der xnamath verwendet habe errors gehagelt. Nach einigem rumprobieren bin ich zu folgendem Fazit gekommen.

Objekte vom Typ:
  • XMFLOAT4X4
  • XMVECTORF32
  • XMVECTOR
rufen einen error hervor -> nicht mehr kompilierbar

Skurriler weise funktioniert mit
  • XMFLOAT3x3
  • XMFLOAT3
  • XMFLOAT2
gar kein Problem, nicht mal eine Warnung


Die Error die ich bekommen sind folgende:

Quellcode

 
1
2
3
4
5
6

1>[...]\Editor.h(89): error C2711: "AppStandalone::Editor::Editor": Diese Funktion kann nicht als verwaltet kompiliert werden. Verwenden Sie ggf. #pragma unmanaged.
1> Ausgerichtete Datentypen werden in verwaltetem Code nicht unterstützt.
1> [...]\Editor.h(156): Siehe Quelle der vorherigen Compilerdiagnose.
1>[...]\Editor.h(156): error C3821: "AppStandalone::Editor::Editor(HINSTANCE)": Ein verwalteter Typ oder eine verwaltete Funktion kann nicht in einer nicht verwalteten Funktion verwendet werden.
1> Ausgerichtete Datentypen werden in verwaltetem Code nicht unterstützt.
1>[...]\Editor.h(89): error C3645: "AppStandalone::Editor::Editor": __clrcall kann nicht für Funktionen verwendet werden, die als systemeigener Code kompiliert werden.


Quellcode

 
1
2
3

Fehler  35  error C2711: "AppStandalone::Editor::Editor": Diese Funktion kann nicht als verwaltet kompiliert werden. Verwenden Sie ggf. #pragma unmanaged.  c:\users\michael\documents\visual studio 2012\projects\appstandalone\appstandalone\Editor.h 89
Fehler  37  error C3645: "AppStandalone::Editor::Editor": __clrcall kann nicht für Funktionen verwendet werden, die als systemeigener Code kompiliert werden. c:\users\michael\documents\visual studio 2012\projects\appstandalone\appstandalone\Editor.h  89
Fehler  36  error C3821: "AppStandalone::Editor::Editor(HINSTANCE)": Ein verwalteter Typ oder eine verwaltete Funktion kann nicht in einer nicht verwalteten Funktion verwendet werden. c:\users\michael\documents\visual studio 2012\projects\appstandalone\appstandalone\Editor.h 156



Dann hab ich natürlich auch gegoogelt, aber dazu gibt es kaum etwas oder es hat mir einfach gar nicht geholfen :(

Ich hoffe das hier jemand ne Idee hat wie ich das Problem lösen kann. Ich kann mir nicht vorstellen, dass sobald man C++/CLI verwendet nur noch dieser managed Code zulässig ist und man sonst nichts mehr verwenden kann - zumal xnamath ja auch von Microsoft stammt.

Grüße, Helgon

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Nox« (28.12.2012, 12:26) aus folgendem Grund: Nox: Fehlerausgabe ein wenig augenfreundlicher gestaltet

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

2

28.12.2012, 12:30

Wild guess: die ersten 3 Typen sind speziell aligned während die anderen eben kein alignement spezifierten, was mit managed kollidiert.
Lösungvorschlag: such mal nach alignment byte managed.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Legend

Alter Hase

Beiträge: 731

Beruf: Softwareentwickler

  • Private Nachricht senden

3

28.12.2012, 14:12

Bei der Verwendung von C++/CLI musst du aufpassen, welcher Code managed und welcher unmanaged ist. Du scheinst mir die XNA-Datentypen in Code einer managed Klasse (erkennbar an der Deklaration als ref class) verwenden zu wollen. Das geht in der Tat nicht, da diese Datentypen das schon angesprochen Alignment brauchen um zu funktionieren.

Du könntest höchstens aus der managed Methode eine unmanaged Methode aufrufen, diese darf dann diese Datentypen benutzen. Diese unmanaged Methode kann auch im selben Projekt und daher der selben EXE/DLL sein. Das kann aber je nach Aufbau deiner Anwendung hässlich sein, ausserdem musst du darauf achten, ob sich der Aufwand von der Performance her lohnt.

Ein dünner managed Wrapper um eine Bibliothek wie XNA lohnt sich in der Tat typischerweise nicht. Z.b. ein Dotproduct berechnet man schneller, wenn man für diese Berechnung im managed Code bleibt. Der Weg von managed zu unmanaged, ein Dotproduct in nativem Code mit SSE, und wieder zurück von unmanaged zu managed braucht leider mehr Zeit. Da muss man schon größere Häppchen an Arbeit in unmanaged Code durchführen, damit sich das lohnt.

Ich selbst bin daher den Weg gegangen solche Berechungen einmal nativ und dann noch einmal managed zu implementieren und Konvertierungsfunktionen zwischen den managed und unmanaged Typen zu implementieren. Diese Konvertierung sollte natürlich so selten wie möglich benutzt werden. ;)
Das wird aber sicherlich nicht jeder so machen, aufwendig war es in der Tat. ;)
"Wir müssen uns auf unsere Kernkompetenzen konzentrieren!" - "Juhu, wir machen eine Farm auf!"

Netzwerkbibliothek von mir, C#, LGPL: https://sourceforge.net/projects/statetransmitt/

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

4

28.12.2012, 14:36

Schreib deine Anwendung in C#. Den Renderer etc. packst du per C++/CLI in eine Library, wobei lediglich deren Interface managed und alles andere native ist. Die C# Anwendung verwendet dann diese Library. Rein prinzipiell solltest du aber die Finger von C++/CLI lassen, wenn du nicht zumindest ein etwas tiefergehendes Verständnis von managed Code hast. Die komplette Anwendung in C++/CLI zu schreiben ist auf jeden Fall eine ganz schlechte Idee. Sogar Microsoft selbst rät mittlerweile explizit davon ab, auch wenn ich den entsprechenden MSDN Artikel grad nicht finden kann...
m4studios

Legend

Alter Hase

Beiträge: 731

Beruf: Softwareentwickler

  • Private Nachricht senden

5

28.12.2012, 15:16

Ich würde sogar noch einen Schritt weiter gehen, den Renderer in nativem C++ als eigene Library implementieren und dann einen Wrapper in C++/CLI implementieren. Allein schon weil IntelliSense doch praktisch ist. ;)
"Wir müssen uns auf unsere Kernkompetenzen konzentrieren!" - "Juhu, wir machen eine Farm auf!"

Netzwerkbibliothek von mir, C#, LGPL: https://sourceforge.net/projects/statetransmitt/

Helgon

Frischling

  • »Helgon« ist der Autor dieses Themas

Beiträge: 5

  • Private Nachricht senden

6

28.12.2012, 15:47

Hi, danke für die ganzen Antworten - hätte ich echt nicht gedacht :)

Scheint ja irgendwie nicht das wahre zu sein die C++/CLI Lösung (was ich hier so rauslese)

@Dot Geht das so "einfach" ? Ich glaube ja nicht, das ist doch der Grund warum es SlimDX/SharpDX überhaupt gibt?

Wie auch immer. Ich glaub, ich werd einfach auf Qt umsteigen - damit sollte sich dieser managed Code mist mit erledigen.

Auf jeden Fall trotzdem Danke für die Denkanstöße

Grüße

Helgon

Frischling

  • »Helgon« ist der Autor dieses Themas

Beiträge: 5

  • Private Nachricht senden

7

29.12.2012, 06:41

So - falls irgendwer in Zukunft mal auf diesen Thread stoßen sollte und das gleiche Problem hat: Einfach auf Qt umsteigen! Kein vergleich zu dem rumgefummel mit der C++/CLI Variante oder einem C++ Interop Ansatz den ich verfolgt hab. Sollte sich Microsoft mal schämen das sie da nix für DX anbieten :nono:

Legend

Alter Hase

Beiträge: 731

Beruf: Softwareentwickler

  • Private Nachricht senden

8

29.12.2012, 10:44

Qt ist für ne Oberfläche natürlich auch eine gute Wahl.
SharpDX und SlimDX benutzt man afaik eigentlich von C# heraus und nicht von C++/CLI.
Und ja, C++/CLI ist nicht unbedingt das ware. Der einzige wirkliche Nutzen von C++/CLI
gegenüber C# ist es Interop-Wrapper zu implementieren. Und Interop zwischen managed
und unmanaged Code ist kompliziert, nicht nur per C++/CLI!
"Wir müssen uns auf unsere Kernkompetenzen konzentrieren!" - "Juhu, wir machen eine Farm auf!"

Netzwerkbibliothek von mir, C#, LGPL: https://sourceforge.net/projects/statetransmitt/

Werbeanzeige

Ähnliche Themen