C++ DLL in Labview einbinden

Niko schrieb:
> Wie aufwendig ist das denn für jemenden, der keine Erfahrung mit Labview
> hat?

Normalerweise : Nein.

Niko schrieb:
> Wie soll ich ambesten vorgehen?

Du hast hoffentlich die .h Datei, dann würde ich den Import-Assistenten 
erstmal verwenden.

Nur das:
Niko schrieb:
> zwei DLL (File, die von einander abhangig sind)
ist etwas unklar. Wie würdest Du denn die DLLs in C einbinden so das die 
voneinander erfahren?

lalala schrieb:
> Normalerweise : Nein.

bezogen auf welche Frage?

lalala schrieb:
> ist etwas unklar. Wie würdest Du denn die DLLs in C einbinden so das die
> voneinander erfahren?

Diese DLL sind in C++ geschrieben und nicht in c.

Die Header File habe ich alle nur die Frage der Machtbarkeit ?
beide DLL File beinhalten Klassen und komplexe Datenstrukturen, die 
vielleicht für Labview nicht erkennbar sind.

Niko schrieb:
> lalala schrieb:
>> Normalerweise : Nein.

ich meinte: nicht sehr aufwendig.

Niko schrieb:
> Diese DLL sind in C++ geschrieben und nicht in c.

Das ist ziemlich egal. Du hast meine Frage leider nicht beantwortet. Wie 
würdest Du denn die beiden dlls in C++ einbinden.

lalala schrieb:
> Wie
> würdest Du denn die beiden dlls in C++ einbinden?

Ich bin so vorgegangen:

DLL 1 ist das unterste Schicht in VStudio
dann DLL2 ist der zweite Schicht
dann meine Main_Object "GUI", wo ich die beide DLL 1 und DLL 2 aufrufe.

beide DLL File sind in der C++ ale eigene Projeckt

Wer lädt denn DLL2? Macht DLL1 das, oder Dein 'GUI'-Objekt?

Deine Beschreibung ist leider nicht sehr klar.

lalala schrieb:
> Wer lädt denn DLL2? Macht DLL1 das, oder Dein 'GUI'-Objekt?

DLL1

Boris P. schrieb:
> Ich würde ein C-Style Funktionsinterface einbauen, das den C++
> Teil
> wegkapselt. Damit kannst du dann in labVIEW arbeiten.
>
> Die C++ Klassen wirst du nicht in labVIEW verwenden können.

Ich habe über 20 Klassen.
Soll ich für die alle eine Wrapper schreiben?

Ich brauche eigentlich nur eine Funktionalität, die ich gerne 
visualisieren möchte.

Niko schrieb:
> Ich habe über 20 Klassen.
> Soll ich für die alle eine Wrapper schreiben?
Kommt drauf an. Wenn du die Allokation kapselst und über Kenntnis des 
ABI's den sonst impliziten this-Pointer explizit übergibst, könnte es 
auch "direkt" funktionieren. Gibt halt wegen des Name Manglings lustige 
Funktionsnamen.

Boris P. schrieb:
> Ich würde ein C-Style Funktionsinterface einbauen, das den C++ Teil
> wegkapselt. Damit kannst du dann in labVIEW arbeiten.
>
> Die C++ Klassen wirst du nicht in labVIEW verwenden können.

Diese C-Style Funktionsinterface sollte für das ganze Dll2 File gültig 
oder?

Das heisst wenn ich in dieses DLL File 20 Klassen habe, muss ich die 
dann alle in einem C-Style Funktionsinterface umschreiben.

liege ich richtig?

Niko schrieb:
> Das heisst wenn ich in dieses DLL File 20 Klassen habe, muss ich die
> dann alle in einem C-Style Funktionsinterface umschreiben.
Das ist doch Käse. C++ ist auch keine Magie, das basiert auf den 
gleichen Techniken wie C, insbesondere das ABI. Durch Aufrufen der 
richtigen Funktionen mit den richtigen Parametern kannst du auch eine 
C++ DLL direkt verwenden. Interessant wäre halt zu wissen, welche 
Möglichkeiten LabView hier überhaupt bietet. Einfach nur exportierte 
DLL-Funktionen aufrufen und Integer übergeben? Dann spricht doch wenig 
dagegen, einfach Instanz-Zeiger mitzuübergeben und somit 
Memberfunktionen aufzurufen.

