Frage zu Arrays

' schrieb:BTW ist das oben gezeigte Diagramm sonst ok?

Naja, eigentlich nein.
Da sind lauter Wires mit unnützen Ecken und Überschneidungen. Das geht so nicht.
Außerdem würde ich zum Anhängen das Element "Erstelle Array" verwenden anstelle von "In Array einfügen".

Ansonsten ist es wohl richtig: Wenn du das Feld "Array" (der Name ist auch schlecht gewählt) erweitern willst, muss du es so entbundeln, erweitern und wieder bundeln.

Zitat:Also werden die Arrays tatsächlich immer kopiert, so dass ich sie immer wieder neu zuweisen muss?

Du musst sie nicht neu zuweisen. Das geht ja alles automatisch.
Durch das Entbundeln entsteht eine Datenkopie ("Array"). Mit dieser Kopie wird gearbeitet. Beim Bundeln wird die eben erweiterte Kopie wieder in die Klasse kopiert. Es ist also nicht so, dass über einen Pointer in den Speicher geschrieben wird, der physikalisch immer in der Klasse liegt.
Hinweis:
Ein statisches Array kann man ganz leicht simulieren: Einfach ein dynamisches Array vorbesetzen mit der maximalen Anzahl von Elementen und dann immer "In Array ersetzen" verwenden.

Zitat:Ist es "good code" wenn man möglichst viel Klassen erledigt?

Sag ich mal so:
Guter LV-Code ist dann, wenn das Datenflußprinzip eingehalten ist. Und wenn alles wie es sich gehört sequenziert ist. Am besten noch mit Error-Cluster. Und wenn der Styleguide eingehalten wird.

Zitat:Oder sind unter LabVIEW andere Methoden/Programmierstile sinnvoller?

Da gehts mir wie dem GerdW: Ich hab für Klassen keine Verwendung. Es geht sehr gut ohne.
"Funktionale Globale Variablen" (FGV) sind ein ideales Mittel, um Daten gekapselt zu halten: Kapselung, Properties, private Methoden/Felder etc. - alles ohne OOP mit FGVs möglich. Multithreading geht sowieso automatisch in LV, ohne dass es der Programmierer merkt. Und zum Datenaustausch zwischen unabhängigen Programmteilen gibt es Queues und Melder.

Der OOP-Hintergrund fehlt mir als altem (?) Delphi-Programmierer zwar nicht, Klassen im Lehrbuchstil mach ich aber trotzdem weder in Delphi noch in LV.