Maßeinheiten als Typen

[Rollo62]

Zitat:

Es gbt für jeden "Einheistfall" einen Basistypen. Bei uns für Länge, Flächen, Volumen, Gewicht, Winkel etc.
Der Basistyp muss halt Deinen gesamten Wertebereich der jeweiligen Einheit abfangen.
Umgewandelt wird nur zur Anzeige oder bei Lesen/Schreiben......

Vollkommen richtig, so mache ich das auch :thumb:

Anlehnend an die SI Einheiten, in der i.d.R. auch zusammengesetzte Formeln berechnet werden, heist das die Typen rechnen immer richtig.
Lediglich bei der Ein- und Ausgabe will der "Mensch" halt gerne mal was anderes sehen :stupid:

Rollo

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1415488)

Unter Verwendung der Units System.ConvUtils und System.StdConvs kann man da recht einfach was zaubern:

Das ist dann leider unter Berücksichtigung der Umwandlung nutzlos:

Delphi-Quellcode:

var
  A: TKiloGramm;
  B: TGramm;
begin
  A := 50;
  B := A; // compiliert ohne irgendwelche Konvertierungen, dun dun dunnn :(

[p80286]

@Ghostwalker
Vielleicht solltest Du ein wenig ausholen und uns sagen was der Hintergrund Deiner Frage ist.
Grundsätzlich würde ich mit einem Record arbeiten:

Delphi-Quellcode:

Type
  tEinheit=(mgr,gr,kg,ton);
  tMyrec=record
           Menge:integer;
           Einheit:tEinheit;
         end;

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1415519)

Das ist dann leider unter Berücksichtigung der Umwandlung nutzlos:

Delphi-Quellcode:

var
  A: TKiloGramm;
  B: TGramm;
begin
  A := 50;
  B := A; // compiliert ohne irgendwelche Konvertierungen, dun dun dunnn :(

Diese Verwendung war aber auch nicht in den vier Vorgaben des Posts aufgeführt.

Zitat:

1. Die einzelnen Typen sollen sicher und eindeutig sein.

Gemeint ist, das, wenn man das ganze als Parameter an eine Methode übergibt, keine andere Maßeinheit
übergeben werden kann

Beispiel:

Procedure TuWas(const a:gramm); Wenn versucht wird, hier Kilogram zu übergeben, soll der Compiler meckern.

2. Rechenoperationen sollen möglich sein. D.h. Addition, Subtraktion, Division und Multiplikation
3. Vergleichsoperation sollen auch möglich sein.

4. Eine Möglichkeit, von einer Maßeinheit in eine andere Maßeinheit zu konvertieren/umzurechnen

Punkt 1 ist gegeben, für Punkt 2 und 3 muss TWeight noch etwas erweitert werden und Punkt 4 liegt als Beispiel vor. Daß eine direkte Zuweisung einer TGramm-Variable an eine TKilogramm-Variable vom Compiler verboten sein soll, kann ich da nicht entdecken. Eine korrekte Zuweisung muss natürlich über TWeight erfolgen, aber das ist ja auch schon im Beispiel gezeigt.

[Ghostwalker]

Das mit der direkten Zuweisung von verschiedenen Maßeinheiten ist eher Kontraproduktiv. Den dann wärs ja wieder möglich, bei Verwendung als Methoden-Parameter, bei Gramm, Kilogramm zu übergeben.

Das läst sich aber umgehen, in dem man statt Implizierter Typumwandlung die Explizite Variante wählt.

Was mich allerdings irretiert ist, wo der Vorteil liegen soll, das ganze in einem Typ zu handhaben.

@p80286
siehe 1 Post und Verweis auf anderen Thread :)

Ursprünglich wollte ich für jede Maßeinheit (als Beispiel hab ich Gewichte genommen) einen eigenen eigenen
Record definieren mit entsprechenden Operatoren und Convertierungen. Im anderen Thread ging es darum, ob man
entsprechende Unittests generieren kann. Dabei kamm die Frage auf, ob das wirklich das beste Design ist (also
einzelne Typen für Maßeinheiten), da es doch recht aufwendig ist. Da das ganze mit der Unittest-Frage nur indirekt zu tun hab, hab ich das ganze mal abgekapselt.

[TiGü]

Zitat:

Zitat von Ghostwalker (Beitrag 1415562)

Ursprünglich wollte ich für jede Maßeinheit (als Beispiel hab ich Gewichte genommen) einen eigenen eigenen
Record definieren mit entsprechenden Operatoren und Convertierungen.