Dr. Sommer schrieb:

> Das ist doch Käse. C++ ist auch keine Magie, das basiert auf den
> gleichen Techniken wie C, insbesondere das ABI. Durch Aufrufen der
> richtigen Funktionen mit den richtigen Parametern kannst du auch eine
> C++ DLL direkt verwenden. Interessant wäre halt zu wissen, welche
> Möglichkeiten LabView hier überhaupt bietet. Einfach nur exportierte
> DLL-Funktionen aufrufen und Integer übergeben? Dann spricht doch wenig
> dagegen, einfach Instanz-Zeiger mitzuübergeben und somit
> Memberfunktionen aufzurufen.


Ich verstehe nicht ganz was du meinst. Sorry

Wenn ich meine DLL (wie es jetzt ist(in C++)) importiere, kann ich 
einfach keine Funktion selektieren.

Niko schrieb:
> Wenn ich meine DLL (wie es jetzt ist(in C++)) importiere, kann ich
> einfach keine Funktion selektieren.
Sind denn die Funktionen die du aufrufen willst korrekt exportiert in 
der DLL? Hab grad nicht 100% im kopf wie das unter Windows ging, ich 
meine man musste __declspec(dllexport) oder sowas dranschreiben.

Ja das habe ich auch so gemacht

Niko schrieb:
> Ja das habe ich auch so gemacht
Zeigen. Nimm mal Depwal ( http://www.dependencywalker.com/ ) um zu sehen 
ob der die exportierten Funktionen anzeigt.

Dr. Sommer schrieb:
> Zeigen. Nimm mal Depwal ( http://www.dependencywalker.com/ ) um zu sehen
> ob der die exportierten Funktionen anzeigt


Du hast vollkommen recht.
Es wurde nichts exportiert.

Ich mache es betimmt was falsch.

Niko schrieb:
> Ich mache es betimmt was falsch.
Ja, du hast deinen C++ Code noch nicht gezeigt.

meine c++ code anhand einen beispiel sieht so aus:

1

namespace MathFuncs

2

{

3

  class MathFuncsDll

4

  {

5

  public:

6

    // Returns a + b

7

    static __declspec(dllexport) double Add(double a, double b);

8

9

    // Returns a - b

10

    static __declspec(dllexport) double Subtract(double a, double b);

11

12

    // Returns a * b

13

    static __declspec(dllexport) double Multiply(double a, double b);

14

15

    // Returns a / b

16

    // Throws DivideByZeroException if b is 0

17

    static __declspec(dllexport) double Divide(double a, double b);

18

  };

19

}

Niko schrieb:
> meine c++ code anhand einen beispiel sieht so aus:
Sieht eigentlich gut aus. Das ist ja schon fast ein un-OOP-C API, da 
kannst eigentlich gar nichts wrappen. Dann muss beim Compiler etwas 
falsch eingestellt sein.

Boris P. schrieb:
> Ähh, das sind Methoden, keine Funktionen. Die kannst du nicht
> exportieren!
In C++ sagt man lieber Member-Funktion statt Methode. Und ja, die kann 
man selbstverständlich exportieren, wie das zB die Microsoft-eigenen 
MFC-DLLs machen.
> Wie sollen die auch aufgerufen können ohne Objektinstanz?
Indem man eine anlegt und den Pointer darauf als 0. Parameter übergibt. 
Da Niko's Member-Funktionen aber statisch sind gibt es keine Instanz.
>
> Nicht umsonst habe ich dir einen C-style Funktionswrapper empfohlen.
Das macht aber 0 Sinn, denn was würde dieser Wrapper genau tun? Gar 
nichts, nur den Code verkomplizieren.
>
> Dr. Sommer schrieb:
>> Dann muss beim Compiler etwas
>> falsch eingestellt sein.
>
> Ich denke nicht
Ich denke doch, denn der Code ist korrekt.

Boris P. schrieb:
> Wie kannst du denn in labVIEW Objekte einer Klasse instanziieren?
Entweder:
1) Aufruf einer Factory Funktion in der DLL die eine Instanz anlegt und 
einen Pointer zurückliefert - die Standardmethode die von vielen C++ 
Libraries verwendet wird
2) Anlegen des Speichers und Aufruf des Konstruktors. Erfordert Kenntnis 
über die Größe des Objekts, kann
aber effizienter sein wenn man das Objekt auf den Stack packt o.ä. Eher 
hässlich, sollte man nur tun wenn wirklich erforderlich.

