"named return values are no longer supported"

wob

Hui, wieder was gelernt! Was es nicht alles gibt bzw. gab!

Ich habe noch eine andere Bemerkung:
Ehrlich gesagt sind mir Namen wie getx, gety und getz zu undurchsichtig. Die ersten 3 Buchstaben sind irrelevant und die Information kommt dann ganz am Ende. Wenn es wenigstens getX, getY, getZ (oder für die Freunde des Underscores auch get_x, get_y, get_z) wäre - aber selbst da. Brauche ich bei einem 3d-Vector wirklich das "get"? Ich fände insbesondere hier einfach x(), y(), z() besser, da man schneller sieht, worum es eigentlich geht.

Man könnte auch noch überlegen, ob man das Ding XYZVector oder CartesianVector3d nennt, um klar zu machen, dass intern kartesische Koordinaten verwendet werden und es sich um einen 3d-Vector handelt.

Und vsubtract könnte man auch gut als operator- implementieren. Und für Skalarprodukt bietet sich operator* an. Einzig cross muss wohl eine Funktion sein. Für print bietet sich operator<< an.

titan99_

@wob Finde ich auch. Ich denke auch zudem noch, dass lenght und setLenght fehlt.

DirkB

@wob @titan99_ ich habe das als minimales, den Fehler produzierendes Beispiel aufgefasst.

Jockelx

@wob sagte in "named return values are no longer supported":

Brauche ich bei einem 3d-Vector wirklich das "get"? I

Nein, so für sich betrachtet sicherlich nicht. Aber dieses unschöne "get" hat auch Vorteile, wenn man sich darauf verlassen kann, dass alle öffentlichen Daten mit getXYZ zur Verfügung gestellt werden, nämlich dass man durch die IDE sofort alles zur Auswahl hat, sobald du "obj.get" eingetippt hast.
Und Inkonsistenz ist halt auch blöd (hier weglassen, bei komplizierteren Sachen dann doch wieder). Also ich finde das "get" nicht schlecht.

Getter/Setter sind hier nun wirklich überflüssig wie ein Kropf.

wob

@titan99_ sagte in "named return values are no longer supported":

@wob Finde ich auch. Ich denke auch zudem noch, dass lenght und setLenght fehlt.

Sorry, was sollen denn length zurückgeben bzw. was soll setLength machen? Habe so eine Funktion noch nie in Zusammenhang mit einem Vector gesehen.

@manni66

Getter/Setter sind hier nun wirklich überflüssig wie ein Kropf.

Denke ich nicht. Stell dir mal vor, du möchtest diesen Vector durch einen 3d-Kugelkoordinaten-Vector ersetzen. Dann hast du auf einmal andere Member und x,y,z müssen über Funktionen berechnet werden. Damit du unabhängig von der internen Koordinatendarstellung bist, würde ich es wohl als Funktion machen.

titan99_

@wob sagte in "named return values are no longer supported":

Sorry, was sollen denn length zurückgeben bzw. was soll setLength machen? Habe so eine Funktion noch nie in Zusammenhang mit einem Vector gesehen.

Fertige Klasse für Vektor. Soweit ich es in Erinnerung habe, bedeutet es in der glm lib etwas anderes. Gemeint ist damit aber die Länge eines Vektors, z.B. $\left | \vec{a} \right | = \sqrt{x^2+y^2+z^2}$

@wob sagte in "named return values are no longer supported":

Denke ich nicht. Stell dir mal vor, du möchtest diesen Vector durch einen 3d-Kugelkoordinaten-Vector ersetzen.

Dann verstecke ich die Konvertierung nicht hinter Getter/Setter. Stell dir vor, du willst anschliessend den Kugelkoordinatenvector durch einen Zylinderkoordinatenvector ersetzen.

Jockelx

Da wo ich zur Zeit arbeite, sind API-changes im Grunde nicht möglich (3x in den letzten über 20 Jahren). Aber das da Getter/Setter irgendwie wichtig gewesen wären, kann ich -soweit ich das beurteilen kann- nicht sagen. Wird trotzdem verpflichtend gemacht und stört mich auch nicht.

wob

@titan99_ sagte in "named return values are no longer supported":

Gemeint ist damit aber die Länge eines Vektors

Achso. Das wäre aber ein eher unüblicher Name, davon würde ich sehr abraten. Da würde ich eher "magnitude" oder auch "magnitude2" vorschlagen, da man oft auf das Wurzelziehen verzichten kann. Oder man nennt das Ding L2Norm oder wie auch immer.
Und das setLength finde ich noch merkwürdiger. (0,0,0).setLength(1) ist ja wohl ein bisschen undefiniert - sowas würde ich nicht einbauen. Dann eher ein "scale" zum Strecken. Wobei das einfach ein operator* ist.

@manni66

Dann verstecke ich die Konvertierung nicht hinter Getter/Setter. Stell dir vor, du willst anschliessend den Kugelkoordinatenvector durch einen Zylinderkoordinatenvector ersetzen.

Sorry, ich verstehe dein Argument nicht. Das ist doch gar kein Problem. In allen 3 Fällen heißt es dann x(), wenn ich an die x-Koordinate will. Und außerdem kann ich in Fällen, in denen nicht sofort klar ist, welche interne Darstellung effizienter ist, einfach mal schnell ausprobieren, indem ich einen anderen Konstruktor nehme. Ansonsten muss ich nichts ändern. Ohne Funktion muss ich dann x durch x() oder theta durch theta() ersetzen.

titan99_

@wob sagte in "named return values are no longer supported":

Dann eher ein "scale" zum Strecken. Wobei das einfach ein operator* ist.

