Bitte um Kritik zu einer meiner C++ Library

[_ro_ro]

@Helmut-Jakoby sagte in Bitte um Kritik zu einer meiner C++ Library:

https://www.youtube.com/watch?v=-5wpm-gesOY

Ja. Das wird ein Thema wenn Sie mit der Digitalkamera nach Mexico reisen. Und dann zuhause feststellen, daß alle Fotos offensichtlich mitten in der Nacht gemacht wurden

MFG

[_ro_ro]

@DocShoe sagte in Bitte um Kritik zu einer meiner C++ Library:

Die kurze und höfliche Anwort: verbesserungswürdig.

Das ist geschmeichelt
Also der C-Style der da noch drinstekt ist grauenhaft. Da habe ich heute mal aufgeräumt. Allerdings habe ich noch nicht geprüft, inwieweit ich die (int) Cast Notation c++konform ersetzen kann. Und als einen weiteren Vorteil von OOP betrachte ich den Fakt daß man in jeder Private Methode Vollzugriff auf die Eigenschaften der Instanz hat, also auf Return-Values und unendliche Argumentelisten weitgehend verzichten kann.

MFG

[omggg]

@_ro_ro sagte in Bitte um Kritik zu einer meiner C++ Library:

@Helmut-Jakoby sagte in Bitte um Kritik zu einer meiner C++ Library:

https://www.youtube.com/watch?v=-5wpm-gesOY

Ja. Das wird ein Thema wenn Sie mit der Digitalkamera nach Mexico reisen. Und dann zuhause feststellen, daß alle Fotos offensichtlich mitten in der Nacht gemacht wurden

MFG

Sag mal, schaust du dir Videos überhaupt an, die dir freundlicherweise gegeben werden? Da geht es um Reinventing the wheel - und nicht um Digitalkameras, die nicht mal mit einem Netzwerk verbunden sind.

MfG

[_ro_ro]

@omggg

von Ihrer ausgesprochenen Höflichkeit mal abgesehen: Die Zeitzone (um die es in dem Video geht) spielt bei Datumsberechnungen und Kalkulationen zwischen Kalendern überhaupt gar keine Rolle. Das ist historisch begründet. Zeitzonen wurden viel später eingeführt als Kalender.

MFG

[wob]

Die tiefgründigere Message des Videos ist (völlig korrekt): alles mit Datum ist kompliziert, man verwendet am besten gut gepflegte Bibliotheken. Wir haben eigenen Code für diverse Datumsumrechnungen (ich muss oft mit unterschiedlichen Wochendefinitionen arbeiten, wer braucht schon ISO-Kalenderwochen, wenn man Wochen auch von Mittwoch bis Dienstag oder Sonnabend bis Freitag definieren kann...) - und dieser Codeteil hat bei und in der Firma nicht nur die meisten Tests, sondern auch wirklich komische Spezialfallbugs (trotz der Tests) gehabt. In welcher Kalenderwoche bedingen wir uns - allein das ist auch schon so eine Spezialfrage, die von den Regeln abhängt und davon, wie man Wochen definiert... (4. Januar in KW1? Erster Donnerstag ist Jahr in KW1? Hahaha, alles viel zu einfach!)

Alles ein ganz großer Mist ist das!

Und dann finde mal für die GUI (da nutzen wir vuejs) irgendwelche Datepicker, die mit so komischen Wochen umgehen können...

[_ro_ro]

@wob sagte in Bitte um Kritik zu einer meiner C++ Library:

Die tiefgründigere Message des Videos ist (völlig korrekt): alles mit Datum ist kompliziert, man verwendet am besten gut gepflegte Bibliotheken. Wir haben eigenen Code für diverse Datumsumrechnungen

Das beißt sich schon ein bischen: Gut gepflegte Bibliotheken <=> Eigener Code. Es sei denn, Du meinst damit gut gepflegte eigene Bibiotheken. Was ich völlig nachvollziehen kann

Alles ein ganz großer Mist ist das!

Nö. Man muß sich nur mal richtig damit befassen. Und: Am Einfachsten zu verstehen ist und bleibt der Maya-Kalender. Sämtliche Fragen der Korrelation zu Diesem mit Unstimmigkeiten von bis zu 1000 Jahren liegen nicht am Maya-Kalender sondern an der Unzulänglichkeit Europäischer Zeitrechnungen.

Viele Grüße!!

[omggg]

@_ro_ro sagte in Bitte um Kritik zu einer meiner C++ Library:

von Ihrer ausgesprochenen Höflichkeit mal abgesehen:

Ich war nicht unfreundlich...

Wollte lediglich schreiben, dass dein Vorhaben deine Kenntnisse bei Weitem übersteigt. Wie es die anderen ja auch schon getan haben... Falls du jetzt vor Wut tobst: Einfach 5 Minuten an die frische Luft.

[_ro_ro]

Eingaben prüfen:
Ausgehend davon daß Benutzereingaben in HTML-Formularen grundsätzlich immer Strings sind, wäre da zunächst das Format zu prüfen, bspw. TT.MM.JJJJ. Hierzu bemühe ich eine RegEx die auf Ziffern prüft womit ich letztendlich Tag, Monat und Jahr wiederum als Strings bekomme die ich an stoi übergebe.

Also irgendwie erscheint mit das unlogisch, daß eine RegEx auf Ziffern prüft

std::regex format("(\\d{1,2})\\.(\\d{1,2})\\.(-?\\d{1,4})");
std::regex_match(date, res, format);  // Strings in res

aber Strings liefert. Wie auch immer, erst nachdem die Tag, Monat und Jahr numerisch vorliegen habe, kann ich prüfen ob das Datum valide ist und erst dann damit rechnen.

Wie macht Ihr das? Was wäre Eure Herangehensweise?

MFG

[Finnegan]

@_ro_ro sagte in Bitte um Kritik zu einer meiner C++ Library:

Eingaben prüfen:
Ausgehend davon daß Benutzereingaben in HTML-Formularen grundsätzlich immer Strings sind, wäre da zunächst das Format zu prüfen, bspw. TT.MM.JJJJ. Hierzu bemühe ich eine RegEx [...] Wie auch immer, erst nachdem die Tag, Monat und Jahr numerisch vorliegen habe, kann ich prüfen ob das Datum valide ist und erst dann damit rechnen.

Ich bin kein Web-Spezialist, aber meine Herangehensweise wäre, die Zeit im Browser parsen zu lassen, bevorzugt mit einer Methode, welche die Locale des Users berücksichtigt. Ich bin da echt kein Spezialist, aber ich glaube, dass Date.parse in JavaScript sowas macht. Du weisst, die Locale, die Datumsformate, Währungen, Uhrzeiten und andere Dinge mit all den verrückten Eigenheiten berücksichtigt, die solche Angaben haben können. Von TT.MM.JJJJ über JJJJ-MM-TT bis zu den völlig durchgeknallten Yanks mit TT/MM/JJJJ. Das will man vielleicht nicht wirklich alles selbst in C++ implementieren.

Wenn man dann ein Date-Objekt hat, liefert soweit ich sehe Date.valueOf() die Anzahl der Millisekunden seit dem 1. Januar 1970. Das ist m.E. eine schöne, generische Zeitpunkt-Angabe mit der man dann weiterarbeiten kann ohne sich um all die speziellen Formatierungen kümmern zu müssen. Das spart dann auch noch Serverlast, wenn man das kompliziertere Datums-Parsing auf den Client verlegt und auf dem Server nur noch prüfen muss, ob man einen gültigen Integer vorliegen hat. Umgekehrt geht das dann auch für die Anzeige auf der Website z.B. mit Date.toLocaleDateString().

Das hat zwar den Nachteil, dass es JavaScript benötigt, aber den Vorteil, dass es am wenigsten überraschend für den User ist, da er die Daten genau so angezeigt bekommt und eingeben kann, wie er sein OS konfiguriert hat und es wahrscheinlich gewohnt ist. Das würde zumindest solche Verwirrungen vermeiden, wie ich sie öfter auf Websites habe wenn ich sowas wie 05/03/24 lese. Ist das der 3. Mai beknackten Ami-Format oder ist das z.B. australisch und es ist der 5. März gemeint?

[_ro_ro]

@Finnegan

Danke Dir. Nun, die Prüfung soll schon serverseitig erfolgen. Ich habe mich jetzt dazu entschlossen, anstatt wieder extern was zu bauen, meine Klasse um einen Konstruktor zu erweitern so daß bei der Objekterstellung direkt das Datum aus dem Eingebefeld übergeben wird: Scaliger sca1( cgi.param("date1") ); also als String

und alle Püfungen in der Klasse selbst erfolgen. Den Browser könnte man für eine Vorab-Prüfung heranziehen, aber <input type="date"> erfordert wieder eine zusätzliche Formatumwandlung und das ist unschön, es rechtfertigt den Aufwand nicht.

Viele Grüße!!