Boris P. schrieb:
> So wie ich das sehe, geht das nur über die eingebundene DLL.
Logischerweise.

Boris P. schrieb:
> Z.B. das Instanziieren bzw. Aufräumen des Objekts übernehmen
Ah. Dein Instanziieren entspricht vermutlich der Factory Funktion - die 
ist aber nicht wirklich ein C Wrapper sondern einfach eine freie oder 
statische Member- Funktion. Wenn man das so macht ist es tatsächlich 
sinnvoll auch eine Löschfunktion vorzusehen die den Speicher freigibt 
und den Destruktor aufruft. Wenn man oben 2) gemacht hat ruft man direkt 
ohne Wrapper den Destruktor auf und löscht den Speicher selber.
Das heißt also man kapselt ausschließlich die (de) allokation in 
freie/statische Member-Funktionen. Der Rest der Funktionalität kann 
bleiben wie er ist, d.h. die Member-Funktionen ruft man einfach direkt 
auf. Kein Grund für C-Wrapper.

Mich interessiert immer noch wie er denn an diese exportierten Member 
der Klasse in seinem C++ Code herankommt.

Hallo alle zusammen,

Boris P. schrieb:
> Wie läuft's bei Niko?

Die Methoden können von Labview gelesen werden seh Bild1.

Ich kann leider die Methoden nicht ausführen seh bitte Bild2.


Da ich neuling in Labview bin, weiss es nicht was habe ich falsch 
gemacht.

Niko schrieb:
> Ich kann leider die Methoden nicht ausführen seh bitte Bild2.

Mit demselben DLL Code? Mit geändertem DLL Code?

bei alle drei Methoden, kann ich keine Funktion ausführen.
seh bitte Bild3.

lalala schrieb:
> Mit demselben DLL Code? Mit geändertem DLL Code?

Mit demselben DLL Code

lalala schrieb:
> Mich interessiert immer noch wie er denn an diese exportierten
> Member
> der Klasse in seinem C++ Code herankommt.
Habe mal schnell ein Beispiel zusammengecodet. Zum Anlegen der Instanz 
ruft man die exportierte Funktion "_ZN4Test12makeInstanceEid" auf und 
merkt sich den 64bit-Rückgabewert (=Pointer), der die Instanz darstellt.
Zum Aufruf der calculate-Funktion die exportierte Funktion 
"_ZN4Test9calculateEd" aufrufen, als 0. Parameter den Instanz-Pointer 
übergeben, als 1. Parameter einen double. Um getX/getY zu aufzurufen 
ruft man die exportierten _ZN4Test4getXEv / _ZN4Test4getYEv auf und 
übergibt den Instanz-Pointer. Zum Löschen ruft man 
ZN4Test14deleteInstanceEPS auf und übergibt ebenfalls die Instanz.
Die Funktionsnamen sehen wegen des Name Mangling wie gesagt etwas lustig 
aus, die von mir genannten entstehen bei der Verwendung vom GCC, wenn 
man Visual Studio verwendet kommen vermutlich andere raus; muss man sich 
dann zB mit Depwalk anschauen.
Das ganze wie man sieht ohne irgendwelchen "C-Wrapper".

