Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[Meister der Operatoren]

Xin schrieb:

Wozu asInt()? schrieb:

Kraft k;
int x = k / Newton(1);

Wozu eine Operatoren durchführen?

Kraft k;
int x = k;

Eindeutigkeit. Klarheit. Eleganz.

int y = k / kiloNewton(1);
long long z = k / picoNewton(1);

[CStoll]

Xin schrieb:

CStoll schrieb:

OK, dann ist aus deiner Sicht also die Arbeit mit void* auch typsicher? Du sagst zwar einiges aus über typsicher verbotene Operationen (ungeprüfte Zuweisung von unpassenden Typen), aber nichts über typsicher erlaubte Operationen.

Warum sollte void * nicht typsicher sein. Du hast eine Zeiger auf Informationen, ohne deren Typ zu kennen. Also weißt Du, was sie nicht sind. Du kannst sie keinem sicheren Typ zuweisen, Du kannst nichts damit anfangen, solange der Entwickler nicht vorgibt, was das ist.

Interessante Sichtweise

Xin schrieb:

CStoll schrieb:

Dein Typsystem hat zwar Geschwindigkeiten und Beschleunigungen, aber keine Darstellung für Quadratgeschwindigkeiten, also ergibt der Teilausdruck 'v*v' einen int und damit hast du plötzlich einen nackten int-Wert und mußt selber dafür sorgen, daß der in eine Länge reingequetscht werden kann. So etwas ist in meinen Augen nicht typsicher.

Leute, ihr seid echt witzlos. Shade programmiert die Klassen um, um zu behaupten, dass sie nicht funktionieren, Du legst fest, dass ich keine Quadrateinheiten haben darf.
Kannst Du mir mal erklären, wieso ich überhaupt noch hier schreibe?
Ich soll doch hier nicht verteidigen, was ich vorgegeben habe, sondern immer wildere Mutationen und Anforderungen, die ihr euch ausdenkt und von mir nie angegeben wurden.

OK, vielleicht hast du tatsächlich an Quadrat-Einheiten gedacht, aber hast du auch alle Einheiten und -Kombinationen bis zur (z.B.) 200. Potenz vorrätig?

Xin schrieb:

Vielleicht kapierst Du das nicht: Das Template, was Du aus dem Internet kopiert hast und meine Klassen stehen nicht im Widerspruch zueinander.

OK, dann zum wiederholten Mal: Dieses Template erschlägt das SI-Einheitensystem mit einem Schlag und ich kann mit allen denkbaren Kombinationen rechnen, ohne irgendwelche int's zu bekommen, deren korrekte Einheit ich erraten/wissen muß. Welchen Mehrwert habe ich, wenn ich das noch um eine (hypothetische) Vererbung von int bzw. eine (mögliche und praktisch gleichwertige) implizite Umwandlung nach int& dort draufpacke?

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Casts sollten vermieden werden. Aber das gilt nicht grundsätzlich, sonst gäb es keine Casts.
Der Entwickler gibt vor, was das Programm zu leisten hat und was richtig oder falsch ist, nicht der Compilerhersteller.

Und ein kluger Entwickler verwendet Typen, die er ohne Casts korrekt zuweisen - und nur mit Klimmzügen (und bewußt) falsch/unpassend verwenden kann. Daß man eine Flächenangabe nicht antandslos in ein Gewicht pressen kann, ist angenehm, daß man das Ergebnis von 'Geschwindigkeit*Geschwindigkeit/(2*Beschleunigung' nicht ohne Hilfestellung in eine Länge stecken kann, ist unschön.

Jow, pack den Zeigefinger wieder ein und stell die Füße mal auf den Boden der Tatsachen. Gelegentlich brauchst Du casts, um festzulegen, wie etwas erledigt wird.
"Wenn was nicht passt, wird's passend gemacht."
Du hast in der Realität nunmal leider viel zu selten die Chance, etwas formal perfekt zu machen, manchmal musst Du auch draufhauen, weil Du sonst zu spät lieferst, Ärger mit dem Kunden bekommst und Folgeaufträge flöten gehen, woraufhin Dein Chef Dir das viereckige Loch in der Wand näherbringt.
Das mag unschön sein, aber das Leben ist nicht immer fair und ein kluger Entwickler sollte damit umgehen können.
Der Vorschlaghammer macht Kunden und Chefs froh und sorgt für den Eingang Deinen Gehaltsschecks und das ist der Realität manchmal wichtiger als der perfekte Quelltext.

Ja, wenn ich es eilig habe, lasse ich die Einheiten unter den Tisch fallen und rechne nur mit blanken int's. Aber wenn ich anfange, über Typsicherheit und Einheiten nachzudenken, baue ich ein System, das ohne unnötige Klimmzüge und Vorschlaghammer funktioniert.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Das Dumme ist halt nur, dass die Informatik sich auch mit Einheiten beschäftigt, die sich durch SI Einheiten nur ganz schlecht ausdrücken lassen, mit denen man aber auch rechnen können muss: Butterbrot, Teppichboden, Krieger.

Ein "Butterbrot" ist keine Einheit, sondern eine Größe - die dazugehörige Einheit wäre "Anzahl".

*lach* Okay... Und wenn ich an die Steckdose packe durchströhmt mich 230 Stück Volts, richtig. Volt ist eine physikalische Größe und Größen werden in "Anzahl" gerechnet.

Du hattest Physik Leistungskurs und kennst nicht den Unterschied zwischen "Größe" und "Einheit"? Die Größe "Butterbrote" wird in "Stück" gemessen, die Größe "Spannung" in "Volt".

Xin schrieb:

CStoll schrieb:

Und wieviele Leute kennst du, diemit solchen "Einheiten" wie Butterbroten physikalische Rechnungen ausführen? (btw, was ergibt "1 Schraubenschlüssel + 1 Werkzeugkasten"? 2 Objekte? 27 Werkzeuge? 10,05 kg?)

Gute Frage... wenn ich sie als ints verrechne, wieviel gibt denn dann 1+1?
Ist das für Dich wirklich so schwer, die Einheiten von Objekten wegzunehmen und nur noch die Zahl zu sehen?

Wenn du die Einheiten wegnimmst, kommt eine sehr sonderbare Physik heraus - 1kg+200g sind 201 (irgendwas) - viel Spaß mit der Berechnung.
Zu meinem Beispiel von oben - ich kann Schraubenschlüssel und Werkzeugkästen (je nach Anwendung) unterschiedlich betrachten und eine dafür passende Semantik der "Addition" aufstellen:

