Announcement

Collapse
No announcement yet.

Native C++ Anbindung in .NET (C# oder C++)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Native C++ Anbindung in .NET (C# oder C++)

    Hallo,

    mit Interesse habe ich bereits den Beitrag "Native C++ besser mit C++/CLI oder C#? http://entwickler-forum.de/showthread.php?t=55342" verfolgt.

    Wir wollen ebenfalls ein Userinterface mit .NET (C++ bzw. C#) erstellen und recht umfangreichen "native bzw. unmanaged C++ - Code" einer Alt-Anwendung einbinden.


    Nun frage ich mich nach der bestmöglichen Lösung der folgenden Möglichkeiten:

    1. (.NET) C# - Userinterface mit native C++ Anbindung
    2. (.NET) C++ - Userinterfave mit native C++ Anbindung
    3. Eine .NET-Anwendung und eine native C++ - Anwendung, die via Pipes Daten austauschen

    Bislang habe ich das Userinterface mit C# erstellt und finde das Einbinden von native C++ Code recht kompliziert. Es scheint via DLLImport oder Erstellen von Wrappern jedoch möglich.

    Nun stelle ich mir die Frage, wenn ich das Userinterface mit Managed C++, also ebenfalls in .NET, statt mit C# erstelle, ob ich dadurch wesentliche Vorteile habe, wenn ich hier nativen C++ - Code einbinde?

    Wie würdet ihr verfahren, wenn recht viel nativer C++ Code vorhanden ist, der wiederverwendet werden soll und warum?

    Vielen Dank für Antworten/Anregungen - Michael.

  • #2
    Hallo,

    es kommt darauf an ob
    • ob du Visual C++ kannst
    • die GUI wirklich in .net sein muss


    Wenn beides zutrifft warum die GUI nicht mit VC++ entwickeln (oder einer anderen C++ Sprache die GUI erstellen kann).

    Ich würde die GUI in C# entwickeln (also kann ich VC++ zu wenig/nicht) und für die C++ Klassen einen Wrapper mit C++/CLR erstellen. Beispielhaft vorgehensweise -> http://codeguru.earthweb.com/cpp/cpp/cpp_managed/interop/article.php/c6867/

    Ein automatisches Tool das die Wrapper erstellt gibt es glaub ich nicht da die unmanaged DLLs keine bzw. zu wenige Metainformationen hierzu besitzen.

    mfG Gü
    "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

    Comment


    • #3
      Möglich wäre die Konvertierung des C++-Quellcodes in C#-Quellcodes.

      Dazu gibt es Tools zB:

      Ich hab keinen wirklich getestet und kann somit nicht sagen inwiefern dies möglich/sinnvoll ist.

      mfG Gü
      "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

      Comment


      • #4
        mit Interesse habe ich bereits den Beitrag "Native C++ besser mit C++/CLI oder C#?
        Der ursprüngliche Poster hat die Diskussion zu diesem Thema hier weitergeführt.

        Ansonsten wenn du deinen Punkt 3. wirklich für anwendbar hälst dann ist die gedachte Schnittstelle zwischen den beiden Anwendungsteilen(managed/unmanaged) vermutlich so schmal das eine Wrapperschicht in C++/CLR sinnvoll wäre. Zumindest besser als die Idee in Punkt 3. selbst

        Wenn du den unmanaged Teil dann so veröffentlicht hast ist es danach letztlich egal in welcher .NET Sprache du eine GUI drüberlegst.

        Comment


        • #5
          Hallo,

          vielen Dank für Eure Antworten.

          Ich werde zunächst bei Visual C# für die GUI-Entwicklung bleiben und den nativen C++ Code mit Wrappern anbinden.

          Hat Jemand von Euch hierzu vielleicht noch gute Links oder Beispiele?

          Viele Grüsse - Michael.

          Comment


          • #6
            Siehe oben (http://entwickler-forum.de/showpost.php?p=195859&postcount=2)

            mfG Gü
            "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

            Comment


            • #7
              Besseres als den Link von Gü hab ich auch nicht.
              Bedenke aber das das der alte Syntax von managed c++ aus dem 1.1er Framework ist und du das entsprechend noch nach c++/clr bringen must (also insbesondere das __gc , __nogc weg und durch das ^ für managed Referenzen ersetzen).

              Und das Zweite ist das du noch das Konvertieren der Datentypen brauchst. Im Beispiel wird ja ein Integer benutzt. Dessen Darstellung im Speicher ist in managed Code (natürlich nur die unboxed Version eines Integers) und unmanaged Code identisch und muß deshalb nicht konvertiert werden. Für viele anderen Datentypen brauchst du aber Konvertierungsroutinen. Dazu siehe z.B. hier.

              Comment


              • #8
                Vielen Dank, die Links sind sehr hilfreich.


                Was ich bisher nicht lösen konnte, ist die Konvertierung eines Singletons.

                Hierzu habe ich folgenden Code der Header-Datei:

                static Class_A* GetInstance();

                Die Methode GetInstance() erzeigt dann im unmanaged Code mit new() das Objekt, sofern noch nicht vorhanden.

                Also kann ich hier in C++/CLI nicht einfach die Klasse mit gcnew instanzieren...

                Hat da Jemand eine Idee?

                Danke - Michael.

                Comment


                • #9
                  Deine Class_A ist eine unmanaged Klasse die wirst du nicht einfach in die managed Welt bekommen in dem du sie mit gcnew erzeugst. Das sollte sogar knallen. Eine managed Klasse ist strukturell was anderes als eine unmanaged Klasse sie heißen beide nur class weil sie natürlich konzeptionell das selbe darstellen ihre technisch Umsetzung ist aber inkompatibel. Du hattest doch in diesem Thread selbst schon von Wrappern gesprochen die du schreiben willst. Ich dachte deshalb das wäre dir bewußt.

                  Du mußt also eine managed Wrapperklasse schreiben die Class_A kapselt, das Interface von Class_A wiederveröffentlicht(Properties, Methoden etc), also deren unmanaged Typen im Interface als managed Typen wiederveröffentlichst, aber intern eine unmanaged Instance von Class_A(also mit new erzeugt) hält.

                  Comment


                  • #10
                    Mal als Aufhänger ein kleines Codebeispiel für einen entsprechenden Wrapper..
                    Das ist Freihand Code, weiß also nicht ob das überhaupt kompiliert, sollte aber das Vorgehen verdeutlichen. Die Implementierung des Singelton in .NET sollte man besser über einen static Constructor machen hatte aber gerade keine Idee (und auch keine Lust das nachzuschlagen) wie das in C++/CLR aussieht.


                    Code:
                    public ref class Class_A_Wrapper
                    {
                    public:   
                       explicit  Class_A_Wrapper();
                       static Class_A_Wrapper ^GetInstance();
                    private:
                       Class_A *_innerInstance;
                       Class_A_Wrapper ^_singletonInstance;
                    }
                    
                    Class_A_Wrapper() 
                    {
                       _innerInstance = new Class_A();   
                    }
                    
                    Class_A_Wrapper ^GetInstance()
                    {
                        if(_singletonInstance == null)
                            _singletonInstance = gcnew Class_A_Wrapper();
                    
                       return _singeltonInstance;
                    }
                    Zuletzt editiert von Ralf Jansen; 10.06.2009, 21:30.

                    Comment

                    Working...
                    X