Boris P. schrieb:
> Sollten die Funktionsnamen nicht unabhängig vom Compiler sein?
Leider sind die nirgends wirklich standardisiert. Ich meine aber sein 
dass der GCC hier das Schema vom Visual Studio nachmacht, ich weiß es 
gerade nicht und hab auch grad kein VS zur Hand.
> Ich kenne
> DLL-Exports nur so, dass der Name der Funktion dem entspricht, was man
> auch im Code vergeben hat.
Das geht aber nicht, da zB "Test::deleteInstance(Test*)" kein gültiges 
Linker-Symbol ist, "_ZN4Test14deleteInstanceEPS_" hingegen schon.
> Ansonsten ist der Ärger doch schon vorprogrammiert???
Jup...

Boris P. schrieb:
> Das wäre doch schon mal ein Grund nicht auf exportierte Methoden
> zurückzugreifen, sondern doch ein C-Style Interface zu verwenden, oder?
Naja, das Schema wird sich so schnell nicht ändern (dann wären ja alle 
Windows-DLL's nicht mehr nutzbar). Wenn es unbedingt sein muss kann man 
da noch dumme extern "C" -Wrapper drum machen damit das Symbol einen 
"definierten" Namen hat, aber eigentlich gibt es keinen wirklichen 
technischen Grund nicht einfach "_ZN4Test14deleteInstanceEPS_" 
aufzurufen.

@Autor: Dr. Sommer (Gast)

was mache ich dann falsch?

ich habe so meine Code(C++) so angepasst, dass es so aussieht.
[c]
    class MyMathFuncs
    {
    public:
        // Returns a + b
         __declspec(dllexport)double Add(double a, double b);

        // Returns a - b
         __declspec(dllexport)double Subtract(double a, double b);

        // Returns a * b
         __declspec(dllexport)double Multiply(double a, double b);

        // Returns a / b
        // Throws const std::invalid_argument& if b is 0
         __declspec(dllexport)double Divide(double a, double b);
    };

[/]

ich habe so meine Code(C++) so angepasst, dass es so aussieht.

1

    class MyMathFuncs

2

    {

3

    public: 

4

        // Returns a + b

5

         __declspec(dllexport)double Add(double a, double b); 

6

7

        // Returns a - b

8

         __declspec(dllexport)double Subtract(double a, double b); 

9

10

        // Returns a * b

11

         __declspec(dllexport)double Multiply(double a, double b); 

12

13

        // Returns a / b

14

        // Throws const std::invalid_argument& if b is 0

15

         __declspec(dllexport)double Divide(double a, double b); 

16

    };

Niko schrieb:
> @Autor: Dr. Sommer (Gast)
>
> was mache ich dann falsch?
Tja mit LabView kenne ich mich auch nicht so aus. Ich hab mal deinen 
Code bei mir compiliert (einmal 32bit einmal 64bit) und die DLL's 
angehängt. Die Funktionen werden definittiv exportiert. Versuch mal aus 
der DLL die Funktion "_ZN9MathFuncs12MathFuncsDll3AddEdd" aufzurufen. 
Das sollte funktionieren, wenn nicht ist das ein LabView-spezifisches 
Problem...

@Dr. Sommer (Gast)
Kannst du mir bitte noch den Header file noch zuschicken?

mit der "dllclass.h" könnte ich gar keine Funktion exportieren.

Niko schrieb:
> @Dr. Sommer (Gast)
> Kannst du mir bitte noch den Header file noch zuschicken?
Was? Braucht LabView einen Header? Das ändert die Sache... Der Header 
wäre einfach das:

1

namespace MathFuncs

2

{

3

  class MathFuncsDll

4

  {

5

  public:

6

    // Returns a + b

7

    static __declspec(dllexport) double Add(double a, double b);

8

9

    // Returns a - b

10

    static __declspec(dllexport) double Subtract(double a, double b);

11

12

    // Returns a * b

13

    static __declspec(dllexport) double Multiply(double a, double b);

14

15

    // Returns a / b

16

    static __declspec(dllexport) double Divide(double a, double b);

17

  };

18

}

exportieren kann ich schon aber eben nur 3 Funktionen, die wie 
folgenden:

    Divide
    Multiply
    Subtract

warum nicht die Add Funktion weiss es nicht.

das ist auch den Report, die ich dazu bekomme:

VI Not Executable
The VI is not executable because of one of the following reasons:
1. The shared library or a dependent file is not installed. To make the 
VI executable, you must install the shared library and all support files 
on the computer on which you run the VI.
2. A required custom control might be empty or cannot be found. To make 
the VI executable, update the custom control manually.
3. The VI contains a parameter with an unsupported data type. To make 
the VI executable, you must replace the empty cluster that the wizard 
generates with a control or indicator that uses supported data types.
    Divide.vi
    Multiply.vi
    Subtract.vi


--> Ich kann gar keine Funktionen in Labview ausführen bitte seh Bild3

Fazit: Das DLL als C++ lässt sich leider nicht exportieren
 Folgende ànderung habe ich gemacht :

Header File

1

        extern "C" __declspec(dllexport)double Addi(double a, double b); 

2

3

        // Returns a - b

4

         extern "C" __declspec(dllexport)double Subtract(double a, double b); 

5

6

        // Returns a * b

7

         extern "C" __declspec(dllexport)double Multiply(double a, double b); 

8

9

        // Returns a / b

10

        // Throws const std::invalid_argument& if b is 0

11

         extern "C" __declspec(dllexport)double Divide(double a, double b);

c.File

1

    double Addi(double a, double b)

2

    {

3

        return a + b;

4

    }

5

6

    double Subtract(double a, double b)

7

    {

8

        return a - b;

9

    }

10

11

    double Multiply(double a, double b)

12

    {

13

        return a * b;

14

    }

15

16

    double Divide(double a, double b)

17

    {

18

        if (b == 0)

19

        {

20

            throw invalid_argument("b cannot be zero!");

21

        }

22

23

        return a / b;

24

    }

--> Resultat :

Dieses DLL kann ich mit Labview exportieren

Meine Frage:
Dieses Testprojekt ist nur als Test gedacht wie soll ich denn machen in 
meinem Projekt, der über 30 Klassen als in einem C-Style umschreiben????

Hat jemenden Erfahrung mit einen export von "C++ DLL"
Danke in voraus.

Niko schrieb:
> Dieses DLL kann ich mit Labview exportieren
Dann macht LabView da komische Dinge. Auf "binärer" Ebene ist 0 
Unterschied zwischen beiden DLL's, nur die Namen der Funktionen sind 
anders. Keine Ahnung wie man LabView dazu bringt einfach eine gegebene 
Funktion aufzurufen :-/

Dr. Sommer schrieb:
> Unterschied zwischen beiden DLL's, nur die Namen der Funktionen sind
> anders


Ich habe der Funktionsname von "Add" zu "Addi" geändert weil ich gedacht 
habe.Es könnte vielleicht einen Fehler sein, weil es Schlüsselwort sein 
kann.

Fazit:

Änderung der name hat nichts gebracht und das ist gültig für die C++ DLL 
export.

Lies mal den Namen mit Dependency Walker aus und trage ihn manuell in 
den Lib-Node von Labview ein. Das ist unschön, sollte aber gehen.

Einen schönen guten Morgen Zusammen,

ich bin gestern Abend im Internet auf folgende Seite: 
"http://labviewwiki.org/DLL/shared_library"; gestossen.

Ich könnte dieses Beispiel bei mir in Visual Studio abbilden und daraus 
einen DLL erstellen.Dann habe ich in Labview importiert.
Es funktioniert alles so weit so gut.

Nur mir ist nicht klar wie ich dieses Beispiel in Labview zum laufen 
bringe?

@Florian Kulling Danke


Es hat mit diesem demo Projekt alles funktioniert.
In meinem Projekt sieht die lage etwas anders aus.

Ich habe zwei DLL File die eigentlich von einander abhängig sind.
Das DLL2 wird von DLL 1 gebraucht.
Die Funktionalität, die ich brauche befindet sich In DLL2.

Ich weiss es nicht wie ich am besten vorgehen soll?
Soll ich für jeden DLL eine Labview Import mit den nötigen DLLWrapper 
und dann die Funktionen mit Labview konfigurieren?

Wenn ich nur für DLL1 einen Labview Import mache (und bestimmte 
funktionalität von DLL1 gebraucht sind), dann funktioniert das ganze 
bestimmt nicht.

Ist meine vorhaben überhaupt machbar?

Noch eine Frage Bitte:
Beim DLL Erstellung(Visual Studio):
Spielt eine Rolle, ob der DLL von eine Release Version oder Debug 
Version ist?

@Avr Noob Danke :-)
Avr Noob schrieb:
> Lustige Frage. Ich denke, dass Du sie Dir selbst beantworten kannst wenn
> Du drueber nachdenkst.

Ich weiss es was für einen Unterschied zwischen debug und Release 
Version.
Aber die Frage war bezogen auf Labview.
Hat Labview Problem mit einem DLL (Release) oder DLL(Debug)?
Was ist besser?

Avr Noob schrieb:
> Funktionieren muessen in LabIEW beide.

eben nicht

warum weiss ich nicht, deswegen kam die Frage.

Avr Noob schrieb:
> Ich habe mir das Problem mal angesehen und wuerde gerne die DLL (von Dr.
> Sommer) in LabVIEW einbinden, um ein Ergebnis praesentieren zu koennen.
Ja das wär cool.
> Leider meckert LabVIEW beim importieren, dass die Datei
> LIBGCC_S_SJLJ-1.DLL fehlt.
Hubbs, vergessen. Da sind Hilfsfunktionen von der C-Umgebung von MinGW 
drin. Hab mal die aus meiner (der Ubuntu-) MinGW Distribution angehängt 
(32 & 64 bit).

Avr Noob schrieb:
> Funktionieren muessen in LabIEW beide.
Kommt drauf an, nur wenn auf dem Zielsystem alle DLL's, die von der 
Debug-Version gebraucht werden, installiert sind; wenn Visual Studio 
installiert ist ist das der Fall, sonst nicht unbedingt. Die von der 
Release-Version benötigten DLL's sollten aber überall installiert sein, 
wimre.