• beides Einzelobjekte - die Summe zählt die Objekte (2)
• sie sind ein Werkzeug bzw. ein Container von Werkzeugen - die Summe ergibt die Gesamtzahl an Werkzeugen (z.B. 27)
• sie sind unterschiedlich schwere Objekte - die Summe ergibt das Gesamtgewicht (z.B. 10,05 kg)

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

(btw, wer unbedingt Längen und Gewichte addieren will, kann die Einheiten auch rauskürzen)

Und? Passiert dann irgendwas anderes, wenn Du die Information manuell vernichtest?

Wenn ich die Information manuell vernichte, passiert das mit voller Absicht. Wenn der Compiler die Informationen implizit herausschmeißt, weil er nichts damit anfangen kann, habe ich ein Problem, sie zurückzugewinnen.

Richtig. Du als Entwickler musst selbst denken, weil Du etwas durchführen möchtest, für das Dir der Compiler keine Garantien verspricht. Wenn Denken ein Problem darstellt, dann ist es wohl etwas spät die Berufswahl zu überdenken.

Ich habe dich vor einer ganzen Weile schon gefragt, ob du dein System jemals jemand anderem in die Hand drücken willst
Ja, ein Entwickler muß etwas mitdenken - aber wenn ich als Bibliotheksentwickler die Möglichkeit habe, meinen Kunden die Arbeit zu erleichtern, indem ich meinen Klassen die erforderlichen Sicherheiten einbaue, werde ich das auch tun - da können sich die Physiker dann darauf konzentrieren, wie man die Kapazität eines Kondensators berechnet, anstatt zu überlegen, was für eine Einheit sie da eigentlich benötigen.

Xin schrieb:

Und obwohl ich mit meinen merkwürdigen "Meinungen" meinen SWT-Prof in mancher Diskussion halb in den Wahnsinn getrieben habe und seiner Lehrmeinung oft genug im Wege stand, gab er mir ein 'sehr gut' und zusätzlich einen WPF mit 'sehr gut' und schrieb in einem Empfehlungsschreiben "Im Fachbereich und in Lehrveranstaltungen ist Herr Atrops ein kritischer Geist, der mit großer Treffsicherheit Schwachpunkte identifiziert und thematisiert."
Auch als Professor kommt man an mir nicht ohne eine gute Argumentation vorbei und er war einer der wenigen Profs, die sich damit auseinandersetzen und vor allem auch merkte, dass ich die Lücken in der Argumentation sinnvoll aufbohrte.

Na dann wünsche ich dir, daß du irgendwann den Sachverstand entwickelst, den du an diesem Professor so bewunderst.

Xin schrieb:

Die Umwandlung zu ints ist eine Lücke, aber es ist nicht die Lücke, die die Typsicherheit zerstört, es ist die Lücke, die dem Entwickler zum Recht verhilft, alles zu tun, was er für richtig empfindet.
Den Vorschlaghammer zu vermeiden ist gut, ihn abzuschaffen wäre Wahnsinn.
Das kannst Du auch mit asInt() erreichen, aber es hat keinen Vorteil die Kompilierung zu verweigern, damit Du erst asInt dazuschreiben musst, um dann auch ebenfalls keine Typinformation zu erhalten.

Und da hat es einen Vorteil, die Compilierung zu verweigern, weil du eine Typdefinition - bzw. eine bestimmte Überladung von operator* nicht bedacht hast?

Xin schrieb:

CStoll schrieb:

Ich habe absolut kein Problem damit, daß du deine Meinung vertrittst. Aber ich hätte dir eigentlich schon so viel Intelligenz zugetraut, daß du Gegenargumente nicht mit einem "ist für mich unerheblich" vom Tisch fegst.

Nanana, wir wollen doch nicht beleidigend werden...
Laut Forumsmeinungen ist das ein Zeichen, dass einem die Argumente ausgehen und außerdem bin laut Forumsmeinung ich der einzige, der hier zu beleidigen hat. Also artig bleiben.

OK, ich formuliere die Aussage um: Du versuchst uns zu erklären, warum es besser wäre, physikalische Einheiten von int ableiten zu können. Aber wenn du dabei alle ankommenden Argumente als "unwichtig" einstufst, bringt die ganze Diskussion nichts - du magst zwar in der Lage sein, "Schwachpunkte zu thematisieren", aber du bist offenbar nicht in der Lage, diese Fähigkeit auf deinen eigenen Entwurf anzuwenden.

Xin schrieb:

CStoll schrieb:

Und Typsicherheit bedeutet nicht nur "wenn ich den Typ nicht kenne, liefere ich keinen - und übergebe die Verantwortung an andere", sondern auch "wenn ich den Typ kenne, nutze ich diese Information".

Und? Also wenn Du schon von Intelligenz anfängst, so lass Dich fragen, was ich hier nicht vom Tisch fegen könnte, immerhin sagen die Klassen nicht nur "wenn ich den Typ nicht kenne, liefere ich keinen - und übergebe die Verantwortung an andere" aus, sondern auch "wenn ich den Typ kenne, nutze ich diese Information".

Was Du hier vorbringst, ist also kein Argument und damit für die Diskussion unerheblich.

Solange das Produkt zweier Größen von deinem System steht, läuft alles glatt. Aber an den "Rändern" des Systems wirfst du die Typinformationen ohne Nachdenken über Bord - und das ist nicht (mehr) typsicher.

Xin schrieb:

Der Unterschied ist schließlich nicht, dass ich keine Typen liefere, sondern nur dann ein typloses Ergebnis liefere, wenn mir der Typ nicht bekannt ist und es dem Entwickler überlasse, die fehlende Information hinzuzufügen. Du verweigerst die Kompilierun und fertig.

Ich verweigere die Kompilation, wenn die Typ nicht miteinander verrechnet werden können, du bei der Zuweisung zu einer typisierten Variablen - und in beiden Fällen braucht der Entwickler einen Holzhammer, um den Compiler zur Zusammenarbeit zu überreden. Wo ist da der prinzipielle Unterschied?

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

(und ein "Zugewinn von Typ-Informationen", der sich beim ersten Anzeichen von Gefahr verflüchtigt, ist imho noch unsicherer als keine Typinformation).

Der Compiler meckert also immer genau da, wo der Programmierer denken und sich konzentrieren muss: beim ersten Anzeichen von Gefahr.