scale kann ja schon vorkommen, dafür muss aber zuerst der Vektor normiert werden, wenn ich mich nicht täusche.

@wob sagte in "named return values are no longer supported":

da man oft auf das Wurzelziehen verzichten kann.

Wie kann man das?

SeppJ

@titan99_ sagte in "named return values are no longer supported":

@wob sagte in "named return values are no longer supported":

Dann eher ein "scale" zum Strecken. Wobei das einfach ein operator* ist.

scale kann ja schon vorkommen, dafür muss aber zuerst der Vektor normiert werden, wenn ich mich nicht täusche.

Das kommt drauf an, was man meint. Normalerweise würde man mit scale nicht das meinen, was du meinst.

@wob sagte in "named return values are no longer supported":

da man oft auf das Wurzelziehen verzichten kann.

Wie kann man das?

Was hast du denn vor mit der Länge? Zu 99% willst du sie doch mit anderen Längen vergleichen. Dann sparst du dir lieber das teure Wurzelziehen.

@wob sagte in "named return values are no longer supported":

Ohne Funktion muss ich dann x durch x() oder theta durch theta() ersetzen.

Nein. Ich verwende verschieden Vectorklassen.

Konsequnterweise müsstest du ja schon in der ersten Implementierung alle möglichen Varianten anbieten.

titan99_

@SeppJ sagte in "named return values are no longer supported":

Was hast du denn vor mit der Länge?

Vektor normieren?

@SeppJ sagte in "named return values are no longer supported":

Zu 99% willst du sie doch mit anderen Längen vergleichen. Dann sparst du dir lieber das teure Wurzelziehen.

?

DirkB

Wenn sqrt(x) <= sqrt(y) (für nicht negative x und y) gilt,
gilt auch x <= y

und Wurzelziehen braucht Zeit.

titan99_

@DirkB sagte in "named return values are no longer supported":

und Wurzelziehen braucht Zeit.

Also Quadratwurzeln haben soweit ich weiss eine hohe Konvergenzgeschwindigkeit mit dem Newtonverfahren. Also im Kopf habe ich irgendwie ca. 8 Iterationen für ein double, bin mir jetzt aber gar nicht sicher.

SeppJ

@titan99_ sagte in "named return values are no longer supported":

@SeppJ sagte in "named return values are no longer supported":

Was hast du denn vor mit der Länge?

Vektor normieren?

Das ist ein Selbstzweck. Wozu willst du den Vektor normieren? Doch zu 99%, um ihn wieder mit anderen Vektoren zu vergleichen, z.B. um einen Winkel auszurechnen und mit anderen Winkeln zu vergleichen. Auch das geht wieder ohne Trigonometrie oder Wurzeln, wenn man sich im klaren ist, was man am Ende wirklich will.

@titan99_ sagte in "named return values are no longer supported":

@DirkB sagte in "named return values are no longer supported":

und Wurzelziehen braucht Zeit.

Also Quadratwurzeln haben soweit ich weiss eine hohe Konvergenzgeschwindigkeit mit dem Newtonverfahren. Also im Kopf habe ich irgendwie ca. 8 Iterationen für ein double, bin mir jetzt aber gar nicht sicher.

Und? Bloß weil du die Wurzel in 20 µs berechnen kannst, ist das doch immer noch langsam, wenn die Alternative in 50x schneller fertig ist.

wob

@manni66 sagte in "named return values are no longer supported":

Konsequnterweise müsstest du ja schon in der ersten Implementierung alle möglichen Varianten anbieten.

Ja. Gut, ich bin diese Klassen hier gewohnt: TVector3 und LorentzVector - die haben sogar die Member-Funktionen x() und X(), damit man sich selbst aussuchen kann, ob man Groß- oder Kleinschreibung besser findet

SeppJ

Ich würde doch sehr empfehlen, bei einem Kugelkoordinatenvektor nicht die gleiche Schnittstelle wie bei einem kartesischen Vektor anzubieten. Das wäre ganz schön fies für den Nutzer wenn hinter einem scheinbar harmlosen Getter eine komplexe Rechnung versteckt ist. Die Anwendungsgebiete der unterschiedlichen Systeme sind so verschieden, dass man die jeweils andere Schnittstelle nie brauchen sollte, außer in Ausnahmefällen, in denen man die Umrechnung dann über den expliziten Aufruf von Umrechnungsfunktionen macht.

C++ Vergleich: Das wäre so, als würde man einer std::list einen operator[] geben, bloß weil std::vector einen hat.

wob

@SeppJ Ok, vom Softwareentwicklungsstandpunkt her verstehe ich das.

Wenn ich aber schnell ne Analyse machen will, möchte ich eine einheitliche Schnittstelle. Lieber erstmal ineffizient rechnen, dann feststellen, dass ich doch was anderes will usw. Ich finde diese Riesen-Schnittstellen durchaus sehr praktisch, denn häufig ist mir einfach s...egal, wie der Vector intern gespeichert ist - ich möchte einfach z.B. den x-Wert berechnen. Ich möchte nicht erst nachdenken, ob das Ding in dem "richtigen" Koordinatensystem vorliegt. Zumal ich doch mit toCartesian(spherical).x nichts gewinne, außer dass der Code komplizierter wird (gut, ich sehe, dass hier was berechnet wird - dafür berechnet toCartesian mir gleich y und z mit, die ich ggf. gar nicht benötige).

(dazu kommt noch, dass ich in ROOT auch in einem Browser auf die Funktionen Doppelklicken kann und sofort ein Histogramm sehe, bei dem die Funktion einfach auf alle Daten angewendet wurde - Memberfunktionen sind also wesentlich praktischer für mich).