LVOOP - wann wird Kopie erstellt?

Ich hab zwar schon ein wenig Erfahrung mit LV aber noch nicht besonders viel mit LVOOP. Auch OOP glaube ich generell verstanden zu haben ^^
Was mich allerdings beschäftigt (weil ich beim lesen von Threads zu LVOOP drauf gestoßen bin):

Wann genau erstellt Labview Kopien von Objekten? Es gibt ja eine by Value Syntax, was ja an sich grundsätzlich kein Nachteil ist (man kann sehr schnell aus einem Objekt zwei verschiedene machen wenn man es braucht), allerdings stellt sich für mich dann die Frage, wann genau wirklich Kopien erzeugt werden.
Bei Verzweigungen muss das ja notwendigerweise passieren, allerdings habe ich aus den anderen Threads (schon etwas ältere) zwischen den Zeilen herausgelesen, dass auch bei der Übergabe an ein SubVI eine Kopie erzeugt wird. Ist das (immer noch?) richtig?
Ich dachte bisher immer Labview geht sparsam mit Kopien um und macht die nur wenn "notwendig" (also bei Verzeigungen).

Gruß Kiesch

P.S: Konkret stellt sich die Frage, da natürlich Objekte mit Objekten als Attributen schnell sehr "groß" werden können und ich nicht mein ganzes aktuell funktionierendes Programm nach OO umstelle, nur um dann festzustellen, dass das so nicht vernünftig funktioniert....

Hi Kiesch
im Prinzip liegst Du richtig. In dem folgenden Link wird etwas über das Memory Management von LVOOP Objekten geschrieben: The Decisions behind the Design. Und hier etwas zum Compiler: LabVIEW Compiler under the Hood.

Ich denke der Compiler ist im Laufe der Zeit ziemlich schlau geworden. Ich benutze LVOOP Objekte wie Typedefinitionen und habe dabei bisher keine Speicher- oder Laufzeitprobleme entdecken können.

Gruß Holger

Ich habe irgendwo in den Tiefen der LabVIEW Hilfe gelesen, dass LabVIEW nur Kopien bei Übergabe an ein Sub VI macht wenn das entsprechende Control innerhalb irgendeiner Struktur, Schleife ect. des Sub VIs liegt. Deshalb sollte man die Controls und Indocators immer auf die sogenannte BlockDiagram Root, also außerhalb jeder Struktur, legen.

Edit:
Ach ja und natürlich das FP des Sub VI nicht anzeigen.

Moin

LVOOP Kontrollen & Indikatoren sollten auf dem Frontpanel nichts ausmachen, da die Attribute privat sind. Dort sollte nur der Verweis auf die Objektdaten gespeichert sein. Sonst ist Deine Aussage natürlich richtig.

Wenn man den Ein- und Ausgäng eines SubVIs, speziell den Objektdraht, in einem Shift-Register festhält, sollte beim Call-By-Value auch nicht notwendig eine Objektkopie angelegt werden, sondern nur wenn es das subVI notwendig erfordert, bzw. der Objektdraht zusätzlich an dem subVI vorbei in ein anderes subVI verdrahtet wird. Und auch dann nur, wenn in beiden subVIs das Objekt geändert wird. Der Compiler denkt da ziemlich tiefgehend drüber nach.

Gruß Holger

Okay, heist: Auch Lesezugriffe erzwingen keine Objektkopien?


Noch eine Frage:

"Bauartbedingt" kann man ja in Labview kein klassisches build durchführen. Das heist also Datenkonsistenz (bei der Erstellung) erzwingt man nur durch die Option Standardwert (für Objekteigenschaften) setzen? Und natürlich in den Zugriffsprozeduren...

(21.10.2011 09:40 )Kiesch schrieb:  Okay, heist: Auch Lesezugriffe erzwingen keine Objektkopien?

Genau, es wird nur der Speicher für die gelesenen Attribute angelegt.

(21.10.2011 09:40 )Kiesch schrieb:  Noch eine Frage:

"Bauartbedingt" kann man ja in Labview kein klassisches build durchführen. Das heist also Datenkonsistenz (bei der Erstellung) erzwingt man nur durch die Option Standardwert (für Objekteigenschaften) setzen? Und natürlich in den Zugriffsprozeduren...

Selbstverständlich kann man aus LabVIEW-VIs Executables erzeugen. Dafür benötigt man den Application-Builder, der in der Professional-Version enthalten ist.

Datenkonsitenz? Wenn ein LabVIEW-VI direkt gestartet wird, kopiert es die Werte der Kontrollen auf die Datenquellen im Blockdiagramm. Wenn es als SubVI aufgerufen wird, werden die Daten Eingangsdaten des aufrufenden VIs als Datenquelle im Blockdiagramm benutzt.

Die Attribute von LVOOP-Objekten sind privat. Daher werden beim direkten Start eines VI die Werte des Frontpanel-Elements benutzt, das in diesem Fall die Default-Werte enthält.

Gruß Holger

Sorry, Missverständnis, mir ging es um den "klassischen" Konstruktor, der ja (auch) dazu dient Datenkonsistenz (im Sinne von zusätzlichen Einschränkungen des Wertebereichs) innerhalb des Objekts sicherzustellen. *Zum Beispiel festzulegen, dass nur die Zahlen von -10 bis 10 gültige Attributwerte sind (oder ähnliches, komplexeres).

Hat sich von LV 2010 zu LV 2011 maßgeblich was an den Möglichkeiten bei LVOOP getan? Überlege nämlich gerade auch ob ich vielleicht updaten sollte.

Kann leider schon nicht mehr bearbeiten:

2 Sachen:

1. vielleicht kann mal jemand den Titel in "Allgemeine Regeln zum Programmieren mit LVOOP" oder so ändern, da ich

2. noch eine Frage habe die nur noch am Rande mit dem Ausgangsproblem zu tun hat:

Ist es sinnvoll Setter und Getter Methoden festzulegen und dann auf die Objekteigenschaften über den Eigenschaftsknoten zuzugreifen? Soweit ich das verstanden habe werden ja dabei nur die Setter und Getter ausgeführt (samt selbst implementietem Fehlerbehandlung)?
Mit der Variante kann man nämlich (meiner Meinung nach) "natürlicher" Labview programmieren ohne ständiges unbundle, auslesen, modifizieren etc. Oder gibt es dabei noch andere Nachteile?

Ist es außerdem möglich den Methodenknoten auf Klassen zu benutzen? (wenn ich einfach anschließe meckert er, dass er ne Referenz erwartet und kein Klassenobjekt)

Gruß Kiesch

P.S: Schönes Wochenende