Niko schrieb:
> Was ist besser?
Da du aus LabVIEW eh nicht debuggen kannst bietet die Debug-Version wohl 
kaum Vorteile, während die Release-Version schneller&kleiner ist und 
auch auf jedem Windows funktionieren sollte.

Niko schrieb:
> Wenn ich nur für DLL1 einen Labview Import mache (und bestimmte
> funktionalität von DLL1 gebraucht sind), dann funktioniert das ganze
> bestimmt nicht.

Solange sich DLL1 wie Du schreibst selber darum kümmert das DLL2 geladen 
wird, kann das kein Problem sein.

Avr Noob schrieb:
> @ Dr.Sommer. Laeuft!
Ha, super ;-) dank dir siehts jetzt nicht so aus als hätt ich nur Unsinn 
erzählt :o)

Avr Noob schrieb:
> LV Function Prototype:
> double _ZN9MathFuncs12MathFuncsDll3AddEdd(double arg1, double arg2);
Genau so war das gedacht.

@Dr.Sommer
Kannst du mir bitte deine Quellen Code von deine Example zu verfügung 
stellen.
Ich möchte gucken wie du mit dem Factory gemacht hast?
und dann anschliessen in Labview testen.
Danke in Voraus

Niko schrieb:
> @Dr.Sommer
> Kannst du mir bitte deine Quellen Code von deine Example zu verfügung
> stellen.
Der ist doch oben schon in einzelteilen...

Hab ihn hier nochmal zusammen gestellt, alles in einem.
Der Ordner "dllclass" im Zip enthält eine DLL die eine C++ Klasse mit 
Factory und nichtstatischen Funktionen enthält.
Der Ordner "dllstatic" im Zip enthält eine DLL die statische 
Member-Funktionen einer Klasse exportiert, die direkt aufgerufen werden 
können. Das ist die DLL die Avr Noob (balze) erfolgreich in LabView 
verwendet hat.

Der Ordner libgcc enthält die libgcc DLL die Hilfsfunktionen für die C 
Runtime enthält, stammt aus MinGW.