Das ist genau das, was ich erreichen möchte.

Und auf diesem Punkt bleibst du nun stehen? Geh doch einen Schritt weiter und gib dem Programmierer eine Möglichkeit, die Gefahr zu umgehen, anstatt nur ein Hinweisschild "hier wird's unsicher" aufzustellen.

Tust Du doch auch nicht - Du verweigerst die Kompilierung und dann kommen Vorschläge wie "asInt()".

Bei physikalisch unsinnigen Berechnungen ist das auch die (imho) bessere Lösung sie nicht implizit auszuführen (mit unklarer Semantik), sondern den Entwickler explizit erklären lassen, was er vorhat. Und wenn bei deinen Berechnungen am Ende doch nackte int's rauskommen, würde ich mir zweimal überlegen, womit ich rechnen will.

Xin schrieb:

Das ist Programmierung. Wo Gefahr ist, kommentierst Du und stellst ein Schild auf.

Nein, ich begnüge mich nicht mit einem Schild - ich gebe meinem Kunden einen Sturzhelm.

[quote=Xin"]

CStoll schrieb:

Xin schrieb:

Tellerrand schrieb:

Dadurch das in manchen Fällen automatisch die Integer Werte genommen werden resultiert in manchen Fällen aus Meter * Kilometer * Millimeter ein vollkommen falsches Ergebnis.

Das Ergebnis ist schon richtig. Wenn Du 3 Meter mal 2000 Millimeter nimmst, dann kommt da 6000 raus. Wohlgemerkt 6000 ohne Typ, noch nichtmals m*mm, obwohl das eine legitime Einheit wäre.
Sorry, aber für eine merkwürdige Frage, ist das die korrekte Antwort.
Ob eine merkwürdige Frage eine dumme oder gar falsche Frage ist, ist eine ganz andere Frage, die nur durch das eigentliche Programm beantwortet werden kann.

Wenn ich 3 Meter mal 2000 Millimeter rechne, habe ich physikalisch eine Flächenangabe - und da erwarte ich als Ergebnis 6 Quadratmeter und keine einheitenlose 6000 (Millimeter sind keine eigenständige Einheit, sondern lediglich eine skalierte Form von Metern).

Die Einheit m*mm wäre eine vollkommen korrekte Angabe, sollte ich also eine Einheit m*mm definieren, hättest Du die auch.
[/quote]Man kann es auch komplizierter machen als unbedingt nötig - 1mm==0.001m, da brauche ich keine neue Einheit "Millimeter" (oder abgeleitete Einheiten, die damit umgehen können).

Xin schrieb:

Aber, wie gesagt: für eine perfekte Welt bist Du bei mir im falschen Theater. Ich entwickle für die Realität und versuche die Realität ein wenig zur perfekten Welt zu bewegen. Üblich ist weiterhin alles mit Ints oder Floats zu machen und einen Schritt vorwärts zu kritisieren, weil er nicht gleich die pefekte Welt ausruft.

Wie ich schon sagte, du bist auf dem richtigen Weg - aber neben der "üblichen" Lösung gibt es auch Ansätze, die ein Stück weiter gekommen sind als deiner, und mit denen mußt du dich auch vergleichen lassen.

Xin schrieb:

Tellerrand schrieb:

Jenachdem welche Operatoren nun wie implementiert sind existieren unterschiedliche Ergebnisse.
Man hat hier keine Möglichkeit bei der Programmierung zu sehen ob nun der Standard Operator genommen wird, oder ob ein anderes Verhalten implementiert ist.

Ehrlich gesagt kann ich nichtmals genau sagen wann die Reihenfolge eine Rolle spielt. Bei MilliMeter * Holz * Meter gegenüber (MilliMeter * Meter) * Holz bin ich mir nichtmehr sicher.
Spielt die Reihenfolge für den Compiler eine Rolle?
(auch wenn hier die Ableitung von int nur theoretischer Natur ist)

Die Reihenfolge kann eine Rolle spielen, wenn Du Verwandschaftsbeziehungen in operatoren herstellst, statt expliziter Umrechnungen.

Meter m = Millimeter( 1000 ) + Meter( 1 );

wäre bei mir nicht zuweisbar, weil Millimeter und Meter nicht soweit verwandt sind, als dass der Operator + sie verstehen würde. Hier würde also auf int gerechnet und versucht m = int(1001); zuzuweisen, was nicht möglich ist.
Hier haben wir also das Warnschild an den Entwickler, dass er das hier deutlicher beschreiben muss. Er muss Verwandtschaftsverhältnisse über explizite Konstruktoren bzw. operator Meter() nutzen,

Hier hast du eher ein Warnschild für dich, daß du zu viele Klassen hast (und durch dein eigenes System nicht mehr durchblickst) - Länge ist eine Größe, Meter und Millimeter sind lediglich verschiedene Einheiten für diese Größe - und "Millimeter(1000)" und "Meter(1)" sollten den selben Wert (und Typ) ergeben.

Xin schrieb:

Wozu asInt()? schrieb:

Kraft k;
int x = k / Newton(1);

Wozu eine Operatoren durchführen?

Kraft k;
int x = k;

Eine implizite Umwandlung kann dir an den unpassendsten Stellen entgegenkommen und deine komplette Rechnung kaputtmachen. Über eine explizite Umwandlung mußt du dem Compiler informieren, sonst verwendet er sie auch nicht.

[Braunstein]

CStoll schrieb:

...Dieses Template erschlägt das SI-Einheitensystem mit einem Schlag und ich kann mit allen denkbaren Kombinationen rechnen, ohne irgendwelche int's zu bekommen, deren korrekte Einheit ich erraten/wissen muß. ...

Das System sieht interessant aus, erschlägt aber leider doch nicht das gesamte Einheitensystem. Einheiten mit nichtganzzahligen Exponenten fallen hier raus oder siehst du eine Möglichkeit das mit dem Template zu realisieren?

[Tellerrand]

Xin schrieb:

Die Reihenfolge kann eine Rolle spielen, wenn Du Verwandschaftsbeziehungen in operatoren herstellst, statt expliziter Umrechnungen.

Die Verwandschaftsbeziehung durch Operatoren hast du selber rausgehauen mit dem Satz:

Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.

Aber mein Problem bezieht sich nicht nur auf die Reihenfolge und lässt sich genauso auf die Umwandlung über den Konstruktor übertragen.

Meter m = Meter( Millimeter( 1000 ) ) + Meter( 1 )

Bzw. wenn es die Umrechnung nicht gäbe, die Umrechnung selbst festlegen. In dem Fall hat er hier das Warnschild bekommen, dass er genau an der Stelle denken muss, damit er Millimeter und Meter nicht einfach addiert.

Meter m = Meter( Millimeter( 1000 ) / 1000 ) + Meter( 1 )

Der Programmierer muss wissen ob die Umrechnung so existiert.

Wie gesagt im schlimmsten Fall verwendet das jemand als Framework.
Hat in seinem Programm Zeilen wie:
Meter m = Meter( Millimeter( 1000 ) / 1000 ) + Meter( 1 )

Millimeter(1000) / 1000 sind Millimeter(1)
(Vergleichbar mit Fall A: Meter m = 7 * Meter( 2 ); // => Meter( 14 ) => zuweisbar)

Jetzt erweitert man das Framework um diese Umrechnung und aus der Zeile:
Meter m = Meter( Millimeter( 1000 ) / 1000 ) + Meter( 1 )
resultiert ein Ergebnis um den Faktor 1000 vergrößert.

Ok, dein Satz sagt ja aus, dass er an der Stelle ein Warnschild bekommen würde, warum und wie sieht das aus?
In beiden Fällen bekommt der Compiler zu einem Ausdruck Meter(Millimeter).
Als Meter(Integer) behandelt er es nur, wenn der Konstruktor Meter(Millimeter) nicht existiert.
Warnt der Compiler einen, wenn er Millimeter als Integer behandelt?

Meine Kritik basiert ja hauptsächlich darauf, dass der Programmierer an einigen Stellen nicht mitbekommt ob nun ein Meter(1) als Integer behandelt wird oder nicht.

[CStoll]

Braunstein schrieb:

CStoll schrieb:

...Dieses Template erschlägt das SI-Einheitensystem mit einem Schlag und ich kann mit allen denkbaren Kombinationen rechnen, ohne irgendwelche int's zu bekommen, deren korrekte Einheit ich erraten/wissen muß. ...

Das System sieht interessant aus, erschlägt aber leider doch nicht das gesamte Einheitensystem. Einheiten mit nichtganzzahligen Exponenten fallen hier raus oder siehst du eine Möglichkeit das mit dem Template zu realisieren?

Hmm, Punkt für dich, aber prinzipiell auch lösbar - ich verwende zwei int-Parameter, um die Potenz jeder Basiseinheit zu beschreiben (Measure<x,y,...> stellt dann ein Meter^x/y dar) - und erlaube implizite Umwandlungen zwischen Measure<x,y,...> und Measure<n*x,n*y,...>.

(OK, das stellt mich vor das nächste Problem, mit irrationalen Exponenten umgehen zu können - aber wieviele Physiker verwenden die?)

[Theston]

...

[Braunstein]

Ich denke das wars so ziemlich. Mir ist noch keine Einheit mit irrationalen Exponenten untergekommen. Sollte also so gehen. Ich arbeite auf dem Gebiet Bauphysik.
Ich bin nämlich ein wenig auf der Suche nach einen schönen Parameter/Einheitensystem. Das was wir gerade verwenden hat ein paar Macken. Das was mal bei boost vorgeschlagen war hatte mich auch nicht so überzeugt.

[Neugierig]

Braunstein schrieb:

Ich denke das wars so ziemlich. Mir ist noch keine Einheit mit irrationalen Exponenten untergekommen. Sollte also so gehen. Ich arbeite auf dem Gebiet Bauphysik.
Ich bin nämlich ein wenig auf der Suche nach einen schönen Parameter/Einheitensystem. Das was wir gerade verwenden hat ein paar Macken. Das was mal bei boost vorgeschlagen war hatte mich auch nicht so überzeugt.

Welche Einheit hat sie denn, die gebrochenen Exponenten?

[Braunstein]

Was mir als erstes einfällt
Wasseraufnahmekoeffizient
$\frac{kg}{m^2s^{0.5}}$

[edit]
Hier noch der Wiki-Link dazu
http://de.wikipedia.org/wiki/Wasseraufnahmekoeffizient
[edit]

[Tellerrand]

Ich schlage mal einen anderen Ansatz vor.

Basisklasse Unit.
Davon dann abgeleitet:
1. Basiseinheiten: KGUnit, MeterUnit, etc als konstante Objekte, quasi ein enum.
2. Numerische Werte: NumberUnit, welche einen numerischen Datentyp innehält.
3. Operationen: MultiplUnit, usw welche aus zwei Units besteht.

Der Wasseraufnahmekoeffizient wäre dann eine Zusammensetzung aus:

3 kg / (m² * (s^0.5))
=>
Andere Notation:
(* 3 (/ kg (* (exp m 2) (exp s (/ 1 2)))))
=>
MultiplUnit(
    NumberUnit(3),
    DivUnit(
        KGUnit(),
        MultiplUnit(
            ExpUnit(
                MeterUnit(),
                NumberUnit(2)),
            ExpUnit(
                SekUnit(),
                DivUnit(
                    NumberUnit(1),
                    NumberUnit(2))))))

Sieht kompliziert aus, aber wenn man die Operatoren anbietet und aus z.B. NumberUnit(3) * KGUnit() einfach ein MultiplUnit(NumberUnit(3), KGUnit()) macht, dann lässt es sich wie gewohnt schreiben.

Das schöne daran ist, dass eine Ausgabefunktion rekursiv einfach durch alle Unit Objekte durchlaufen kann. Jede Unit Klasse kann so sehr schöne angepasste Ausgabe Funktionen haben, z.B. kann die Ausgabefunktion der MultiplUnit darauf reagieren, dass zwei NumberUnit Objekte direkt miteinander verrechnet werden. Ebenso kann dies bei der Eingabe über die Operatoren schon geschehen und eine Rechnung Wasseraufnahmekoeffizient * 8 führt nicht zu einer weiteren Schachtelung, sondern zu einem Ergebnis mit den gleichen Einheiten.

Problematischer wird das natürlich wenn es darum geht Terme wirklich zu berechnen und zu vereinfachen. Ist also erstmal nur eine Form der Darstellung, der Datenorganisation.

Ich lass das mal so als ganz anderen Ansatz stehen ... nur ein Gedanke, eine Idee, mehr nicht

[Xin]

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Das Dumme ist halt nur, dass die Informatik sich auch mit Einheiten beschäftigt, die sich durch SI Einheiten nur ganz schlecht ausdrücken lassen, mit denen man aber auch rechnen können muss: Butterbrot, Teppichboden, Krieger.

Ein "Butterbrot" ist keine Einheit, sondern eine Größe - die dazugehörige Einheit wäre "Anzahl".

*lach* Okay... Und wenn ich an die Steckdose packe durchströhmt mich 230 Stück Volts, richtig. Volt ist eine physikalische Größe und Größen werden in "Anzahl" gerechnet.

Du hattest Physik Leistungskurs und kennst nicht den Unterschied zwischen "Größe" und "Einheit"? Die Größe "Butterbrote" wird in "Stück" gemessen, die Größe "Spannung" in "Volt".

Der Unterschied zwischen "Größe" und "Einheit" ist also dass Butterbrote in Stück gemessen wird und Spannung Volt?
Aha. Verstehst Du die Bedeutung von dem, was Du da schreibst?

Sorry, aber ich breche hier ab. Das ist doch absolut witzlos und beim Deinem restlichen Posting habe ich nicht viel interessanteres gelesen. Damit Du Dich nicht vollkommen ignoriert fühlst, will ich dennoch zu einem was schreiben:

CStoll schrieb:

Eine implizite Umwandlung kann dir an den unpassendsten Stellen entgegenkommen und deine komplette Rechnung kaputtmachen. Über eine explizite Umwandlung mußt du dem Compiler informieren, sonst verwendet er sie auch nicht.

Sowas ist vollkommen ohne Aussage, pures Geblubber. Ich verlange explizite int-Konstruktoren, Typsicherheit ist durch den Copy-Construktor gegeben. Also passt. Und dass man explizite Konstruktoren explizit aufrufen muss, ist wohl klar, sonst würde ich sie nicht explizit verlangen. Also was willst Du damit jetzt eigentlich ausdrücken!?
Wenn ich ehrlich bin, halte ich das für die Verkomplizierung von Blah: Wer's nur überfliegt, sieht tolle Worte und "deine Rechnung kaputtmachen". Dann muss das wohl'n Argument sein...
Dass Du mit impliziten int-Konstruktoren einfach nicht landen kannst, ist ein wichtiges - aber weggelassenes Detail, weil ich nur explizite erlaube. Ergo das ganze Geblubber einen Wert von exakt 0 hat, wenn Du Dich auf meine Klassen beziehen willst.

Tellerrand schrieb:

Xin schrieb:

Die Reihenfolge kann eine Rolle spielen, wenn Du Verwandschaftsbeziehungen in operatoren herstellst, statt expliziter Umrechnungen.

Die Verwandschaftsbeziehung durch Operatoren hast du selber rausgehauen mit dem Satz:

Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.

Oookay... Aber dass zwischen Meter und Meter^2 eine andere Beziehung besteht als zwischen Meter und Millimetern, ist nachvollziehbar?

Tellerrand schrieb:

Aber mein Problem bezieht sich nicht nur auf die Reihenfolge und lässt sich genauso auf die Umwandlung über den Konstruktor übertragen.

Meter m = Meter( Millimeter( 1000 ) ) + Meter( 1 )

Bzw. wenn es die Umrechnung nicht gäbe, die Umrechnung selbst festlegen. In dem Fall hat er hier das Warnschild bekommen, dass er genau an der Stelle denken muss, damit er Millimeter und Meter nicht einfach addiert.

Das Warnschild erhält er durchaus, denn den expliziten Konstruktor vor Meter muss er schließlich aufrufen, damit er das Warnschild aus dem Weg bekommt und er sich damit absichtlich über die Vorstellungen des Compilers hinwegsetzt.

Tellerrand schrieb:

Meter m = Meter( Millimeter( 1000 ) / 1000 ) + Meter( 1 )

Der Programmierer muss wissen ob die Umrechnung so existiert.

Wenn nicht er... wer dann?
Ich mache mir das einfacher: Ich rechne nicht ohne Aufforderung um.

Tellerrand schrieb:

Wie gesagt im schlimmsten Fall verwendet das jemand als Framework.
Hat in seinem Programm Zeilen wie:
Meter m = Meter( Millimeter( 1000 ) / 1000 ) + Meter( 1 )

Millimeter(1000) / 1000 sind Millimeter(1)

Korrekt. Und wieder der explizite Konstruktor, damit das ganze kompilierbar wird und damit das Warnschild an den Entwickler, hier besonders aufmerksam zu sein.

Tellerrand schrieb:

Jetzt erweitert man das Framework um diese Umrechnung und aus der Zeile:
Meter m = Meter( Millimeter( 1000 ) / 1000 ) + Meter( 1 )
resultiert ein Ergebnis um den Faktor 1000 vergrößert.

vergrößert? Statt 2m kämen 1,001m raus. Oder verstehe ich hier grade was falsch?

Aber auch hier muss erst das Framework verändert werden und wenn Du das Framework veränderst und damit andere Spielregeln einbaust, dann argumentierst damit Du nicht gegen meine Klasse.

Tellerrand schrieb:

Ok, dein Satz sagt ja aus, dass er an der Stelle ein Warnschild bekommen würde, warum und wie sieht das aus?
In beiden Fällen bekommt der Compiler zu einem Ausdruck Meter(Millimeter).
Als Meter(Integer) behandelt er es nur, wenn der Konstruktor Meter(Millimeter) nicht existiert.
Warnt der Compiler einen, wenn er Millimeter als Integer behandelt?

Meter ist wohl eindeutig eine Größe, die auch als gebrochene Zahl vorkommt. Es von int abzuleiten ist also suboptimal. Das es sich um Beispielcharakter handelt und um keine Produktivlösung, ist wohl eindeutig.

Tellerrand schrieb:

Meine Kritik basiert ja hauptsächlich darauf, dass der Programmierer an einigen Stellen nicht mitbekommt ob nun ein Meter(1) als Integer behandelt wird oder nicht.

Ein Meter ist entweder ein Meter oder ein Integer. Wenn er sich nicht als Meter verhalten kann, wird er ein Integer. Konvertierungsoperatoren gibt es ausschließlich explizit. Rechnen kannst Du, was immer Du willst, aber du kannst nur zuweisen, wenn die Sache sicher ist oder vom Entwickler abgesegnet.

[Tellerrand]

Xin schrieb:

Oookay... Aber dass zwischen Meter und Meter^2 eine andere Beziehung besteht als zwischen Meter und Millimetern, ist nachvollziehbar?

Ja, die Beziehung ist in beiden Fällen aber durch einen Operator hergestellt.
Mehr wollte ich nicht sagen, dachte eher du willst solche Ausdrücke wie Meter(3) + Millimeter(7) fördern.
Denn irgendwie geht es doch darum etwas zu schaffen was einem erlaubt mit Maßeinheiten zu rechnen

Zum Rest:

Da hast du glaub ich was falsch verstanden.

Ich schreibe folgendes:
Meter m = Meter( Millimeter( 1000 ) ) + Meter( 1 )

Wenn der explizite Konstruktor Meter(Millimeter) mit der passenden Umrechnung existiert, dann kommt da als Ergebnis 2 Meter raus.

Existiert der explizite Konstruktor nicht, so wird Milimeter(1000) einfach als Integer Wert 1000 an den Konstruktor Meter(Integer) übergeben und das Ergebnis ist 1001 Meter.

Der Programmierer muss also höllisch aufpassen, welcher Konstruktor nun mit welcher Umwandlung auch funktioniert.
Und das Beispiel zielte darauf ab, dass eine Implementation wie:
Meter m = Meter(Millimeter(1000) / 1000) + Meter(1)
eine potentielle Fehlerquelle ist, da ja jemand auf die Idee kommen könnte und den expliziten Konstruktor Meter(Millimeter) inklusive Umrechnung implementiert.
Und da hast du dann Recht, es kommt ein Wert raus Meter(1,0001), der einfach viel zu klein ist.

Fakt ist für mich, dass der Programmierer bei jedem Konstruktoraufruf darauf achten muss welche Umwandlung gemacht wird.
Das Beispiel von Shade of Mine hat durch asInt nunmal den Vorteil, dass der Entwickler diese Arbeit nicht hat. Wenn der Konstruktor Meter(Millimeter) nicht existiert, dann bekommt man das vom Compiler gesagt und man implementiert Meter(Millimeter.asInt())
Das bringt dann auch den Vorteil mit sich, dass eine spätere Implementation des Konstruktors Meter(Millimeter) keine Auswirkungen auf den schon vorhandenen Code hat.

Aber auch hier muss erst das Framework verändert werden und wenn Du das Framework veränderst und damit andere Spielregeln einbaust, dann argumentierst damit Du nicht gegen meine Klasse.

Ich habe es nciht verändert, ich sage nur, dass Erweiterungen wie ein zusätzlicher Konstruktor, der nur Code weiter vereinfachen soll, sehr tiefe Auswirkungen haben kann.
Du kannst natürlich sagen dein Framework darf man nicht erweitern und du wirst es selber nie erweitern. Aber das ist in meinen Augen unrealistisch und ein Zeichen für ein schlechtes Framework. Es existieren ja andere Ansätze bei denen man mit solchen Erweiterungen keine Probleme hat.

Was ich mich mittlerweile auch frage:
Was passiert bei einfachen Rechnungen wie Meter(3) * KG(5), welcher Typ kommt da raus. Und wenn da nur ein typloser Wert retuniert, was bringt mir das Framework?
Weil irgendwie sehe ich schon unmengen von verschiedenen TypKlassen und unmengen von unterschiedlichen Operatoren vor mir.

[Tellerrand]

Habe da doch tatsächlich was übersehen.

Xin schrieb:

Dass Du mit impliziten int-Konstruktoren einfach nicht landen kannst, ist ein wichtiges - aber weggelassenes Detail, weil ich nur explizite erlaube.

Wie kann man nur explizite Integer Konstruktoren erlauben?
Kann man sagen ich verbiete es Konstruktor x(y) mit Subklassen von y aufzurufen?

Weil das wäre ja auch die Variante um meine Argumente etwas zu entkräften.

[camper]

Ist mal jemand so freundlich und fasst zusammen, was gerade diskutiert wird?

[Xin]

Tellerrand schrieb:

Xin schrieb:

Oookay... Aber dass zwischen Meter und Meter^2 eine andere Beziehung besteht als zwischen Meter und Millimetern, ist nachvollziehbar?

Ja, die Beziehung ist in beiden Fällen aber durch einen Operator hergestellt.
Mehr wollte ich nicht sagen, dachte eher du willst solche Ausdrücke wie Meter(3) + Millimeter(7) fördern.
Denn irgendwie geht es doch darum etwas zu schaffen was einem erlaubt mit Maßeinheiten zu rechnen

Natürlich möchte ich das Rechnen mit Maßeinheiten fördern. Aber natürlich möchte ich nicht viele Klassen für eine Einheit. Millimeter sind 1/1000 Meter, also möge man doch bitte möglichst in Metern rechnen.

Tellerrand schrieb:

Zum Rest:

Da hast du glaub ich was falsch verstanden.

Ich schreibe folgendes:
Meter m = Meter( Millimeter( 1000 ) ) + Meter( 1 )

Wenn der explizite Konstruktor Meter(Millimeter) mit der passenden Umrechnung existiert, dann kommt da als Ergebnis 2 Meter raus.

Ich schreibe keine Konvertierungskonstruktoren, damit sind Millimeter und Meter unabhängige Größen.

Es wird auch keine geben. Wenn Du in Millimetern rechnen möchtest, dann rechne in Meter um.

Meter Millimeter( int i ) { return Meter( i / 1000 ); }
int Meter::AsMilli() { return MeterValue * 1000; }   

Meter meter = Millimeter( 2000 );

printf( "als Millimetern: %d\n", meter.AsMilli() );

Damit entspricht

Meter m = Millimeter( 1000 ) + Meter( 1 );

dem, was Du erwartest, ohne dass es eine konkurrierende Meterklasse gibt.
Es gibt nur die Basiseinheit, das lässt man sich leicht merken.
int i = Millimeter( 1000 ) * Butterbrot( 7 );
ganz logisch 7 Unit.

Tellerrand schrieb:

Existiert der explizite Konstruktor nicht, so wird Milimeter(1000) einfach als Integer Wert 1000 an den Konstruktor Meter(Integer) übergeben und das Ergebnis ist 1001 Meter.

Aufgrund der fehlenden Beziehung zwischen Millimeter und Meter ist das Ergebnis 1001. Die Einheit ist aber nicht Meter, sondern nicht festgelegt, bzw. "Unit". Eine Zuweisung auf Meter wird also abgelehnt, womit der Programmierer weiß, dass er hier überlegen muss, was er tun muss, um hier zwei kompatible Einheiten zu addieren.

Tellerrand schrieb:

Der Programmierer muss also höllisch aufpassen, welcher Konstruktor nun mit welcher Umwandlung auch funktioniert.
Und das Beispiel zielte darauf ab, dass eine Implementation wie:
Meter m = Meter(Millimeter(1000) / 1000) + Meter(1)
eine potentielle Fehlerquelle ist, da ja jemand auf die Idee kommen könnte und den expliziten Konstruktor Meter(Millimeter) inklusive Umrechnung implementiert.
Und da hast du dann Recht, es kommt ein Wert raus Meter(1,0001), der einfach viel zu klein ist.

Auf die Idee hat niemand zu kommen, denn die Typverwaltung wird einmalig geschrieben.
Wenn ein funktionierendes Konstrukt durch fehlerhafte Erweiterungen zu Fehlern neigt, so ist das nicht in der Verantwortung desjenigen, der das funktionierende Konstrukt erstellt hat.
Wer mal eben so unüberlegt "erweitert", ohne das Konzept verstanden zu haben, hat's auch nicht besser verdient.
Das ist kein Problem meiner Klassen, sondern ein ganz allgemeines.

Tellerrand schrieb:

Fakt ist für mich, dass der Programmierer bei jedem Konstruktoraufruf darauf achten muss welche Umwandlung gemacht wird.
Das Beispiel von Shade of Mine hat durch asInt nunmal den Vorteil, dass der Entwickler diese Arbeit nicht hat. Wenn der Konstruktor Meter(Millimeter) nicht existiert, dann bekommt man das vom Compiler gesagt und man implementiert Meter(Millimeter.asInt())

Der Konstruktor Meter( varOfClassMillimeter ) existiert grundsätzlich nicht, also wird varOfClassMillimeter als Int aufgefasst. Wenn Dir das nicht explizit genug ist, ist das okay. Aber fraglich ist mein Vorgehen nicht.

Tellerrand schrieb:

Das bringt dann auch den Vorteil mit sich, dass eine spätere Implementation des Konstruktors Meter(Millimeter) keine Auswirkungen auf den schon vorhandenen Code hat.

Ich halte es für falsch und für einen Designfehler, zwei Klassen für eine Einheitenklasse zu implementieren.

Tellerrand schrieb:

Aber auch hier muss erst das Framework verändert werden und wenn Du das Framework veränderst und damit andere Spielregeln einbaust, dann argumentierst damit Du nicht gegen meine Klasse.

Ich habe es nciht verändert, ich sage nur, dass Erweiterungen wie ein zusätzlicher Konstruktor, der nur Code weiter vereinfachen soll, sehr tiefe Auswirkungen haben kann.

Eine Erweiterung, die tiefe Auswirkungen hat - und das ist hier der Fall - ist eine sehr deutliche Veränderung und in diesem Fall einfach nur falsch.

Tellerrand schrieb:

Du kannst natürlich sagen dein Framework darf man nicht erweitern und du wirst es selber nie erweitern. Aber das ist in meinen Augen unrealistisch und ein Zeichen für ein schlechtes Framework. Es existieren ja andere Ansätze bei denen man mit solchen Erweiterungen keine Probleme hat.

Ich sage, dass man das Framework überlegt erweitern kann. Konvertierungskonstruktoren sind keine überlegte Erweiterung.

Tellerrand schrieb:

Was ich mich mittlerweile auch frage:
Was passiert bei einfachen Rechnungen wie Meter(3) * KG(5), welcher Typ kommt da raus. Und wenn da nur ein typloser Wert retuniert, was bringt mir das Framework?
Weil irgendwie sehe ich schon unmengen von verschiedenen TypKlassen und unmengen von unterschiedlichen Operatoren vor mir.

Wenn Du Meter*Kilogramm nicht klassifizierst, was Du in der Physik ja durch die Beschreibung "kg*m" tust, wie möchtest Du es sonst ausdrücken, dass es etwas anderes als eine typlose Größe ist? Schau Dir das Template an, dass CStoll im INet gefunden hat. Es ist aufwendig, weil die physikalische Schreibweise in C++ nunmal nicht 'nicht aufwendig' zu beschreiben ist.
Es gibt in C++ kein Verfahren, um typsicher und gleichzeitig einfach zu sein.
Daher muss man sich irgendwo auch überlegen, an welchem Punkt man aussteigen muss (nicht will). Man kann nicht alles abbilden, es wird immer Beispiele geben, die man nicht abbilden konnte.
Aber man kann den Alltag abbilden. Typsicherheit im Alltag, das wäre ein gigantischer Schritt nach vorne.

[Xin]

Tellerrand schrieb:

Habe da doch tatsächlich was übersehen.

Xin schrieb:

Dass Du mit impliziten int-Konstruktoren einfach nicht landen kannst, ist ein wichtiges - aber weggelassenes Detail, weil ich nur explizite erlaube.

Wie kann man nur explizite Integer Konstruktoren erlauben?
Kann man sagen ich verbiete es Konstruktor x(y) mit Subklassen von y aufzurufen?

Weil das wäre ja auch die Variante um meine Argumente etwas zu entkräften.

Du kannst x nicht mit y oder Subklassen von y aufrufen, da es nur den Copyconstruktor gibt, der x oder Subklassen von x akzeptiert und den expliziten int Konstruktor.

[Undertaker]

Xin schrieb:

int i = Millimeter( 1000 ) * Butterbrot( 7 );
ganz logisch 7 Unit.

Millimeter() ist 'ne funktion die durch 1000 teilt und Butterbrot() eine, die den originalwert wieder zurückgibt, oder wie soll man sowas verstehen?
falls das konstruktoren sind - wo sind die objekte geblieben? hat diese sprache sowas wie 'nen GC?

[camper]

Xin schrieb:

int i = Millimeter( 1000 ) * Butterbrot( 7 );
ganz logisch 7 Unit.

und wenn ich aber lieber in cgs rechne?

[Mr. N]

Undertaker schrieb:

falls das konstruktoren sind - wo sind die objekte geblieben? hat diese sprache sowas wie 'nen GC?

Dafür gibt es in C++ eindeutige Regeln. Das ist hier kein Problem.

[Tellerrand]

Xin schrieb:

Tellerrand schrieb:

Wenn der explizite Konstruktor Meter(Millimeter) mit der passenden Umrechnung existiert, dann kommt da als Ergebnis 2 Meter raus.

Ich schreibe keine Konvertierungskonstruktoren, damit sind Millimeter und Meter unabhängige Größen.

Dann bringe das bitte nicht als Beispiel für andere Argumente.

Xin schrieb:

Meter m = Meter( Millimeter( 1000 ) ) + Meter( 1 );

1000 Millimeter sind 1m und damit ergibt sich 2m = 1m + 1m, die typsicher zugewiesen werden können.

Xin schrieb:

Tellerrand schrieb:

Existiert der explizite Konstruktor nicht, so wird Milimeter(1000) einfach als Integer Wert 1000 an den Konstruktor Meter(Integer) übergeben und das Ergebnis ist 1001 Meter.

Aufgrund der fehlenden Beziehung zwischen Millimeter und Meter ist das Ergebnis 1001. Die Einheit ist aber nicht Meter, sondern nicht festgelegt, bzw. "Unit". Eine Zuweisung auf Meter wird also abgelehnt, womit der Programmierer weiß, dass er hier überlegen muss, was er tun muss, um hier zwei kompatible Einheiten zu addieren.

Unit ist doch von Integer abgeleitet, wieso sollte der Konstruktor nicht mit Integer funktionieren?
Darauf läuft mein Beispiel hinaus, wie kann man einem Konstruktor Meter(Integer) verbieten, dass er mit Subklassen von Integer funktioniert.
Dass habe ich auch unten mit x(y) gefragt.

Xin schrieb:

Tellerrand schrieb:

Das bringt dann auch den Vorteil mit sich, dass eine spätere Implementation des Konstruktors Meter(Millimeter) keine Auswirkungen auf den schon vorhandenen Code hat.

Ich halte es für falsch und für einen Designfehler, zwei Klassen für eine Einheitenklasse zu implementieren.

Ich halte das für OK, warum nicht? Weil dein Framework damit nicht klarkommt?

Xin schrieb:

Tellerrand schrieb:

Aber auch hier muss erst das Framework verändert werden und wenn Du das Framework veränderst und damit andere Spielregeln einbaust, dann argumentierst damit Du nicht gegen meine Klasse.

Ich habe es nciht verändert, ich sage nur, dass Erweiterungen wie ein zusätzlicher Konstruktor, der nur Code weiter vereinfachen soll, sehr tiefe Auswirkungen haben kann.

Eine Erweiterung, die tiefe Auswirkungen hat - und das ist hier der Fall - ist eine sehr deutliche Veränderung und in diesem Fall einfach nur falsch.

Es liegt nur am Design das diese kleine Erweiterung so tiefe Auswirkungen hat.
Ein Design bei dem diese kleine Erweiterungen nicht so tiefe Auswirkungen hat halte ich für besser, wenn es nur an so einer Kleinigkeit wie der Ableitung aller Klassen von Integer liegt.
Ergo ziehe ich das Design von Shade of Mine oder anderen vor.
Dein Design bietet anscheinend sehr viele Fallstricke und Regeln, aber kaum Vorteile.

Xin schrieb:

Tellerrand schrieb:

Du kannst natürlich sagen dein Framework darf man nicht erweitern und du wirst es selber nie erweitern. Aber das ist in meinen Augen unrealistisch und ein Zeichen für ein schlechtes Framework. Es existieren ja andere Ansätze bei denen man mit solchen Erweiterungen keine Probleme hat.

Ich sage, dass man das Framework überlegt erweitern kann. Konvertierungskonstruktoren sind keine überlegte Erweiterung.

Dann landen wir wieder bei den Operatoren.
Mit irgendetwas musst du konvertieren, ansonsten beantworte mir nochmals folgende Frage:
Was nutzt das ganze Framework?
Die erste Antwort waren die Konvertierungsoperatoren. Da ich dort Probleme sah hast du auf Konvertierung mittels Konstruktoren verwiesen. Jetzt existieren da auch Probleme und du nimmst sie wieder raus?
Womit konvertierst du dann Maßeinheiten untereinander?

In beiden Fällen habe ich übrigens die gleiche Kritik wie CStoll gebracht.
Die impliziten Typumwandlungen nach Integer machen es für den Entwickler unübersehbar welche der überschriebenen Operatoren oder überladenen Konstruktoren benutzt werden. (Deshalb nennt man es ja implizit)
Das fällt natürlich erst dann auf, wenn man Umwandlungen durchführt, welche nicht mit den reinen Werten funktionieren, also bei Meter(3) * Meter(3) ist das numerische Ergebnis dem numerischen Wert der Quadratmeter gleich.
Bei solchen Umwandlungen macht die implizite Verwendung von Integer natürlich kein Problem.

Xin schrieb:

Tellerrand schrieb:

Was ich mich mittlerweile auch frage:
Was passiert bei einfachen Rechnungen wie Meter(3) * KG(5), welcher Typ kommt da raus. Und wenn da nur ein typloser Wert retuniert, was bringt mir das Framework?
Weil irgendwie sehe ich schon unmengen von verschiedenen TypKlassen und unmengen von unterschiedlichen Operatoren vor mir.

Wenn Du Meter*Kilogramm nicht klassifizierst, was Du in der Physik ja durch die Beschreibung "kg*m" tust, wie möchtest Du es sonst ausdrücken, dass es etwas anderes als eine typlose Größe ist? Schau Dir das Template an, dass CStoll im INet gefunden hat. Es ist aufwendig, weil die physikalische Schreibweise in C++ nunmal nicht 'nicht aufwendig' zu beschreiben ist.
Es gibt in C++ kein Verfahren, um typsicher und gleichzeitig einfach zu sein.
Daher muss man sich irgendwo auch überlegen, an welchem Punkt man aussteigen muss (nicht will). Man kann nicht alles abbilden, es wird immer Beispiele geben, die man nicht abbilden konnte.
Aber man kann den Alltag abbilden. Typsicherheit im Alltag, das wäre ein gigantischer Schritt nach vorne.

Also doch Konvertierung mittels Operatoren, dann ein paar Posts zurück und wir sind wieder bei der Verwandschaftsbeziehung mittels Operatoren.
Siehe meine Kritik an der Stelle.
Auch dort war es, der Entwickler hat keine Möglichkeit zu erkennen wann ... bla, bla

... irgendwie drehen wir uns im Kreis und ich glaube langsam das hat hier keinen Sinn.

Nunja, damit steige ich dann wahrscheinlich aus.