Das ist ja auch vollkommen okay.
Du musst nur verstehen das Kilogramm, Gramm, Mikrogramm, Nanogramm K E I N E verschiedenen Maßeinheiten sind.
Es ist immer ein und dieselbe Maßeinheit mit verschiedenen Vorsätzen.
Ich wiege gleichzeitig 100 kg = 100000 g = 100000000000000 ng.
Das kann man mit einem einzigen Typen abbilden.

[Jumpy]

Ich hab gestern zufällig einen Vortrag (Java, sorry) gehört über eine "JSR-354 Money and Currency API".
Grundprinzip war in etwa, das Geld jeweils aus einem Betrag und einer Währung besteht und alles jeweils Objekte sind, mit diversen Eigenschaften und Methoden. Dazu gibt es Umrechnungsobjekte von Währungen usw.

Was ich damit sagen will: Wenn man es schon kompliziert und ausführlich machen will, mit viel Overhead, dann aber auch alles richtig als Objekte abgebildet mit Typsicherheit usw. (auch wenn Delphi nicht Java ist, kann man sich da ja was abgucken).

[Rollo62]

Zitat:

Es ist immer ein und dieselbe Maßeinheit mit verschiedenen Vorsätzen.

Jein, das stimmt zwar in den meisten Fällen.
Also Kg, ng, gr, m, cm, dm sind nur verschiedene Faktoren, das ist leicht.

Aber es gibt auch Ausreisser, z.B. bei Temperatur (°C, °F, °K),
das muss man mit Offset und Faktor arbeiten.

Oder bei Winkeln und Längen in diversen Darstellungsformen, z.B. der worst case ist wohl in USA mit der grässlichen inch-feet Darstellung und Brüchen derselben.


Rollo

[Schokohase]

@Rollo62

Egal wie komplex die Umrechung ist, die Bedeutung bleibt aber immer dieselbe, egal in welcher Dimension ich diese Einheit darstelle/angebe.

Es wird nicht heißer oder kälter wenn ich die Temperatur(-Differenz) in Celsius, Kelvin oder Fahrenheit angebe.

Es wird nicht schwerer oder leichter wenn ich das Gewicht in Kilogramm, Tonnen oder Mikrogramm angebe.

Der TE hat es aber bislang nicht geschafft auch nur ansatzweise eine Begründung zu liefern, warum er diese Aufsplittung einer Einheit in unterschiedliche Dimensions-Typen als nötig erachtet. Es kommt nur ein "ja, wenn man das mal braucht".

[JasonDX]

Zitat:

Zitat von Rollo62 (Beitrag 1415586)

Zitat:

Es ist immer ein und dieselbe Maßeinheit mit verschiedenen Vorsätzen.

Jein, das stimmt zwar in den meisten Fällen.
Also Kg, ng, gr, m, cm, dm sind nur verschiedene Faktoren, das ist leicht.

Aber es gibt auch Ausreisser, z.B. bei Temperatur (°C, °F, °K),
das muss man mit Offset und Faktor arbeiten.

Oder bei Winkeln und Längen in diversen Darstellungsformen, z.B. der worst case ist wohl in USA mit der grässlichen inch-feet Darstellung und Brüchen derselben.

Es ist aber immer die selbe physikalische Größe. Deswegen glaube ich dass die weiter oben vorgeschlagene Möglichkeit, orientiert an System.TimeSpan.TTimeSpan, die sinnvollste Lösung ist: Sie dokumentiert um welche Physikalische Größes es sich handelt (Und garantiert dass nicht Sekunden statt Gramm übergeben werden), inklusive der exakten Maßeinheit (es wird vermieden dass ein Wert als "meter" angegeben, aber als "millimeter" interpretiert wird), und erlaubt flexible Konvertierungen (Bei Gewicht kann dies z.B. auch Pfund etc. beinhalten, bei Geschwindigkeit m/s, kmh und mph, und zwischen Kelvin, Celsius und Fahrenheit zu konvertieren ist auch kein Problem).
Einzig Operatoren würde ich außen vor lassen. Addition und Subtraktion sind vllt. noch machbar, aber bei Multiplikation&Division wirds schwierig: Bspw. muss das Multiplikationsergebnis aus Spannung und Stromfluss vom Divisionsergebnis aus Drehmoment durch Zeit subtrahierbar sein.

Guava macht das ganze übrigens ähnlich.