Alle DLL's jeweils als 32bit und 64bit Version, kompiliert mit MinGW 
unter Ubuntu.

@Dr.Sommer
10000 Dank

Avr Noob schrieb:
> Ich bin LabVIEW Programmierer und kenne mich nur am Rande mit C++ aus.
Na is doch super, sind wir die optimale Beratung bei diesem Problem ;-)
> Deshalb meine dumme Frage:
> Bedeutet "static" nicht auch, dass die Funktion nicht mehr ueberladen
> werden kann?
Nö, das geht immer noch:

1

#include <string>

2

3

class Foo {

4

  public:

5

    static void test (int x);

6

    static void test (double x);

7

    static void test (std::string x);

8

};

9

10

11

int main () {}

"static" bewirkt nur dass die Funktion nicht zu einer bestimmten Instanz 
gehört und somit ohne Instanz der Klasse aufgerufen werden kann, ähnlich 
einer "globalen"(freien) Funktion.
> Das torpediert das Objekt-Orientierte-Konzept aber
> ordentlich, oder?
Naja, SO wichtig sind Überladungen für OOP jetzt nicht, aber sie sind 
schon praktisch.
> Ich wollte mir gerne die "echte" Klassenloesung ansehen. Leider fehlt
> beim Importieren auch hier eine DLL (libstdc++-6.dll).
Oh, und ich hab noch überlegt ob die gebraucht wird... Ist im Anhang, 
auch im libgcc Verzeichnis.

Avr Noob schrieb:
> Danke Herr Dr.
>
> aber das mit dem 0. Parameter funktioniert mit LabVIEW garantiert nicht.
> Wie kann man denn bei C++ einen Funktionaufruf mit einem zusaetzlichen
> 0. Parameter machen?
Ich glaub ich hab mich blöd ausgedrückt... Mit 0. Parameter meinte ich 
halt ganz normal den Anfang der Parameterliste:

1

myFunction (a, b, c, d);

Hier ist a der 0. Parameter. Für einen Aufruf einer nichtstatischen 
Member-Funktion ist dieser 0. Parameter eben der Pointer auf die 
Instanz, der zuvor von der Factory-Funktion zurückgegeben wurde. Und ein 
Pointer unter x86(_64) ist im Endeffekt nichts anderes als ein 32/64 bit 
Integer, und die sollte LabVIEW ja verarbeiten können?!

@ Avr Noob


Ich habe das lv-dll.zip von Herr.Dr (Danke) ausprobiert. Ich könnte die 
Funktionen öffnen aber leider nicht konfigurieren.
Da ich einen Einsteiger in labview bin fehlen mir die Idee was lauft 
dann schief...?


Ich habe Labview 2012 und der DLL File wurde mit Visual studio 2012 
erstellt.
anbei ist die das ganze Zip mit allem (VI, DLL und Header ).


Danke in voraus.

Diese DLL exportiert gar keine Symbole, da kann also kein Programm 
irgendwas mit machen, weder LabView noch ein C++ Programm noch 
sonstwas...
Da muss beim Compilieren irgendetwas schief gelaufen sein. Versuch mal 
meine DLL, die exportiert u.a. folgende Symbole:

1

6cbc154c T __ZN4Test12makeInstanceEid

2

6cbc158c T __ZN4Test14deleteInstanceEPS_

3

6cbc1536 T __ZN4Test4getXEv

4

6cbc1540 T __ZN4Test4getYEv

5

6cbc14e6 T __ZN4Test9calculateEd

6

6cbc14c0 T __ZN4TestC1Eid

7

6cbc14c0 T __ZN4TestC2Eid

Da müsstest du dann ZN4Test12makeInstanceEid aufrufen können und dabei 
einen integer und ein double übergeben, den Rückgabewert (der die 
Instanz darstellt und ein 32/64bit Pointer ist) merken, und den zB an 
__ZN4Test4getXEv übergeben um getX() auf dieser Instanz aufzurufen.

@ Herr Dr.Sommer

