Datums berechnungen
-
@EinNutzer0 sagte in Datums berechnungen:
@manni66
@lucki1000 sagte in Datums berechnungen:
wie ich zb 7 Tage vom 1.11 abziehen kann
Ja, du kannst sogar die Frage nicht finden.
-
@manni66 Nö, es ist ein ganz eindeutiges Beispiel gewählt worden. Ich interpretiere 1.11. als 1.11.2020 und nicht als 1.11.1900.
-
@DocShoe sagte in Datums berechnungen:
@EinNutzer0
Die ist beimctime
Aufruf schon kaputt, weil du ein temporary zurückgibst. Und da das temporary weder an eine lokale Variable zugewiesen wird noch deren Lebensdauer durch Bindung an eine const-Referenz verlängert wird erzeugt derctime
Aufruf UB, weil das Temporary da schon wieder zerstört wurde.Kannst du das bitte genauer erklären? Lebt das Temporary nicht auf jeden Fall so lange, bis der äußere Aufruf von ctime abgeschlossen ist?
siehe https://en.cppreference.com/w/cpp/language/lifetime
All temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created, and if multiple temporary objects were created, they are destroyed in the order opposite to the order of creation. This is true even if that evaluation ends in throwing an exception.
-
@wob sagte in Datums berechnungen:
So viel? Die date.h ist ein Header, der von nichts abhängt. Da brauchst du gar nichts weiter zu machen. Einfach Header #includen und fertig.
Ja, man kann natürlich auch die lib reinkopieren. Aber das finde ich nicht die beste Art, eine Lib einzubinden. Man sieht nicht, welche Version der lib man verwendet und muss jedes mal die header austauschen, wenn man die version updaten will.
-
@EinNutzer0 sagte in Datums berechnungen:
Hier bitte, fluent:
MyDate addDays(int days) { // ... return MyDate(tt); }
Mit "fluent" hat das aber nichts zu tun, da du jedesmal ein neues Objekt erzeugst.
So wäre es richtiger:MyDate& addDays(int days) { my_time += days * 86400; return *this; }
PS: Und eine Konstante (e.g.
SecondsPerDay
) für das Literal wäre auch angebrachter.
-
-
@EinNutzer0 sagte in Datums berechnungen:
Wie lange wäre bei
std::cout << ctime(MyDate(1, 11).addDays(365).getTimePointer()) << "!\n";
eigentlich die Lebensdauer der Klasse MyDate?
Wie sieht das denn aus wenn Du den Funktionsaufruf ausschreibst statt dem Operator
<<
? Kannst Du Dir die Frage dann selbst beantworten?
-
@wob sagte in Datums berechnungen:
@DocShoe sagte in Datums berechnungen:
@EinNutzer0
Die ist beimctime
Aufruf schon kaputt, weil du ein temporary zurückgibst. Und da das temporary weder an eine lokale Variable zugewiesen wird noch deren Lebensdauer durch Bindung an eine const-Referenz verlängert wird erzeugt derctime
Aufruf UB, weil das Temporary da schon wieder zerstört wurde.Kannst du das bitte genauer erklären? Lebt das Temporary nicht auf jeden Fall so lange, bis der äußere Aufruf von ctime abgeschlossen ist?
siehe https://en.cppreference.com/w/cpp/language/lifetime
All temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created, and if multiple temporary objects were created, they are destroyed in the order opposite to the order of creation. This is true even if that evaluation ends in throwing an exception.
Huch, hast recht! Ich bin davon ausgegangen, dass das temporäre
MyDate
Objekt direkt nach demGetTimePointer()
Aufruf zerstört wird, weil es nicht mehr benötigt wird und nur der Zeiger weiterverwendet wird.
-
@EinNutzer0 sagte in Datums berechnungen:
@manni66 Nö, es ist ein ganz eindeutiges Beispiel gewählt worden. Ich interpretiere 1.11. als 1.11.2020 und nicht als 1.11.1900.
Dann hättest Du es einfacher machen können, und einfach den 25. Oktober 2020 zurückgeben können ....
-
@Th69 sagte in Datums berechnungen:
Mit "fluent" hat das aber nichts zu tun, da du jedesmal ein neues Objekt erzeugst.
Ja, aber so wie ich es hatte, wäre es fluent UND immutable. Manchmal ist auch immutable gewünscht.
-
@EinNutzer0 sagte in Datums berechnungen:
immutable
Du hast wieder mal keinen Plan mit welchen Wörtern du in der Gegend rumwirfst. Oder du weißt es und bist ein elendiglicher Troll. Derzeit meine favorisierte Theorie zu deiner Person.
-
@Th69 sagte in Datums berechnungen:
Mit "fluent" hat das aber nichts zu tun, da du jedesmal ein neues Objekt erzeugst.
So wäre es richtiger:Da bin ich auch anderer Meinung. Ich hätte das addDays() auch gerne const und sehe kein Problem damit, hier eine Kopie zurückzugeben. Ein Datum ist total billig zu kopieren.
Vielleicht habe ich auch zu viel mit pandas gearbeitet, aber ich vermeide inplace-Operationen sehr gerne. Da addDays vom Namen her misleading sein kann, wäre hier ggf.
operator+
besser. Aber dann braucht man wieder einen ordentlichen Typen für Tage... und so landen wir dann langsam bei einem Nachbau von chrono....
-
@wob sagte in Datums berechnungen:
und so landen wir dann langsam bei einem Nachbau von chrono....
DAS.
-
-
@Swordfish sagte in Datums berechnungen:
@EinNutzer0 sagte in Datums berechnungen:
immutable
Du hast wieder mal keinen Plan mit welchen Wörtern du in der Gegend rumwirfst. Oder du weißt es und bist ein elendiglicher Troll. Derzeit meine favorisierte Theorie zu deiner Person.
Eh, ich habe keine Lust, dir in Sachen fluent und immutable Nachhilfeunterricht zu geben. Die Begriffe lassen sich doch leicht nachlesen, wenn man sie noch nicht kennt. Insofern kannst du den Spott gern für dich behalten.
-
@EinNutzer0 sagte in Datums berechnungen:
Nachhilfeunterricht
Du gabst eine unsinnige Kopie zurück. Da stellt sich die Frage nichtmal. Und die Kopie ist mutable wie nur was.
<°)))><(
Da du ja so gerne nach Best Practices und Idiomen fragst: https://stackoverflow.com/a/4421719/3975177
-
@Swordfish sagte in Datums berechnungen:
Du gabst eine unsinnige Kopie zurück.
Bewusste Designentscheidung.
@Swordfish sagte in Datums berechnungen:
Und die Kopie ist mutable wie nur was.
Nö, wie willst du
time_t my_time;
denn ändern, ohne eine zusätzliche Klassen-Funktion, die nicht das tut, was sie soll?Jetzt beruhige dich einfach ein bisschen.
-
@EinNutzer0 sagte in Datums berechnungen:
Bewusste Designentscheidung.
Dein
Add...()
schaut aus wie einoperator+()
. Lies meinen Link.Nö, wie willst du time_t my_time; denn ändern, ohne eine zusätzliche Klassen-Funktion, die nicht das tut, was sie soll?
Das zurückgegebene Objekt an sich ist mutable. Ich sage ja daß du Worte verwendest die du nicht völlig verstehst oder nur trollen willst. qed.
Anyway, ich bin hier raus. Der nächste Thread kommt bestimmt.
-
@hustbaer sagte in Datums berechnungen:
Pandas?
Ist so eine (im Data-Science-Bereich) recht bekannte Python-Bibliothek. Diese hat unter anderem die Philosophie, dass fast alle Funktionen eine Kopie des gesamten Datensatzes zurückgeben, außer wenn man den Parameter
inplace=True
setzt. Als ich angefangen habe, habe ich vielinplace=True
genutzt, aber inzwischen verzichte ich darauf komplett. Das gibt viel weniger Probleme am Ende und viel weniger Überraschungen.
-
@wob Danke für die Erklärung
Ja, immutable ist schon nett. Ausser wenn es einem aufgezwungen wird und man überall wo man mutable State braucht greislichst drum rum arbeiten muss. Deswegen programmier ich auch immer noch lieber C++ als irgendwas funktionales.
Wobei ich zugeben muss dass ich den funktionalen Sprachen auch nie wirklich eine Chance gegeben habe. Bloss wenn ich mir ansehe was die z.T. für einen Tanz aufführen müssen für die einfachsten Dinge...