möchte man eine Klasse schreiben, die für das Speichern einer physikalischen Größe mit Maßeinheit verantwortlich ist, so stellt man sich die Frage, in welcher Maßeinheit diese gespeichert werden soll. Ein Dilemma beim genaueren Hinschauen. Ich möchte eine Klasse für Winkel schreiben, so dass man Grad, Bogenmaß und Zeitmaß speichern kann. Ideen / Ansätze:

1. Für jede Maßeinheit ein eigenes Klassentemplate.
Nachteile:
- Viel Boilerplatecode, damit man zwischen den Einheiten hin- und herkonvertieren kann
- Redundant da man in jeder Konvertierungsfunktion Faktoren einfügt.

2. Ein Klassentemplate für Bogenmaß, die anderen Einheiten haben keine Klasse, können aber in / von Bogenmaß konvertiert werden.
Nachteile:
- Sind viele Werte als z.B. Grad vorhanden und werden diese auch weiterhin als Grad benötigt, so ist diese Klasse nicht brauchbar wegen den vielen Konvertierungen - durch die sowohl Geschwindigkeit als unter Umständen auch die Genauigkeit leidet -, womit die damit verbundene Funktionalität entfällt.

3. Ein Klassentemplate für alle Winkeleinheiten, intern wird mit einer Enumeration gespeichert, welche Einheit aktuell in Benutzung ist.
Nachteile:
- Speicheroverhead für eine jede Instanz, auch wenn man diese zusätzliche Funktionalität nicht braucht.

Gibt es bessere Lösungen?

MfG

Gibt es bessere Lösungen?

Nur mit einer der Einheiten rechnen. Am besten Bogenmass only.

Die Sache mit den Winkeln ist äusserst doof.
z.B. schonmal deswegen weil die Periode von sin / cos 2 Pi ist, aber 2 Pi blöderweise nicht als float / double darstellbar ist.
Wenn man exakte Ergebnisse braucht nervt das.

Bei 3600000090 Grad ist klar dass der Sinus 1 ist. Bei Modulo 360 kommt exakt 90,0 raus, und dass der Sinus davon exakt 1,0 ist wissen wir.
Bei 20000000,5*Pi Radianten modulo 2 Pi kommt dagegen bloss was raus was relativ nahe an 0,5 Pi liegt -- allerdings nicht so nahe an 0,5 Pi wie es mit der verwendeten Gleitkommadarstellung sein könnte. => sin() davon wird nicht exakt 1,0 sein. => Doof.

20000000,5*Pi Radianten

Speichern wir Radians nicht direkt als Vielfaches von Pi? Warum also den Faktor noch drinbehalten? Man kann das *Pi doch implizit machen.

Ich würde zu 1 tendieren, und dann einfach kontextabhängig das sinnvollste benutzen. Wenn man sehr viel mit Grad rechnet, so sollte man auch für diesen Fall Grad abspeichern.

Und nicht UDLs vergessen!

Wenn man sehr viel mit Grad rechnet, so sollte man auch für diesen Fall Grad abspeichern.

Hä?

ps: Seltsam, daß keiner verlangte, man müsse es unbedingt ähnlich wie im C++-Standard machen.
http://en.cppreference.com/w/cpp/chrono/duration

//an dem tag haben sie wieder was geraucht

Arcoth schrieb:

Wenn man sehr viel mit Grad rechnet, so sollte man auch für diesen Fall Grad abspeichern.

Hä?

... wenn du sehr oft - nach Berechnungen - Funktionen aufrufst, die einen double mit der Gradzahl erwarten (könnten aus irgendeiner API stammen), wirst du natürlich deine Berechnungen, falls sinnvoll, vorzugsweise in Grad durchführen und speichern damit du nicht bei jedem Aufruf ins Bogenmaß konvertieren musst.

... wenn du sehr oft - nach Berechnungen - Funktionen aufrufst, die einen double mit der Gradzahl erwarten (könnten aus irgendeiner API stammen),

Ahh.
Ok, kann nicht vorkommen.

Ahh.
Ok, kann nicht vorkommen.

Wie man merkt bin ich ein Greenhorn, danke für die Aufklärung.

Seltsam, daß keiner verlangte, man müsse es unbedingt ähnlich wie im C++-Standard machen.

Willste für jede Maßeinheit eine Spezialisierung haben? Und Konstanten (zur Konvertierung etc.) als Template-Parameter nehmen?

allerdings nicht so nahe an 0,5 Pi wie es mit der verwendeten Gleitkommadarstellung sein könnte. => sin() davon wird nicht exakt 1,0 sein. => Doof.

Ähm.
Schon, wenn man eine Zahl durch 3 teilt und danach das Dreifache nimmt, hat man einen Rechenfehler. Mit der Gradrechnung kommste wohl auf ein geschlossenes Dreieck, Viereck, Fünfeck, Sechseck, aber das Siebeneck ist schon offen. Und auch nur FALLS jemand die glatten Sonderfälle in die sin()-Funktion einprogrammiert. Na, besser in double auch, damit sqrt(2)*sqrt(.5)==1. sin(30d) solls nicht besser haben als sin(60d), oder?

Und nicht UDLs vergessen!

Ja, die sind für die Lesbarkeit ganz wichtig.
d für grad, ist klar. g für neugrad und r für normal. WIe im Taschenrechner üblich.
außerdem universell m für milli und k für kilo, aus der Zeit-Lib noch s für Sekunde und m für minute.
1m ist eine Minute.
1mm ist eine Milliminute (ungefähr ein clocktick in DOS). Ach nee, das geht ja so nicht.
Man muss UDLs aneinanderhängen können. Das ist der einzige Ausweg, um nicht in eine kombinatoreische Explosion zu geraten.
1m m ist eine Milliminute.
1k g sind 1000 Grad.
Dann wünschen die Benutzer aber auch, mehr Leerzeichen verwenden zu dürfen. Gibt ja so kranke Leute, die keine zwei Zeilen Code hinkriegen ohne eine Leerzeile dazwischen und keinen Ausdruck ohne Leerzeichen um alle Operatoren).
1 m m ist eine Milliminute.
1 k g sind 1000 Grad.
Und Variablen!
x m m steht einfach für Minute(Milli(x)).
Und weils zu kacke aussieht, muss man auch die Leerzeichen weglassen können. Am besten mit Vorrangregelung für übliche Zusammensetzungen.
1m m oder 1 m m oder (1m)m ist eine Milliminute, aber 1mm oder 1 mm ist ein Millimeter. Siehe auch whitespace overloading.

Übung: Wie sieht die Einheit des Benzinverbrauchs von Autos aus, wenn man nur Einheitenvorsätze wie milli und SI-Basis-Einheiten erlaubt und vielleicht noch ein i für "hoch minus 1" und man meistens Zahlenwerte zwischen 1 und 1000 haben mag?

g für neugrad

Wird das denn wirklich irgendwo eingesetzt?

volkard schrieb:

g für neugrad

Wird das denn wirklich irgendwo eingesetzt?

Wäre mir neu, daß die Vermesser was anderes nehmen.
edit: http://www.hs-bochum.de/fb5/baeumker/download/vermessungskundes1-36einseitig.pdf