3. "named return values are no longer supported"

"named return values are no longer supported"

  • D

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

    0
  • J

    @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.

    0
  • ?

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

    0
  • W

    @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.

    0
    T
    ?
     2 Antworten
  • T
    Gesperrt

    @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. ∣a⃗∣=x2+y2+z2\left | \vec{a} \right | = \sqrt{x^2+y^2+z^2}

    0
    W
    D
     2 Antworten
  • ?

    @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.

    0
  • J

    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.

    0
  • W

    @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.

    0
    T
    ?
     2 Antworten
  • T
    Gesperrt

    @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?

    0 1 Antwort
  • Mod

    @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.

    0
    T
     1 Antwort
  • ?

    @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.

    0
    W
     1 Antwort
  • T
    Gesperrt

    @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.

    ?

    0 1 Antwort
  • D

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

    und Wurzelziehen braucht Zeit.

    0
    T
     1 Antwort
  • T
    Gesperrt

    @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.

    0
  • Mod

    @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.

    0
  • W

    @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 😉

    0
  • Mod

    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.

    0
    W
     1 Antwort
  • W

    @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).

    0
  • Mod

    Das machst'e aber doch irgendwie interaktiv in Mathematica, Matlab, Python oder sonstwo und programmierst nicht ein C++-Programm mit toll gemachten Klassen?!

    0
  • Y

    Hi(gh)!

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

    @Yadgar
    Ich würds zuerst mal mit n paar geschweiften Klammern versuchen.

    Oha... ich war davon ausgegangen, dass die Kurzschreibweise ohne geschweifte Klammern bei Blöcken aus nur einer einer Zeile auch bei Funktionen erlaubt sei... wieder was gelernt! Jetzt kompiliert er fehlerfrei!

    Bei meinen Rechercheversuchen zum Thema hatte ich ja anfangs das Gefühl "wieder so ein neumodischer Firlefanz, mit dem das Programmieren unnötig kompliziert gemacht wird" - aber dann stellte ich fest, dass dieses Feature ein ganz alter Hut von anno 1993 (meine Güte, damals hatte ich gerade erst von C gehört, C++ kannte ich bestenfalls vom Hörensagen...) ist.

    Danke für den Tipp, Belli... rechne schonmal damit, dass eine Straße im Afghatopia-2050-Modus des Khyberspace nach dir benannt wird (Jâde-ye Belli oder so)! Denn (unter anderem) genau darum geht es mir mit diesem Programm: es soll aus eingelesenen Höhenwerten, die einem in eine ASCII-Matrix umgewandelten GeoTIFF (ASTER-Datensatz) entnommen werden, Vertizen für ein der Erdkrümmung folgendes Geländerelief als Mesh2-Objekt in POV-Ray erzeugen, und zwar zusätzlich mit einem Glättungseffekt durch Normalen für jedes Dreieck... auf povray.binaries.images hatte ein Mensch namens "Melody" (früher alphaQuad) bereits ein POV-Ray-Skript für diese automatisierte Normalenberechnung vorgestellt, allerdings ist die Skriptsprache "POV-Ray" als reine Interpretersprache derart langsam, dass dieses Skript für die Berechnung eines Geländereliefs aus den ASTER-Datenkacheln (3601 x 3601 Messpunkte) rund 33 Tage brauchen würde. Das muss einfach schneller gehen, dachte ich mir, und so begann ich mich mal wieder in C++ reinzuknien...

    Kurz gesagt, ich will ein konkretes Programmierproblem lösen und nicht C++ mit allen Verästelungen studieren! Könnte ich natürlich auch mal wollen - aber dann gibt es auch 2030 noch kein POVghanistan...

    Bis bald im Khyberspace!

    Yadgar

    0
Anmelden zum Antworten