INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Objekt-Orientiertes Programmieren mit LV8.5



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

26.12.2007, 18:30
Beitrag #1

robertow Offline
LVF-Grünschnabel
*


Beiträge: 21
Registriert seit: Jul 2006

2010
2003
kA

8010
Oesterreich
Objekt-Orientiertes Programmieren mit LV8.5
Hallo und fröhliche Weihnachten an Alle!

Ich hab mal einige Fragen bezüglich Objekt-Orientiertem Programmieren in LabVIEW 8.5:
1) Gibt es irgendwelche Experten auf dem Gebiet hier im Forum? *G*
2) Ich hab im Sinn in späterer Zukunft vielleicht eine Art Vergleich zwischen LabVIEW und C++ zu erstellen, dazu bräuchte ich allerdings einige Informationen:

Ein Beispiel (ich hoffe, man weiß, was ein Graph im Allgemeinen istSmile):
Ich erstelle ein Objekt der Klasse Graph. Dieses Objekt besteht aus einigen Methoden und den Eigenschaften Name (String) und einem Array mit Knoten (Klasse Knoten). Die Klasse Knoten besteht nun ihrerseits aus den Eigenschaften Name (String) und einem Array mit weggehenden Kanten (Klasse Kante). Die Klasse Kante besteht aus einer Eigenschaft Name (String) und einem Endknoten (Klasse Knoten). Soviel zur Aufgabenstellung bzw. dem Design.
Die erste Sache ist schon mal, dass es von Vorteil (-->Laufzeit) wäre, wenn ich in den Listen nicht Objekte sondern Pointer auf die Objekte hätte. Weiters kann man ja nicht einen Member einer Klasse erstellen, dessen Member eben diese Klasse ist (ein Knoten enthält eine Liste von Kanten, die wiederum Endknoten beinhalten). Wie geht das nun sauber bzw. überhaupt in LabVIEW? Ich hab schon einiges mit Referenzen versucht, dass am Anfang sehr gut aussah, jedoch nirgendwo hinführte, da LabVIEW Speicher von Objekten, die in SubViews erstellt wurden, nach deren Laufzeit wieder freigibt. C++ macht das mit Lokalen Variablen (also Variablen in Unterfunktionen) ja auch, man kann jedoch auch explizit Speicher reservieren mit zB: New oder malloc. Natürlich darf man nicht vergessen, den dann auch wieder 'manuell' freizugebenSmile. Kann man sowas in LabVIEW auch machen? Oder zumindest irgendwo angeben, dass Objekte solange 'leben' sollen, solange es auf Referenzen drauf gibt?

Weiters würde mich auch interessieren, was genau passiert, wenn man die in LabVIEW 8.5 neu hinzugefügte Struktur "In Place Element" verwendet. Die Phrase "In Place" bedeutet meines wissens, dass eine Aktion bzw. ein Algorithmus ausgeführt wird, ohne zusätzlichen Speicher zum Input zu verwenden. Entweder sind Referenzen was anderes, oder dieses In-place ist nicht wirklich das, was es vorgibt (siehe Anhang [LV8.5]).

Ich hoffe, es kann mir jemand weiterhelfen,
Lg und noch einen Guten Rutsch ins neue Jahr,
euer robertow

PS: Wieso gibts eigentlich kein Unterforum OOP mit LV? Blink


Angehängte Datei(en)
Sonstige .vi  Call_square_element.vi (Größe: 10,96 KB / Downloads: 496)

Sonstige .vi  square_element.vi (Größe: 8,56 KB / Downloads: 458)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Nachrichten in diesem Thema
Objekt-Orientiertes Programmieren mit LV8.5 - robertow - 26.12.2007 18:30

Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  VIP 2012: Einführung in das objekt-orientierte Programmieren mit LabVIEW BNT 8 20.043 28.10.2012 18:40
Letzter Beitrag: Y-P
  Objekt in globaler Variable Stephan 13 25.504 24.06.2012 21:50
Letzter Beitrag: Kiesch
  Zugriff von Objekt auf Objekt dessen Attribut es ist Kiesch 1 9.602 26.10.2011 10:28
Letzter Beitrag: Kiesch
  Objektorientiertes Programmieren mit LV cabua 90 102.482 18.08.2009 09:57
Letzter Beitrag: cabua

Gehe zu: