"named return values are no longer supported"

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

[SeppJ]

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

[Yadgar]

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

[SeppJ]

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

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!

Der subtile Unterschied ist, dass auf die Definition einer Funktion ein "(Try-)Block" folgen muss, wohingegen auf so etwas wie if, for, etc. ein "Statement" folgen muss. Nun ist ein Block immer auch ein Statement, aber ein Statement ist kein Block.

[Yadgar]

Hi(gh)!

PS: @Yadgar : Wieso nutzt du kurz vor dem Jahr 2020 einen GCC 4.9.2?

Da nach meinen bisherigen Erfahrungen auf meinem Rechner weder Debian 9 ("stretch", oldstable) noch gar 10 ("buster", stable) fehlerfrei laufen, sehe ich mich gezwungen, an Debian 8 ("jessie", oldoldstable) festzuhalten... ich könnte ja mal einen dist-upgrade wagen, vielleicht bekäme ich damit eine aktuellere gcc-Version.. aber andererseits - warum sollte ich? Als Hobbyprogrammierer muss ich nicht die gesamte zeitgenössische Computerwelt mit allen Eventualitäten im Blick haben... ich programmiere weder in Umgebungen, wo hohe Vermögenswerte, noch wo Menschenleben auf dem Spiel stehen, dazu muss ich nicht die neuesten Sicherheits-Features verwenden.

Bis bald im Khyberspace!

Yadgar

[SeppJ]

Es geht nicht um Sicherheit, sondern um Spaß beim Programmieren. Wenn ich GCC 4.9 einsetzen würde, würde ich mich pausenlos ärgern, dass ich all die neuen Features aus neuem C++ nicht benutzen könnte.

Die Fehlermeldungen selbst sind auch sehr viel brauchbarer geworden. In diesem speziellen Fall bringt zwar auch der neueste GCC die gleiche verwirrende Meldung, aber so allgemein ist der GCC sehr viel weniger kryptisch als vor 5 Jahren.