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!
Testweise schreibe ich grade an einem Polymorphen VI, was eine beliebige Zahl durch 2 teilen soll.
Später soll dann auch die Möglichkeit gegeben sein, mit einer Kopie dieses Polymorphen VIs
andere Teiler zu verwenden. Der einzige Zweck ist, dass ich gerne bei einer unären mathematischen
Operation auch ein SubVi mit nur einem Anschluss haben möchte und nicht mit zwei wie bei dem Dividieren
SubVi aus der Funktionenpalette.
Mir fehlt hierfür grade so ein bisschen die vom C++ her bekannte Template Programmierung.
LabView hat offensichtlich 15 verschiedene numerische Datentypen und es erscheint mir gerade etwas verschwenderisch
ein polymorphes SubVi mit 15 verschiedenen Anschlusstypen zu erstellen.
Folgendes habe ich versucht:
- Ein Kern Vi, welches ein Variant durch 2 teilt -> Variant kann man erst nach Umwandlung teilen (ist ja auch klar, weil die Variant ja auch
nicht numerische Typen ent[/align]halten kann)
- Ein Kern Vi, welches eine ExtendedCpxDbl durch 2 teilt -> lässt sich nicht so ohne weiteres zurückkonvertieren
- Hilfs VIs, welche verschiedene Eingangstypen in eine ExtendedCpxDbl umwandeln und nach Division wieder zurück
- Ein VI mit Variant Eingang, welches die Variant in eine ExtendedCpxDbl umwandelt und an das Kern VI übergibt, welches dann den halbierten Wert als ExtendedCpxDbl zurückgibt.
Wie auch immer man es dreht, es bleibt ein Grundproblem übrig:
1.) Entweder man hat 15 VIs für die 15 Datentypen, die alle im wesentlichen das Gleiche tun oder
2.) Man hat Schwierigkeiten wieder den Ausgangsdatentyp zurück zu erhalten
Hat jemand schon mal so etwas ähnliches probiert, evtl. sogar mit Express VI?
Mich würde interessieren wie andere das machen.
Wenn Du einer zweiten Variantenvariable (tolles Wort) den Typ mit gibst. Könntest Du in einem VI über eine IF Anweisung alle 15 Möglichkeiten abbilden.
Zitat:1.) Entweder man hat 15 VIs für die 15 Datentypen, die alle im wesentlichen das Gleiche tun
Eigentlich ja noch viel mehr: du vergisst, dass man auch mit Arrays beliebiger Dimension (und beliebigem numerischen Datentyps) rechnen kann. Und auch mit Clustern, wenn sie numerische Werte enthalten!
Zitat:2.) Man hat Schwierigkeiten wieder den Ausgangsdatentyp zurück zu erhalten
Ja.
Zitat:es erscheint mir gerade etwas verschwenderisch ein polymorphes SubVi mit 15 verschiedenen Anschlusstypen zu erstellen.
Das ist aber noch immer der einfachste Weg! (Für jeden von dir unterstützten Datentyp ein subVI deines polymorphen VIs anlegen!)
Zitat:Ein Kern Vi, welches ein Variant durch 2 teilt -> Variant kann man erst nach Umwandlung teilen (ist ja auch klar, weil die Variant ja auch
nicht numerische Typen ent[/align]halten kann)
Die Variant-Variante (auch ein schönes Wort!) hat aber einen GROSSEN Nachteil: Du musst entweder einen Variant ausgeben, was dann im aufrufenden VI Probleme machen kann - oder du musst wieder füür jeden unterstützten Datentyp ein subVI anlegen, welches genau diesen Datentyp ans aufrufende VI zurückgibt…
Würde man mit OOP nicht an den gleichen prinzipiellen Stellen steckenbleiben?
Oder bieten die dynamischen dispatches noch mehr Möglichkeiten in diesem Zusammenhang?
(14.04.2016 10:10 )HasteMalNeMark schrieb: Würde man mit OOP nicht an den gleichen prinzipiellen Stellen steckenbleiben?
Oder bieten die dynamischen dispatches noch mehr Möglichkeiten in diesem Zusammenhang?
Die Schwiegrigkeiten wären bei LVOOP andere, sogar schlimmer!
Du würdest nicht nur die Override-VI's für Deine unäre Operation für alle Datentypen implementieren müssen, sondern auch die zugehörigen Basis- und Kindklassen. Zusätzlich sind die Klassenattribute privat! Du kannst Sie also nicht einfach auf dem Frontpanel eingeben oder anzeigen. Du benötigst Attribut-Zugriffs-VI's für jeden Datentyp mit eindeutigem Namen. Diese müssen statische-VIs sein, weil dynamic-Dispach-VIs dieselbe Connector-Pane haben müssen.
Ausweg: XControl! Ein Dynamic-Dispatch-Attribut-Zugriffs-VI, das den Wert als String in der korrekten Formatierung zurückliefert und anzeigt. Alle Kindklassen müssten es überschreiben.
Noch Fragen?
Ich habe noch eine? Wieviel Zeit möchtest Du aufwenden, um alles anderen Rechenoperationen, z.B. Increment, OO-konform zu implementieren.
Was gefällt Dir an dem Primitve Division nicht? Kannst Du das bnitte erläutern? Oder handlet es um eine akademeische Übung?
Zum einen möchte ich mir nützliche Bibliotheksfunktionen schreiben, so dass ich dachte ich investiere jetzt ein bisschen Arbeit um mir dann oft andere Arbeit zu sparen.
Da ich schon ziemlich oft durch 2 (oder eine andere Konstante) dividieren musste, bekam ich den Gedanken ein SubVi mit entsprechendem platzsparendem Icon zu erstellen und dieses immer wieder zu verwenden.
Leider fallen einem die Hindernisse oft erst auf, wenn man was ausprobiert. So war es auch hier. Um die Situation sozusagen zu "retten" habe ich die Frage gestellt weil man selbst ja manchmal irgendwelche Tricks nicht kennt, die einem zur Lösung verhelfen. Abgesehen davon lernt man bei solchen Experimenten unabhängig vom Ergebnis meist recht viel, was die Mühe dann wieder lohnt.
Ich denke, ein tolerabler Komprimiss könnte so aussehen, dass man eine Variant annimmt und eine Dbl (oder ext Dbl) ausgibt. Dann hat man zwar unschöne Koercion Dots, aber immerhin gehts.
So wird ich das jetzt wohl lassen, wobei ich mir vielleicht mal bei der nächsten Gelegenheit die XControls reinziehen werde. Man muss ja auch nicht immer alles auf einmal lösen.
Oh mann, warum kompliziert, wenns auch einfach geht?
Manchmal hat man ne fixe Idee im Kopf und blockiert sich damit selbst.
Die Expression Node ist auf jeden Fall ne gute Idee und ist viel übersichtlicher
als der Kabelverhau mit den Arithmetik VIs.
Weiterer Vorteil: Die Wartbarkeit wird erhöht, wenn man mal die Formel ändern muss.