Ich verstehe nur Bahnhof

Avr Noob schrieb:
> Moin Moin zusammen,
>
> @Dr. Sommer: Laeuft!
HA, großartig ;-)
> Das mit dem zusaetlichen Parameter ist mir neu (und ziemlich (!) fremd).
> Ist das uebliche Vorgehensweise und moeglicherweise auch irgendwo so
> dokumentiert?
Ja, das ist Teil des ABI. Der GCC verwendet wohl das Itanium ABI, MSVC 
irgendein eigenes komisches... Da muss man ein bisschen Googlen um die 
richtigen Infos zu finden. Dass der Instanz-Pointer als 0. Paramter 
übergeben wird ist aber glaubich ziemlich überall so. Im ABI stehen noch 
jede Menge andere definitionen, z.B. wie die Parameter übergeben 
werden (Register, Stack), wie Exceptions übergeben werden, wie diese 
lustigen Funktionsnamen zustande kommen, etc.
> @Niko:
> Versuch doch erstmal die statische DLL zum Laufen zu bringen.
> Ich habe meine Versionen jetzt fuer LV 12 angehaengt. (Wie gesagt, PNG
> in leeres VI droppen)
Dann wird das bei ihm automatisch importiert?! Ist ja cool. Wenn nicht, 
kannst du vielleicht deine LabView Dateien mal anhängen damit er einen 
Ausgangspunkt hat ;-)

Eine Frage bitte:
wo finde ich die Funktionen bzw. das DLL File?

6cbc154c T __ZN4Test12makeInstanceEid
6cbc158c T _ZN4Test14deleteInstanceEPS
6cbc1536 T __ZN4Test4getXEv
6cbc1540 T __ZN4Test4getYEv
6cbc14e6 T __ZN4Test9calculateEd
6cbc14c0 T __ZN4TestC1Eid
6cbc14c0 T __ZN4TestC2Eid


Sorry
es ist mir peinlich genug

Niko schrieb:
Jungeeeeeee
> Eine Frage bitte:
> wo finde ich die Funktionen bzw. das DLL File?
Beitrag "Re: C++ DLL in Labview einbinden"  daaa im Anhang
>
> 6cbc154c T __ZN4Test12makeInstanceEid
> 6cbc158c T _ZN4Test14deleteInstanceEPS
> 6cbc1536 T __ZN4Test4getXEv
> 6cbc1540 T __ZN4Test4getYEv
> 6cbc14e6 T __ZN4Test9calculateEd
> 6cbc14c0 T __ZN4TestC1Eid
> 6cbc14c0 T __ZN4TestC2Eid
Die Liste der exportierten Funktionen kann man im Dependency Walker 
sehen, oder mit "nm" falls man MinGW installiert hat

@Avr Noob
    und
 @ Dr.Sommer


Danke und noch mal Danke....

Avr Noob schrieb:
> 1. Lade Dir das PNG herunter (DLL_Class_factory_Test.png)
> 2. Oeffne ein leeres VI mit LV2012
> 3. Wechsle zum Blockdiagram (Strg+E)
> 4. Ziehe das PNG mit der Maus auf das Blockdiagram
> 5. Voilá, des Raetsels Loesung
>
> (Evtl. musst Du das VI speichern und neu oeffnen. Und zwar in dem Ordner
> in dem auch die DLLs liegen!)

Ich habe genau so gemacht aber leider bekomme ich immer eine 
Fehlermeldung.
Seh bitte Anhang.

@Avr Noob

Es funktioniert  :-)


100000000000000000000 Dank
Sorry für die Umstände

@Avr Noob

was für Literatur "Labview" kannst du mich empfehlen?

Nicht in diesen technischen Details, die jetzt bei der DLL helfen 
würden, aber um schönen (=guten) LabView Code zuschreiben:
http://www.amazon.com/LabVIEW-Style-Book-Peter-Blume/dp/0131458353

@Avr Noob

Danke noch mal
wenn ich dich nochmal Frage:

Ich habe oben in diesen Beitrage meine Vorhaben schon geschildert.
was würdest du machen?