Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
Shade Of Mine schrieb:
Xin schrieb:
Eleganz vor Frikelei. Machbarkeit vor Eleganz.
Bei mir geht es so rum:
Stabilität über allem.Vorallem da Eleganz sehr subjektiv ist.
Stabilität sowieso. Bzgl. Eleganz gibt es durchaus einige Dinge, die man beachten kann und die haben häufig nichts mit festgelegten Regeln von Einrücken zu tun.
Da die Sache natürlich subjektiv bleibt, ist jede öffentliche Äußerung in die Richtung zur Kritik verdammt und grade hier spare ich mir das lieber.
Shade Of Mine schrieb:
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Shade Of Mine schrieb:
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Es ist deine Klasse in deiner Domain und du kannst nicht die Operationen der Klasse definieren? Das ist fragwürdig.
Sorry, aber das hier steht in keinem Zusammenhang zu meinen Klassen, was Dir bewußt sein dürfte, da in C++ nicht von int geerbt werden kann.
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Shade Of Mine schrieb:
Soll ich deshalb immer einen Template Konvertierungsoperator anbieten der halt rand() returned damit jedeweder Code kompiliert?
Soll ich auf Dein Posting antworten oder möchtest Du nur ein wenig herumsticheln, dann kann ich mir das auch schenken.
Shade Of Mine schrieb:
C++ bietet hier typsicherheit an um eine Menge an Fehlern vorzubeugen. Das beste Beispiel ist wohl dieser Thread hier. Wieviele Probleme wurden bei der Vererbung von WinFlags -> Win aufgezählt und an wieviele hast du davor gedacht?
Erstens sehe ich bei der Vererbung weiterhin kein zu großes Problem. if( win ) ist eine Definition, die sich aus der Vererbung ergibt, die CStoll und Dir nicht gefallen. Mir gefällt es auch nicht sonderlich, aber ein Problem habe ich damit nicht.
Shade Of Mine schrieb:
Das alles sind potentielle Fehler in der Software - und für was? Was ist der große Vorteil davon dass man die Typsicherheit über Board wirft? Eine einfachere Syntax.
Das hat grade nichts mit klassifizierten Einheiten zu tun...?
Shade Of Mine schrieb:
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Und was spricht dagegen dafür explizit etwas zu definieren?
Nichts und ich habe auch nicht behauptet, dass etwas dagegen sprechen würde.
Trotzdem kann es sein, dass man diese Typen aus einer Lib nimmt und erstmal feststellt, dass eine Konvertierung nicht dabei ist.
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Er kann nun entweder etwas passendes definieren, oder muss die Verantwortung dafür übernehmen, eine typlose Information zu klassifizieren.
Shade Of Mine schrieb:
Kommen wir auf die einfachere Syntax zurück:
Ich kann jederzeit ein Kraft Objekt erstellen indem ich:Kraft k(g.asInt() * s.asInt() / z.asInt());schreibe.
Richtig, kannst Du. Das ist eine andere Möglichkeit. Es spricht nichts dagegen - aber in meinen Augen auch nichts dafür im Vergleich zu einer (theoretisch möglichen) Ableitung.
Shade Of Mine schrieb:
Dadurch erreiche ich eine Typsicherheit ohne einbussen der Funktionalität auf kosten einer (unter Umständen) komplizierteren Syntax.
Falsch. Du erreichst nicht mehr Typsicherheit, der einzige Unterschied ist, dass Du bei jeder Variable "asInt()" dahinter schreiben musst. Du erhältst also wieder ein typloses int.
In meinem Fall wird - sofern nicht typsicher gerechnet werden kann - mit ints gerechnet und Du erhältst ebenfalls ein typloses int.
In beiden Fällen kannst Du das typlose int nicht zuweisen. Du gewinnst also mit asInt keinen Vorteil.Shade Of Mine schrieb:
Denn um mehr geht es nicht - es geht nach wie vor nur um Syntax. Und ich denke nicht dass Syntax es wert ist dafür potentielle Fehler einzubauen. Allein der 1. Ansatz deiner WinFlags war voller Fehler. Keiner dieser Fehler wäre bei Komposition aufgetreten. Und technisch wären beide gleichwertig - lediglich Sicherheit <-> Syntax.
Ich weiß nicht, von welchen Fehlern Du sprichst. Was ich beschrieb, funktioniert problemlos und korrekt - auch unter Mehrfachvererbung, sobald Du die Operatoren in den Namensraum der Klasse holst.
Shade Of Mine schrieb:
@Knuddlbaer:
Apfel muss nur eine Konvertierung für den Basistypen von Birne anbieten:struct Flags { }; struct Win : public Flags { Win(Flags f=Flags()) {} }; struct Socket : public Flags { Socket(Flags f=Flags()) {} }; int main() { Win w; Socket s(w); }Das Problem dabei ist halt: Win und Socket haben nichts gemeinsam. Sie haben lediglich ein gleiches Property. Wenn wir nun aber von dem Property public erben - passieren viele solcher Sachen. Es hat einen Grund warum es den Leitsatz gibt: Make sure inheritance models an is-a relationship.
struct Flags { }; struct Win { Flags f; Win(Flags f=Flags()) {} }; struct Socket { Flags f; Socket(Flags f=Flags()) {} }; int main() { Win w; Socket s(w.f); }Das rettet die Welt?
Wie wir sehen, haben win und socket hier etwas gemeinsames, nämlich die gleichen Flags. Und wenn das passt, dann passt das - und wenn nicht, dann fragt Socket die falschen Flags ab.
Das ist kein Vererbungs oder Kompositionsproblem, das wäre ein Designfehler - egal als ob Vererbung oder Komposition.
-
Xin schrieb:
struct Flags { }; struct Win { Flags f; Win(Flags f=Flags()) {} }; struct Socket { Flags f; Socket(Flags f=Flags()) {} }; int main() { Win w; Socket s(w.f); }Das rettet die Welt?
Es ist auf jedenfall schon mal klarer. Wenn wir nämlich nicht von Win und Socket ausgehen, sondern von etwas näher verwandten Sachen wie Win und Dialog wobei Dialog keinen CCtor für Win bietet. Da hat man so leicht mehrdeutigkeiten für den Programmierer.
Aber das lustige ist: du verteidigst immer noch nur die Nachteile - aber Vorteile nennst du immer noch keine.
Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Problem ist aber:
Kraft k = gewicht * hoehe;Das wird ziemlich sicher klappen, da du eine Konvertierung von int zu Kraft haben willst - richtig?
Aber genau das ist das Problem - convenience ist nicht immer das beste. Wenn man einfach gewicht*hoehe verbietet, gibt es da keine Probleme. Und wenn ich in die seltene Situation komme wo ich das brauche, gibt es immer noch ein
Kraft k = gewicht.asInt() * hoehe.asInt();Hier sieht man dann sofort dass etwas "Typenloses" raus kommt und vom Programmierer erst interpretiert werden muss. Während das bei "gewicht * hoehe" nicht der Fall ist - es ist eine definierte Operation also erwarte ich ein vernünftiges Ergebnis.
Klar ist es schlecht diese Operation zu verbieten - aber es gibt eben Abstufungen zwischen "operation direkt implementiert im interface" und "operation möglich". Ich denke dass man gewicht mit hoehe nicht multiplizieren können muss. Dass es nicht teil des interfaces von Höhe ist diese Operation zu implementieren. Es sollte aber möglich sein wenn ich es unbedingt will.
Das führt zu sicheren Programmen da man einfach Fehler wie gewicht*hoehe wo man breite*hoehe meinte einfach zur Compilezeit eliminiert.
-
Xin schrieb:
if (window & WindowFlags::UseFullscreen) // schlecht if (window.isFullscreen()) // besserVom Prinzip her habe ich da kein Problem mit, es lässt sich auch problemlos in eine Klasse WindowFlags einbrinen.
Was mir hier fehlt sind zusammenhängende Abfragen:if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )
[/quote]Und da sind wir wieder bei der semantischen Frage: Was bedeutet diese Abfrage? "Das Fenster hat beide Flags"? Oder doch "Das Fenster hat mindestens eins der Flags"? (Mit der für int üblichen Bedeutung, die du bisher als Rechengrundlage genommen hast, ist es letzteres)Xin schrieb:
Shade Of Mine schrieb:
Xin schrieb:
Anstatt mich darüber zu ärgern, dass ich das nicht kompilieren kann, habe ich wenigstens ein Ergebnis.
Das ist also die viel gelobte Qualität deiner Software?
Eleganz vor Frikelei. Machbarkeit vor Eleganz.
Und wo steht in deiner Prioritätenliste die Typsicherheit? Soweit ich das überblicke, sehr weit unten.
Xin schrieb:
Shade Of Mine schrieb:
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ja, solange man mit Einheiten rechnet und nicht nur mit aufbereiteten int's - indem du alle Einheiten von int ableitest, pulverisierst du dir deine heißgeliebte Typsicherheit wieder (Beispiel: Du hast eine Einheit Kraft und Weg - das Produkt davon wäre eigentlich eine Leistung, aber nun bekommst du plötzlich eine reine Zahl heraus, weil Leistung nicht in deiner Einheitensammlung erwähnt wird).
btw, außerdem brauchst du praktisch unendlich viele Einheitenkombinationen, um alle möglichen Multiplikationen darstellen zu können - mit der bereits angerissenen Template-Klasse Measure<...> hast du die alle auf einen Haufen.
Xin schrieb:
Tellerrand schrieb:
Xin schrieb:
Nur eine paar Zeilen weiter steht, warum es doch Sinn ergibt, wenn der Compiler grade die passende Formelsammlung nicht parat hat.
Man gestattet also unsinnige Operationen weil?
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Gewicht*Strecke ist ein Wert, den man in kg*m angibt, Zeit im Quadrat hat die Einheit Quadratsekunden - was die physikalisch darstellen, ist erstmal bedeutungslos. Ich kann diese Zwischenwerte bei Bedarf als Measure<1,0,1,...> bzw. Measure<0,2,0,...> behandeln und miteinander verrechnen, ohne mich um ihre physikalische Bedeutung zu kümmern - der Quotient aus beidem ist ein Measure<1,-2,1,...>, also eine Kraft.
Xin schrieb:
Tellerrand schrieb:
Xin schrieb:
Abgesehen davon, werden sich die Mathematiker nicht geschlagen fühlen, immerhin müssen sie zur Zeit damit leben, dass alles nur typlose Integer (bzw. Floats) sind.
Der Mathematiker wundert sich über Integer / Float nicht, denn die verschiedenen Zahlensysteme sind bis auf einige Ausnahmen, wie die rationalen, komplexen, ..., gut umgesetzt. (Lisp wäre gründlicher aber es reicht auch so)
Nur wenn man schon eine Maßeinheit einführt, dann sollte man diese auch in Berechnungen beachten.Bin ich absolut dafür. Aber wenn man Maßeinheiten einführt und eine Rechnung nicht vom Compiler nicht verstanden wird, weil der Entwickler etwas neues macht, dann ist es nicht Aufgabe der Sprache ihm das grundsätzlich zu verbieten.
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Xin schrieb:
Tellerrand schrieb:
Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?Wozu? Damit Du weißt, dass ein Meter plus ein Meter wieder ein Meter ergibt. Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.
Ja, das ist ein Mehrwert, der die Klasse rechtfertigt. Aber die implizite Behandlung des Meters als reinen int, die du durch deine (ich weiß: hypothetische) Ableitung nachgeworfen bekommst, rechtfertigst du damit noch lange nicht. Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Xin schrieb:
Woher soll ich wissen, wem Meter + Gewicht hilft? Ich kann garantieren, dass ein class Meter + ein class Meter wieder ein class Meter ergibt. Wie soll ich garantieren, dass Meter + Gewicht grundsätzlich sinnlos ist? Wenn ich das nicht garantieren kann, wie soll ich dann eine Einschränkung begründen?
Kannst du begründen, daß diese Addition irgendeinen Sinn ergibt? Wenn nein, warum willst du sie dann erlauben?
Xin schrieb:
Vor dem BMI gab es diese "Formel" für richtiges Gewicht: Gewicht = Groesee - 100
Mathematisch bedeutet das auch Groesse = Gewicht + 100cm
Wenn jemand das rechnen will, warum sollte ich ihm das verbieten?
Soll er doch rechnen. Was die Sprache nicht darf, ist ein solches Ergebnis kritiklos einem Typ wie Meter zuweisen.
Bei Gewicht + 100cm kommt beispielsweise typlose 175 raus. Wenn ich das einer Größe zuordnen will, dann muss ich das bestätigen: Groesse = Zentimeter( Gewicht + 100 );Ja, solche Formeln sind auch der Alptraum für jeden Physiker - und vermutlich auch nicht der richtige Einsatzort für ein typisiertes Einheitensystem. Und aus physikalischer Sicht würde ich die Formel eher als "Groesse/1cm == Gewicht/1kg + 100" schreiben.
Xin schrieb:
Ich sehe mich nicht in der Lage alle mathematischen und physikalischen Formen, die existieren und in Zukunftexistieren werden, in meinen Klassen abzubilden. Deswegen darf ich aber nicht die Kreativität der Entwickler enschränken.
Und darum gibt es Templates - mit denen können alle Einheiten und -kombinationen des SI-Systems mit einem Schlag erfasst werden.
(aber gib's zu, du hast dir den Ansatz noch nicht einmal angesehen)Xin schrieb:
Shade Of Mine schrieb:
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Dann solltest du dafür sorgen, daß der Compiler dein Einheitensystem versteht. Wenn ich gezwungen bin, die (typlosen) Rechenergebnisse von Hand in den richtigen Typ zu quetschen, bleibt von deiner Typsicherheit nicht mehr viel übrig.
Xin schrieb:
Shade Of Mine schrieb:
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Es ist deine Klasse in deiner Domain und du kannst nicht die Operationen der Klasse definieren? Das ist fragwürdig.
Sorry, aber das hier steht in keinem Zusammenhang zu meinen Klassen, was Dir bewußt sein dürfte, da in C++ nicht von int geerbt werden kann.
Also ist alles, was nicht zu deiner Argumentation passt, unsinnig und irrelevant? Auch eine interessante Einstellung, um unbeliebten Argumenten aus dem Weg zu gehen.
Xin schrieb:
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Hast du schonmal daran gedacht, daß int zu viele Operatoren zur Verfügung stellt, um es als Ausgangsbasis für ein typsicheres Einheitensystem dienen zu können? Wenn ich sowas entwerfe, beginne ich lieber bei einer leeren Klasse und definiere mir genau die Operationen, die ich als nötig ansehe. Dann muß ich mir keinen Kopf darüber machen, welche geerbten Operatoren Sinn machen - bzw. wie ich ihr Ergebnis interpretieren soll.
Xin schrieb:
Shade Of Mine schrieb:
C++ bietet hier typsicherheit an um eine Menge an Fehlern vorzubeugen. Das beste Beispiel ist wohl dieser Thread hier. Wieviele Probleme wurden bei der Vererbung von WinFlags -> Win aufgezählt und an wieviele hast du davor gedacht?
Erstens sehe ich bei der Vererbung weiterhin kein zu großes Problem. if( win ) ist eine Definition, die sich aus der Vererbung ergibt, die CStoll und Dir nicht gefallen. Mir gefällt es auch nicht sonderlich, aber ein Problem habe ich damit nicht.
if(win) ist eine Möglichkeit, die dein Entwurf bietet - zwar technisch unsinnig, aber trotzdem verfügbar. In einem vernüftigen Design sollten solche unsinnigen Anweisungen gar nicht erst möglich sein.
Xin schrieb:
Shade Of Mine schrieb:
Das alles sind potentielle Fehler in der Software - und für was? Was ist der große Vorteil davon dass man die Typsicherheit über Board wirft? Eine einfachere Syntax.
Das hat grade nichts mit klassifizierten Einheiten zu tun...?
Shade Of Mine schrieb:
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Und was spricht dagegen dafür explizit etwas zu definieren?
Nichts und ich habe auch nicht behauptet, dass etwas dagegen sprechen würde.
Trotzdem kann es sein, dass man diese Typen aus einer Lib nimmt und erstmal feststellt, dass eine Konvertierung nicht dabei ist.
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Nur ist es immer schlecht, wenn der Entwickler dem Compiler explizit sagen muß, was für ein Typ da auftritt. Wer in der Lage ist (oder sogar gezwungen wird), das Ergebnis von "Gewicht*Strecke/Zeit/Zeit" in eine Kraft umzucasten, nur weil der Compiler nicht selbst erkennt, womit er rechnet, wird genauso schnell anfangen, beliebige Rechenergebnisse in beliebige Einheiten zu konvertieren - und schon ist dein Typsystem im Eimer.
Xin schrieb:
Er kann nun entweder etwas passendes definieren, oder muss die Verantwortung dafür übernehmen, eine typlose Information zu klassifizieren.
Shade Of Mine schrieb:
Kommen wir auf die einfachere Syntax zurück:
Ich kann jederzeit ein Kraft Objekt erstellen indem ich:Kraft k(g.asInt() * s.asInt() / z.asInt());schreibe.
Richtig, kannst Du. Das ist eine andere Möglichkeit. Es spricht nichts dagegen - aber in meinen Augen auch nichts dafür im Vergleich zu einer (theoretisch möglichen) Ableitung.
Shade Of Mine schrieb:
Dadurch erreiche ich eine Typsicherheit ohne einbussen der Funktionalität auf kosten einer (unter Umständen) komplizierteren Syntax.
Falsch. Du erreichst nicht mehr Typsicherheit, der einzige Unterschied ist, dass Du bei jeder Variable "asInt()" dahinter schreiben musst. Du erhältst also wieder ein typloses int.
In meinem Fall wird - sofern nicht typsicher gerechnet werden kann - mit ints gerechnet und Du erhältst ebenfalls ein typloses int.
In beiden Fällen kannst Du das typlose int nicht zuweisen. Du gewinnst also mit asInt keinen Vorteil.Da lobe ich mir doch die (oben erwähnte) Template-Variante - ich kann "Kraft k = g*s/(t*t);" schreiben und der Compiler wird mich darauf aufmerksam machen, wenn ich irgendwo in dieser Rechnung eine Einheit durcheinandergeworfen habe. Keine Probleme mit impliziten oder expliziten Umwandlungen nach int in Sichtweite.
Xin schrieb:
Shade Of Mine schrieb:
Denn um mehr geht es nicht - es geht nach wie vor nur um Syntax. Und ich denke nicht dass Syntax es wert ist dafür potentielle Fehler einzubauen. Allein der 1. Ansatz deiner WinFlags war voller Fehler. Keiner dieser Fehler wäre bei Komposition aufgetreten. Und technisch wären beide gleichwertig - lediglich Sicherheit <-> Syntax.
Ich weiß nicht, von welchen Fehlern Du sprichst. Was ich beschrieb, funktioniert problemlos und korrekt - auch unter Mehrfachvererbung, sobald Du die Operatoren in den Namensraum der Klasse holst.
Falls du es noch nicht bemerkt hast, wir sprechen hier nicht von Fehlern im Sinne von "syntaktisch falsch", sondern von Fehlern im Design - aber die hast du ja bisher erfolgreich ignoriert.
-
Shade Of Mine schrieb:
Xin schrieb:
Das rettet die Welt?
Es ist auf jedenfall schon mal klarer.
Wenn Dich das überzeugt... mir soll's recht sein. Wenn Socket und Window Gemeinsamkeiten haben, dann soll mir das recht sein - dann interessiert mich auch nicht, um welche es sich handelt, wenn ich einen Socket anhand eines Fensters konstruiere. Sollte es mich doch interessieren, hätte ich das entsprechend ausgedrückt.
Socket s( Flags( w ) );
Shade Of Mine schrieb:
Aber das lustige ist: du verteidigst immer noch nur die Nachteile - aber Vorteile nennst du immer noch keine.
Ich verteidige keine Nachteile, ich verteidige eine legitime Möglichkeit davor kaputtgeredet zu werden.
Spaßig empfinde ich das aber auch nicht mehr.Shade Of Mine schrieb:
Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Problem ist aber:
Kraft k = gewicht * hoehe;Das wird ziemlich sicher klappen, da du eine Konvertierung von int zu Kraft haben willst - richtig?
Ich rede bei euch beiden echt gegen eine Wand, hmm? Ich schreibe die ganze Zeit, dass genau derartiger Unsinn nicht klappt. Zum einen direkt, zum anderen frage ich mich, ob Dir "expliziter Konstruktor" etwas sagt? Ich habe es (hoffentlich) oft genug geschrieben, auf jeden Fall mehr als einmal und das nicht grundlos.
Shade Of Mine schrieb:
Aber genau das ist das Problem - convenience ist nicht immer das beste. Wenn man einfach gewicht*hoehe verbietet, gibt es da keine Probleme. Und wenn ich in die seltene Situation komme wo ich das brauche, gibt es immer noch ein
Kraft k = gewicht.asInt() * hoehe.asInt();Sorry, aber wenn soetwas erlaubt wäre, brauche ich mir nicht die Mühe zu machen, irgendetwas zu benennen, dann kann ich auch gleich nur mit Intergern oder Floats rechnen.
Was Du da schreibst, ist eigentlich die totale Katastrophe. Du verwendest hier einen impliziten Konstruktor, um aus ints Kraft zu machen. Typsicherheit komplett ade. Dazu das Ablegen der Typen von gewicht und hoehe, in dem Du als Ints zurückgeben lässt. Für das, was hier steht, hättest Du direkt Integers nehmen können, denn die Typsicherheit ist hier vollkommen ausgehöhlt.
CStoll schrieb:
Xin schrieb:
if (window & WindowFlags::UseFullscreen) // schlecht if (window.isFullscreen()) // besserVom Prinzip her habe ich da kein Problem mit, es lässt sich auch problemlos in eine Klasse WindowFlags einbrinen.
Was mir hier fehlt sind zusammenhängende Abfragen:if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )
Und da sind wir wieder bei der semantischen Frage: Was bedeutet diese Abfrage? "Das Fenster hat beide Flags"? Oder doch "Das Fenster hat mindestens eins der Flags"? (Mit der für int üblichen Bedeutung, die du bisher als Rechengrundlage genommen hast, ist es letzteres)
Stimmt, für einen exakten Abgleich musst Du musst den Vergleich auf die Flags ziehen. Mea maxima culpa, dass ich einem Forumsbeitrag in einem kleinen Textarea nicht die Aufmerksamkeit widmen kann, wie einem Programm.
CStoll schrieb:
Und wo steht in deiner Prioritätenliste die Typsicherheit? Soweit ich das überblicke, sehr weit unten.
CStoll, was soll der Müll? Der Thread wird aus x Seiten geführt, weil Typsicherheit weit oben steht, also was soll diese unsinnige Behauptung!?
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ja, solange man mit Einheiten rechnet und nicht nur mit aufbereiteten int's - indem du alle Einheiten von int ableitest, pulverisierst du dir deine heißgeliebte Typsicherheit wieder (Beispiel: Du hast eine Einheit Kraft und Weg - das Produkt davon wäre eigentlich eine Leistung, aber nun bekommst du plötzlich eine reine Zahl heraus, weil Leistung nicht in deiner Einheitensammlung erwähnt wird).
Und wo ist ads Problem!?
Der Compiler sichert mir keinen Typ zu, das tut er sonst auch nicht, also kein Verlust an Information und ich kann weiterarbeiten, in dem ich die Typsicherung notfalls selbst zusichern muss.
Bei allen bekannten Operatoren, kann er mir einen Typen zusichern, also ein Gewinn an Information.CStoll schrieb:
btw, außerdem brauchst du praktisch unendlich viele Einheitenkombinationen, um alle möglichen Multiplikationen darstellen zu können - mit der bereits angerissenen Template-Klasse Measure<...> hast du die alle auf einen Haufen.
Du musst sie trotzdem aufführen.
CStoll schrieb:
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Abgesehen davon, dass Du mir erzählst, dass ich keine Typsicherheit favorisiere, hast Du in der Richtung nichts gemacht. Also erzähl mir etwas von "nutzlos".
CStoll schrieb:
Xin schrieb:
Tellerrand schrieb:
Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?Wozu? Damit Du weißt, dass ein Meter plus ein Meter wieder ein Meter ergibt. Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.
Ja, das ist ein Mehrwert, der die Klasse rechtfertigt. Aber die implizite Behandlung des Meters als reinen int, die du durch deine (ich weiß: hypothetische) Ableitung nachgeworfen bekommst, rechtfertigst du damit noch lange nicht. Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Du hast selbst eine Möglichkeit angerissen, dass für grundlegende Operationen wie m*m=m² zu automatisieren...
Du lieferst die Lösung und beschwerst Dich, dass es ein Problem wäre?CStoll schrieb:
Xin schrieb:
Woher soll ich wissen, wem Meter + Gewicht hilft? Ich kann garantieren, dass ein class Meter + ein class Meter wieder ein class Meter ergibt. Wie soll ich garantieren, dass Meter + Gewicht grundsätzlich sinnlos ist? Wenn ich das nicht garantieren kann, wie soll ich dann eine Einschränkung begründen?
Kannst du begründen, daß diese Addition irgendeinen Sinn ergibt? Wenn nein, warum willst du sie dann erlauben?
Weil ich nicht garantieren kann, dass sie keinen Sinn ergibt.
CStoll schrieb:
Ja, solche Formeln sind auch der Alptraum für jeden Physiker - und vermutlich auch nicht der richtige Einsatzort für ein typisiertes Einheitensystem. Und aus physikalischer Sicht würde ich die Formel eher als "Groesse/1cm == Gewicht/1kg + 100" schreiben.
Sehe ich ähnlich, aber ich sehe mich nicht im Recht, andere Entwickler einzuschränken, nur weil ich eine persönliche Auffassung über das Thema habe. Um das deutlicher zu machen. Ich (meine subjektive Meinung) stimme Dir zu, dass derartige Rechnungen voll daneben sind. Ich bin aber noch mehr überzeugt, dass ich etwas zu definieren habe, was einen Mehrgewinn an Informationen ergibt (bestimmte Operationen ergeben entsprechende Datentypen), aber einen Entwickler nichts zu verbieten habe. Er darf rechnen wie immer - und er bekommt das Ergebnis wie erwartet: eine typlose Zahl, deren Klassifizierung er selbst zu verantworten hat.
CStoll schrieb:
Xin schrieb:
Ich sehe mich nicht in der Lage alle mathematischen und physikalischen Formen, die existieren und in Zukunftexistieren werden, in meinen Klassen abzubilden. Deswegen darf ich aber nicht die Kreativität der Entwickler enschränken.
Und darum gibt es Templates - mit denen können alle Einheiten und -kombinationen des SI-Systems mit einem Schlag erfasst werden.
(aber gib's zu, du hast dir den Ansatz noch nicht einmal angesehen)Doch habe ich, ich sehe nur "alle Einheiten und -Kombinationen des SI-Systems mit einem Schlag erfasst werden", als etwas optimistisch an. Fehlt eins, eine Relation, die vielleicht so noch gar nicht so bewußt ist, bekommt der Entwickler erstmal ein No-Go.
Weiterhin sind die SI-Einheiten nur vier von tausenden Einheiten. Schrauben mit der Einheit Schrauben gemessen, Butterbrote in der Einheit Butterbrot. Möchte ich wissen, wieviele Teile in meiner Werkzeugkiste sind, kann ich das nicht einfach durchzählen und erhalte typsicher x Objekte (eben ein int) heraus.Ich werde nicht verbieten unterschiedliche Einheiten zu addieren - ich werde lediglich keinen Typ dazu verkünden.
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Dann solltest du dafür sorgen, daß der Compiler dein Einheitensystem versteht. Wenn ich gezwungen bin, die (typlosen) Rechenergebnisse von Hand in den richtigen Typ zu quetschen, bleibt von deiner Typsicherheit nicht mehr viel übrig.
Wenn ich den Programmierer nicht mehr an die Tastatur lassen darf, um Entscheidungen zu treffen, dann brauche ich auch keine Typsicherheit. Wenn niemand die Entscheidung treffen kann, was damit gemacht wird, dann wird es auch keine Software mehr geben.
CStoll schrieb:
Xin schrieb:
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Hast du schonmal daran gedacht, daß int zu viele Operatoren zur Verfügung stellt, um es als Ausgangsbasis für ein typsicheres Einheitensystem dienen zu können? Wenn ich sowas entwerfe, beginne ich lieber bei einer leeren Klasse und definiere mir genau die Operationen, die ich als nötig ansehe. Dann muß ich mir keinen Kopf darüber machen, welche geerbten Operatoren Sinn machen - bzw. wie ich ihr Ergebnis interpretieren soll.
Es stehen die gleichen Operatoren zur Verfügung wie jetzt auch. Ich schränke nicht ein, ich liefere Zusatzinformationen.
Wenn Du es programmierst, darfst Du alles so reglementieren, wie Du es für richtig hältst.CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Nur ist es immer schlecht, wenn der Entwickler dem Compiler explizit sagen muß, was für ein Typ da auftritt. Wer in der Lage ist (oder sogar gezwungen wird), das Ergebnis von "Gewicht*Strecke/Zeit/Zeit" in eine Kraft umzucasten, nur weil der Compiler nicht selbst erkennt, womit er rechnet, wird genauso schnell anfangen, beliebige Rechenergebnisse in beliebige Einheiten zu konvertieren - und schon ist dein Typsystem im Eimer.
Du entschuldigst, dass ich Dich auslache?
Programmierung funktioniert in Ermangelung eines Typsystems zur Zeit genauso, falls es Dir noch nicht aufgefallen ist. Integers stehen für alles, ohne einen Typ zu haben und man kann damit machen, was man will. Addiert man Kraft und Gewicht, erhält men die gleichen Typen raus, die man reingesteckt hat => legale Operation, ohne den Hinweis, dass man grade vermutlich etwas sehr blödes gemacht hat.
Ich zeige durch das Fehlen des Datentyps, dass hier grade etwas passiert, worüber man mal nachdenken soll.Was ist die Antwort? Es ist nicht typsicher, weil es auch typlose Größen zuläßt.
Genau... lassen wir alles typlos, dann ist alles viel besser.
CStoll schrieb:
Da lobe ich mir doch die (oben erwähnte) Template-Variante - ich kann "Kraft k = g*s/(t*t);" schreiben und der Compiler wird mich darauf aufmerksam machen, wenn ich irgendwo in dieser Rechnung eine Einheit durcheinandergeworfen habe. Keine Probleme mit impliziten oder expliziten Umwandlungen nach int in Sichtweite.
Mein Held. Dann setz das mal um.
CStoll schrieb:
Falls du es noch nicht bemerkt hast, wir sprechen hier nicht von Fehlern im Sinne von "syntaktisch falsch", sondern von Fehlern im Design - aber die hast du ja bisher erfolgreich ignoriert.
Genau, ich ignoriere euch grundsätzlich, solange ich nicht zustimme und die einzigen, die das Recht haben über Design und Designfehler zu urteilen, seid Ihr, werter CStoll, der als Moderator selbstverständlich für die ganze Welt der C++-Programmierer spricht.
Die Tatsache, dass wir unterschiedliche Ansichten auf einen Sourcecode haben, macht aus mir keinen schlechten Menschen, es ist also nicht notwendig, mir vorzuwerfen, dass ich Dich oder Deine Templates ignoriere.
Selbiges könnte ich von Dir behaupten, schließlich schreibe ich auch nicht zum ersten mal, dass es einen Zugewinn von Typ-Information gibt und nur bei unbekannten Operationen die Größe genauso typlos rauskommt, wie zur Zeit mit Größen gerechnet wird. Guckt man sich noch dazu an, was Shade da konstruiert hat, um aufzuzeigen, wie schlecht mein Herangehen ist, dann stelle ich mir die Frage, warum ich eurem Vorwurf nicht entspreche.Ich kann nur Informationen gewinnen, egal wie schlecht ihr das redet, es ist besser als das was im Alltag verwendet wird und das ist der Punkt, den nicht ich ignoriere...
-
Xin schrieb:
Shade Of Mine schrieb:
Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Problem ist aber:
Kraft k = gewicht * hoehe;Das wird ziemlich sicher klappen, da du eine Konvertierung von int zu Kraft haben willst - richtig?
Ich rede bei euch beiden echt gegen eine Wand, hmm? Ich schreibe die ganze Zeit, dass genau derartiger Unsinn nicht klappt. Zum einen direkt, zum anderen frage ich mich, ob Dir "expliziter Konstruktor" etwas sagt? Ich habe es (hoffentlich) oft genug geschrieben, auf jeden Fall mehr als einmal und das nicht grundlos.
Typsicherheit bedeutet bei mir im optimalen Fall, daß physikalisch korrekte Zuweisungen wie "geschwindigkeit = distanz / zeit;" anstandslos geschluckt werden und unsinnige wie "kraft = laenge * breite;" schon am Compiler hängen bleiben - mit deinem Design kannst du entweder alle zulassen oder alle verbieten (oder du schreibst einige Dutzend Überladungen für die (in deinen Augen) wichtigsten Operandenkombinationen.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
if (window & WindowFlags::UseFullscreen) // schlecht if (window.isFullscreen()) // besserVom Prinzip her habe ich da kein Problem mit, es lässt sich auch problemlos in eine Klasse WindowFlags einbrinen.
Was mir hier fehlt sind zusammenhängende Abfragen:if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )
Und da sind wir wieder bei der semantischen Frage: Was bedeutet diese Abfrage? "Das Fenster hat beide Flags"? Oder doch "Das Fenster hat mindestens eins der Flags"? (Mit der für int üblichen Bedeutung, die du bisher als Rechengrundlage genommen hast, ist es letzteres)
Stimmt, für einen exakten Abgleich musst Du musst den Vergleich auf die Flags ziehen. Mea maxima culpa, dass ich einem Forumsbeitrag in einem kleinen Textarea nicht die Aufmerksamkeit widmen kann, wie einem Programm.
Du bist schon wieder auf die Flags zurückgekommen, also beschwer dich bitte nicht.
Xin schrieb:
CStoll schrieb:
Und wo steht in deiner Prioritätenliste die Typsicherheit? Soweit ich das überblicke, sehr weit unten.
CStoll, was soll der Müll? Der Thread wird aus x Seiten geführt, weil Typsicherheit weit oben steht, also was soll diese unsinnige Behauptung!?
Dann haben wir wohl ein anderes Verständnis von Typ-Sicherheit. Wäre nett zu erfahren, was du darunter verstehst.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ja, solange man mit Einheiten rechnet und nicht nur mit aufbereiteten int's - indem du alle Einheiten von int ableitest, pulverisierst du dir deine heißgeliebte Typsicherheit wieder (Beispiel: Du hast eine Einheit Kraft und Weg - das Produkt davon wäre eigentlich eine Leistung, aber nun bekommst du plötzlich eine reine Zahl heraus, weil Leistung nicht in deiner Einheitensammlung erwähnt wird).
Und wo ist ads Problem!?
Der Compiler sichert mir keinen Typ zu, das tut er sonst auch nicht, also kein Verlust an Information und ich kann weiterarbeiten, in dem ich die Typsicherung notfalls selbst zusichern muss.
Bei allen bekannten Operatoren, kann er mir einen Typen zusichern, also ein Gewinn an Information.Um mit der Leistung (sinnvoll) weiterarbeiten zu können, mußt du dem Compiler klar machen, was er da vor sich hat (durch einen Cast) - und da kann er nicht mehr kontrollieren, ob sich hinter der übergebenen Zahl wirklich eine Leistung verbirgt oder nicht doch eine Stromstärke.
Xin schrieb:
CStoll schrieb:
btw, außerdem brauchst du praktisch unendlich viele Einheitenkombinationen, um alle möglichen Multiplikationen darstellen zu können - mit der bereits angerissenen Template-Klasse Measure<...> hast du die alle auf einen Haufen.
Du musst sie trotzdem aufführen.
Ich schreibe das Template genau einmal - die daraus benötigten Spezialisierungen liefert der Compiler dann auf Anforderung.
Xin schrieb:
CStoll schrieb:
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Abgesehen davon, dass Du mir erzählst, dass ich keine Typsicherheit favorisiere, hast Du in der Richtung nichts gemacht. Also erzähl mir etwas von "nutzlos".
OK, ich geb's zu - das Template Measure<> dort oben habe ich nur im Netz entdeckt und dann im Hinterkopf behalten. Aber nichtsdestotrotz sorgt so eine Lösung dafür, daß die Basiseinheiten typsicher miteinander interagieren können.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Tellerrand schrieb:
Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?Wozu? Damit Du weißt, dass ein Meter plus ein Meter wieder ein Meter ergibt. Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.
Ja, das ist ein Mehrwert, der die Klasse rechtfertigt. Aber die implizite Behandlung des Meters als reinen int, die du durch deine (ich weiß: hypothetische) Ableitung nachgeworfen bekommst, rechtfertigst du damit noch lange nicht. Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Du hast selbst eine Möglichkeit angerissen, dass für grundlegende Operationen wie m*m=m² zu automatisieren...
Du lieferst die Lösung und beschwerst Dich, dass es ein Problem wäre?Ja, ich habe eine Lösung - aber ich frage mich (oder besser gesagt dich, da du ja der Experte für solche Fragen zu sein scheinst), inwieweit man diese Lösung noch verbessern könnte, wenn die Klassen von int erben würden.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Ich sehe mich nicht in der Lage alle mathematischen und physikalischen Formen, die existieren und in Zukunftexistieren werden, in meinen Klassen abzubilden. Deswegen darf ich aber nicht die Kreativität der Entwickler enschränken.
Und darum gibt es Templates - mit denen können alle Einheiten und -kombinationen des SI-Systems mit einem Schlag erfasst werden.
(aber gib's zu, du hast dir den Ansatz noch nicht einmal angesehen)Doch habe ich, ich sehe nur "alle Einheiten und -Kombinationen des SI-Systems mit einem Schlag erfasst werden", als etwas optimistisch an. Fehlt eins, eine Relation, die vielleicht so noch gar nicht so bewußt ist, bekommt der Entwickler erstmal ein No-Go.
Weiterhin sind die SI-Einheiten nur vier von tausenden Einheiten.Du weißt hoffentlich, daß ALLE physikalischen Größen aus diesen Grundeinheiten (btw, es sind sieben) abgeleitet werden können.
Xin schrieb:
Schrauben mit der Einheit Schrauben gemessen, Butterbrote in der Einheit Butterbrot. Möchte ich wissen, wieviele Teile in meiner Werkzeugkiste sind, kann ich das nicht einfach durchzählen und erhalte typsicher x Objekte (eben ein int) heraus.
Ich werde nicht verbieten unterschiedliche Einheiten zu addieren - ich werde lediglich keinen Typ dazu verkünden.
Und was für einen physikalischen/technischen/sonstigen Sinn würdest du dahinter sehen, Schrauben und Butterbrote miteinander zu multiplizieren?
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Dann solltest du dafür sorgen, daß der Compiler dein Einheitensystem versteht. Wenn ich gezwungen bin, die (typlosen) Rechenergebnisse von Hand in den richtigen Typ zu quetschen, bleibt von deiner Typsicherheit nicht mehr viel übrig.
Wenn ich den Programmierer nicht mehr an die Tastatur lassen darf, um Entscheidungen zu treffen, dann brauche ich auch keine Typsicherheit. Wenn niemand die Entscheidung treffen kann, was damit gemacht wird, dann wird es auch keine Software mehr geben.
Nochmal langsam: Typsicherheit bedeutet, daß alle relvanten Typ-Informationen erhalten bleiben - jemandem zu sagen "hier hast du ein Ergebnis, aber du mußt schon selber wissen, was es darstellt" ist nicht typsicher.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Hast du schonmal daran gedacht, daß int zu viele Operatoren zur Verfügung stellt, um es als Ausgangsbasis für ein typsicheres Einheitensystem dienen zu können? Wenn ich sowas entwerfe, beginne ich lieber bei einer leeren Klasse und definiere mir genau die Operationen, die ich als nötig ansehe. Dann muß ich mir keinen Kopf darüber machen, welche geerbten Operatoren Sinn machen - bzw. wie ich ihr Ergebnis interpretieren soll.
Es stehen die gleichen Operatoren zur Verfügung wie jetzt auch. Ich schränke nicht ein, ich liefere Zusatzinformationen.
Und was nützen diese Zusatzinformationen, wenn sie sich bei der erstbesten Gelegenheit in Rauch auflösen?
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Nur ist es immer schlecht, wenn der Entwickler dem Compiler explizit sagen muß, was für ein Typ da auftritt. Wer in der Lage ist (oder sogar gezwungen wird), das Ergebnis von "Gewicht*Strecke/Zeit/Zeit" in eine Kraft umzucasten, nur weil der Compiler nicht selbst erkennt, womit er rechnet, wird genauso schnell anfangen, beliebige Rechenergebnisse in beliebige Einheiten zu konvertieren - und schon ist dein Typsystem im Eimer.
Du entschuldigst, dass ich Dich auslache?
Programmierung funktioniert in Ermangelung eines Typsystems zur Zeit genauso, falls es Dir noch nicht aufgefallen ist. Integers stehen für alles, ohne einen Typ zu haben und man kann damit machen, was man will. Addiert man Kraft und Gewicht, erhält men die gleichen Typen raus, die man reingesteckt hat => legale Operation, ohne den Hinweis, dass man grade vermutlich etwas sehr blödes gemacht hat.
Ich zeige durch das Fehlen des Datentyps, dass hier grade etwas passiert, worüber man mal nachdenken soll.Und du meinst, durch die Aussage "ich weiß nicht, was für ein Typ das ist" wird dein System in irgendeiner Weise sicherer? Nochmal: Die optimale Lösung ist, daß der Compiler erlaubte Operationen anstandslos zulässt und unsinnige Operationen abblockt.
(btw, wer unbedingt Längen und Gewichte addieren will, kann die Einheiten auch rauskürzen)Xin schrieb:
Was ist die Antwort? Es ist nicht typsicher, weil es auch typlose Größen zuläßt.
Genau... lassen wir alles typlos, dann ist alles viel besser.Nein: Es ist nicht typsicher, weil du bei der Rechnung deine Typ-Informationen in den Müll schmeißt - und der Entwickler anschließend raten kann, was nun für ein Typ vorliegen könnte.
Xin schrieb:
CStoll schrieb:
Da lobe ich mir doch die (oben erwähnte) Template-Variante - ich kann "Kraft k = g*s/(t*t);" schreiben und der Compiler wird mich darauf aufmerksam machen, wenn ich irgendwo in dieser Rechnung eine Einheit durcheinandergeworfen habe. Keine Probleme mit impliziten oder expliziten Umwandlungen nach int in Sichtweite.
Mein Held. Dann setz das mal um.
Wenn ich Zeit habe, gerne. Edit: Bis dahin kannst du dir ja mal das hier zu Gemüte führen.
Xin schrieb:
CStoll schrieb:
Falls du es noch nicht bemerkt hast, wir sprechen hier nicht von Fehlern im Sinne von "syntaktisch falsch", sondern von Fehlern im Design - aber die hast du ja bisher erfolgreich ignoriert.
Genau, ich ignoriere euch grundsätzlich, solange ich nicht zustimme und die einzigen, die das Recht haben über Design und Designfehler zu urteilen, seid Ihr, werter CStoll, der als Moderator selbstverständlich für die ganze Welt der C++-Programmierer spricht.
Nein, ich spreche hier nicht für alle C++ Programmierer. Aber selbst dir sollte nicht entgangen sein, daß du so ziemlich alleine auf weiter Flur stehst.
Xin schrieb:
Selbiges könnte ich von Dir behaupten, schließlich schreibe ich auch nicht zum ersten mal, dass es einen Zugewinn von Typ-Information gibt und nur bei unbekannten Operationen die Größe genauso typlos rauskommt, wie zur Zeit mit Größen gerechnet wird. Guckt man sich noch dazu an, was Shade da konstruiert hat, um aufzuzeigen, wie schlecht mein Herangehen ist, dann stelle ich mir die Frage, warum ich eurem Vorwurf nicht entspreche.
Ich kann nur Informationen gewinnen, egal wie schlecht ihr das redet, es ist besser als das was im Alltag verwendet wird und das ist der Punkt, den nicht ich ignoriere...
OK, dein Ansatz ist (etwas) besser als die Arbeit mit nackten int's - war es das, was du hören wolltest? Aber es ist immer noch meilenweit davon entfernt, wirklich typsicher zu sein (und ein "Zugewinn von Typ-Informationen", der sich beim ersten Anzeichen von Gefahr verflüchtigt, ist imho noch unsicherer als keine Typinformation).
-
CStoll schrieb:
Aber selbst dir sollte nicht entgangen sein, daß du so ziemlich alleine auf weiter Flur stehst.
naja, der eine von euch vertritt hier eine konservative 'scheuklappen-', der andere eine eher progressive sichtweise. dass sich viele an althergebrachtes klammern, ist doch normal, aber trotzdem glaube ich nicht, dass die meisten leser Xin für bekloppt halten.
-
Schön, dass auch Undertaker wieder seiner Hauptbeschäftigung, dem Dummschwätzen, nachkommt.
-
Unreg, der Xin Böses will schrieb:
Schön, dass auch Undertaker wieder seiner Hauptbeschäftigung, dem Dummschwätzen, nachkommt.
du bist doch gar kein unreg
-
Für was soll man jemanden halten, der Ausdrücke wie "Fenster sind Flags" oder "class DeppenWindow" benutzt? Das wäre schon eine Steilvorlage gewesen, diese Diskussion von vornherein abzubügeln, mit einem simplen "mit Leuten, die behaupten, daß Fenster Flags sind, diskutiere ich nicht". Warum CStoll hier immer noch weitermacht (nachdem nun wieder Unterstellungen ohne Ende gekommen sind), ist mir völlig schleierhaft.
Außerdem sagt Xin ja selbst, daß sein Weg eine Alternative ist (und er sagt auch, eine schlechtere). Nix progressiv.
-
Undertaker schrieb:
Unreg, der Xin Böses will schrieb:
Schön, dass auch Undertaker wieder seiner Hauptbeschäftigung, dem Dummschwätzen, nachkommt.
du bist doch gar kein unreg
Oh, ertappt. Ja du hast Recht, ich habe hier einen Account mit etwa 20 Posts, in den ich mich auf Arbeit jetzt aber nicht einloggen will. Außerdem wollte ich Xins Verfolgungswahn mit meinem Nick lächerlich machen.
Trotzdem reicht es, die zwei Threads mit Xin und einen beliebigen Thread mit dir zu kennen, um zu wissen, was für Menschen ihr seid.
-
scrub_ schrieb:
Außerdem sagt Xin ja selbst, daß sein Weg eine Alternative ist (und er sagt auch, eine schlechtere). Nix progressiv.
Xin ist wenigstens einer, der sich eigene gedanken macht, auch wenn dabei nicht unbedingt was gescheites rauskommt, aber allein der versuch ist schon was wert.
viele andere machen das nicht. sie haben das gelernte sehr verinnerlicht, wenden es immer und immer wieder an und können es nur in sehr engen, 'erlaubten' grenzen variieren.Unreg oder nicht Unreg? schrieb:
Trotzdem reicht es, die zwei Threads mit Xin und einen beliebigen Thread mit dir zu kennen, um zu wissen, was für Menschen ihr seid.
wolltest du 'trolle' sagen?
-
Undertaker schrieb:
scrub_ schrieb:
Außerdem sagt Xin ja selbst, daß sein Weg eine Alternative ist (und er sagt auch, eine schlechtere). Nix progressiv.
Xin ist wenigstens einer, der sich eigene gedanken macht, auch wenn dabei nicht unbedingt was gescheites rauskommt, aber allein der versuch ist schon was wert.
Ja, der Versuch wird auch lobenswert anerkannt - nur sollte er auch so weit gehen, zu reagieren, nachdem er auf die Schwächen seiner Lösung hingewiesen wurde (und nein, die Aussage "da sind keine Schwachstellen, das ist so beabsichtigt" ist damit nicht gemeint).
@scrub: Sowas nennt sich wohl "grenzenloser Optimismus"
-
CStoll schrieb:
...nur sollte er auch so weit gehen, zu reagieren, nachdem er auf die Schwächen seiner Lösung hingewiesen wurde (und nein, die Aussage "da sind keine Schwachstellen, das ist so beabsichtigt" ist damit nicht gemeint).
ja? also ich finde Xin macht genügend rückzieher. zudem ist es viel schwieriger, eigene, unausgegorene gedankengänge jemandem darzulegen, der permanent mit 'klassischem' wissen dagegen argumentiert.
-
CStoll schrieb:
@scrub: Sowas nennt sich wohl "grenzenloser Optimismus"
Es zeigt sich erneut, dass Lernresistenz nicht auf die Minderwissenden beschränkt ist.
Xin schrieb:
ja? also ich finde Xin macht genügend rückzieher. zudem ist es viel schwieriger, eigene, unausgegorene gedankengänge jemandem darzulegen, der permanent mit 'klassischem' wissen dagegen argumentiert.
Schütze den armen Xin!
-
CStoll schrieb:
Typsicherheit bedeutet bei mir im optimalen Fall, daß physikalisch korrekte Zuweisungen wie "geschwindigkeit = distanz / zeit;" anstandslos geschluckt werden und unsinnige wie "kraft = laenge * breite;" schon am Compiler hängen bleiben
Das bleibt am Compiler hängen, da Kraft weder mit Quadratmetern, noch mit int zugewiesen werden kann.
=> Typsicher.CStoll schrieb:
Du bist schon wieder auf die Flags zurückgekommen, also beschwer dich bitte nicht.
Falsch, nicht ich war es und der Part ging auch nicht an Dich.
CStoll schrieb:
Dann haben wir wohl ein anderes Verständnis von Typ-Sicherheit. Wäre nett zu erfahren, was du darunter verstehst.
Super... warum darf ich denn hier eine (selbstverständlich perfekte) Beschreibung von Typsicherheit hinlegen? Warum legst Du nicht einfach mal vor? Wäre nett, wenn Du Dich traust Dein Wissen auch mal zum Zerpflücken zu offenbaren.
Ohne den Anspruch zu stellen, eine perfekte Beschreibung zu liefern oder diesen Versuch als garantiert fehlerfrei zu bezeichnen:
Typsicherheit ist für mich dann da, wenn eine Operation nicht auf einen Datentyp zugewiesen werden kann, der nicht seiner Darstellung entspricht.
Beispiel:Meter m, n; Kraft k = m*n; // geht nicht, k entspricht keiner Darstellung von Quadratmeter. Haus * h; Baum * b = h; // geht nicht, b entspricht keiner Darstellung von Haus.Typsicherheit besteht, wenn auf eine übergeordnete Darstellung zugewiesen wird. Hier gehen Informationen verloren, aber es wird dem Zieltyp entsprochen.
Katze * k; Tier * t = k; Meter n, m; Kilogramm kg; int i = m*n; int j = m+kg;Hier wird mit j mit zwei Integern berechnet. Int ist verlangt, also muss operator + int zurückliefern. Für int operator +( int, int ) ist das gegeben und m und kg dürfen als int auf die Basis zugewiesen werden, die Addition ist also legitim und gibt einen korrekten Typ zurück: int vom Typ "Unbekannt".
Das entspricht:
Meter m; Kilogramm k; int i_m = m; // Für Shade meinetwegen auch m.AsInt() int i_k = k; int result = m+k;Typsicherheit besteht auch dann, wenn sie vom Entwickler abgesegnet wird. Sie liegt hier in der Verantwortung des Entwicklers, dem es selbstverständlich auch zusteht, Beliebiges durch Aufforderung als korrekt zu definieren:
Meter m, n; Kraft k = Kraft( m * n ); // Hier wird Kraft auf Kraft zugewiesen.Die Definition, dass m*n als Kraft interpretiert wird, wurde vom Entwickler so angeordnet. Der Entwickler muss immer die Möglichkeit haben, sich über die Vorstellungen des Compilerherstellers hinwegsetzen zu dürfen.
CStoll schrieb:
Xin schrieb:
Der Compiler sichert mir keinen Typ zu, das tut er sonst auch nicht, also kein Verlust an Information und ich kann weiterarbeiten, in dem ich die Typsicherung notfalls selbst zusichern muss.
Bei allen bekannten Operatoren, kann er mir einen Typen zusichern, also ein Gewinn an Information.Um mit der Leistung (sinnvoll) weiterarbeiten zu können, mußt du dem Compiler klar machen, was er da vor sich hat (durch einen Cast) - und da kann er nicht mehr kontrollieren, ob sich hinter der übergebenen Zahl wirklich eine Leistung verbirgt oder nicht doch eine Stromstärke.
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.CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Abgesehen davon, dass Du mir erzählst, dass ich keine Typsicherheit favorisiere, hast Du in der Richtung nichts gemacht. Also erzähl mir etwas von "nutzlos".
OK, ich geb's zu - das Template Measure<> dort oben habe ich nur im Netz entdeckt und dann im Hinterkopf behalten. Aber nichtsdestotrotz sorgt so eine Lösung dafür, daß die Basiseinheiten typsicher miteinander interagieren können.
Spricht ja auch nichts dagegen. Du musst dennoch jedes Gesetz aufschreiben, Du musst garantieren, dass Du keins vergessen hast, Du übergehst das Recht des Entwicklers, selbst zu definieren, was er ausdrücken möchte, Du beschränkst Dich auf "Basiseinheiten".
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Du hast selbst eine Möglichkeit angerissen, dass für grundlegende Operationen wie m*m=m² zu automatisieren...
Du lieferst die Lösung und beschwerst Dich, dass es ein Problem wäre?Ja, ich habe eine Lösung - aber ich frage mich (oder besser gesagt dich, da du ja der Experte für solche Fragen zu sein scheinst), inwieweit man diese Lösung noch verbessern könnte, wenn die Klassen von int erben würden.
Wenn Du Dich dafür interessierst, wie Du etwas verbesserst, solltest Du Fragen stellen, um fragen zu stellen und nicht, um darin derartige Comments unterzubringen.
Du kommst mit Template, wie ohne nicht darum herum, Beziehungen zwischen Einheiten ausführlich zu beschreiben.
CStoll schrieb:
Xin schrieb:
Weiterhin sind die SI-Einheiten nur vier von tausenden Einheiten.
Du weißt hoffentlich, daß ALLE physikalischen Größen aus diesen Grundeinheiten (btw, es sind sieben) abgeleitet werden können.
Yepp, weiß ich. Physik LK... frage mich nur grade, warum ich vier 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.
CStoll schrieb:
Xin schrieb:
Schrauben mit der Einheit Schrauben gemessen, Butterbrote in der Einheit Butterbrot. Möchte ich wissen, wieviele Teile in meiner Werkzeugkiste sind, kann ich das nicht einfach durchzählen und erhalte typsicher x Objekte (eben ein int) heraus.
Ich werde nicht verbieten unterschiedliche Einheiten zu addieren - ich werde lediglich keinen Typ dazu verkünden.
Und was für einen physikalischen/technischen/sonstigen Sinn würdest du dahinter sehen, Schrauben und Butterbrote miteinander zu multiplizieren?
Wie schon gesagt - es ist nicht mein Recht, die Ideen eines anderen Entwicklers zu beschneiden.
Ich kann ihm lediglich den Hinweis geben, dass ich für Schrauben * Butterbrote keine Einheit parat habe und er entsprechend überlegen muss, was er mit dem Ergebnis anfangen soll.Wenn er wissen will, wieviel 5 Schrauben mal 8 Butterbrote sind, kann ich ihm sagen, was 5*8 sind. Es kommt 40 raus. Ob er jetzt pro Butterbrot 5 Schrauben braucht, also insgesammt 40 Schrauben oder pro Schraube 8 Butterbrote, also 40 Butterbrote - das muss er mir dann explizit sagen. Ich akzeptiere das Ergebnis jedenfalls ohne Klarstellung des Programmierers weder als Butterbrote, noch als Schrauben.
CStoll schrieb:
Nochmal langsam: Typsicherheit bedeutet, daß alle relvanten Typ-Informationen erhalten bleiben - jemandem zu sagen "hier hast du ein Ergebnis, aber du mußt schon selber wissen, was es darstellt" ist nicht typsicher.
Doch, ich sage ihm damit, welcher Typ das meiner Auffassung nicht ist. Wenn der Programmierer das anders sieht, muss er mir das mitteilen und das ist sein gutes Recht, schließlich entwickelt der Programmierer das Programm.
CStoll schrieb:
Und was nützen diese Zusatzinformationen, wenn sie sich bei der erstbesten Gelegenheit in Rauch auflösen?
Du hast eine pessimistische Sicht der Dinge. Ich muss bei 5 Schrauben * 8 Butterbrote mit klar ausdrücken, was ich damit meine, das kann ein Compiler nicht wissen. Die üblichen Dinge, sind doch geklärt.
CStoll schrieb:
Und du meinst, durch die Aussage "ich weiß nicht, was für ein Typ das ist" wird dein System in irgendeiner Weise sicherer?
Yepp. Die Information wirst Du an den Stellen bekomme, wo Du besonders gut nachdenken musst. Eine Typ-Konvertierung kennzeichnet damit immer einen Punkt, der besonderer Beachtung bedarf.
CStoll schrieb:
Nochmal: Die optimale Lösung ist, daß der Compiler erlaubte Operationen anstandslos zulässt und unsinnige Operationen abblockt.
Wieso bin ich hier eigentlich der Experte, wenn Du hier eine Behauptung aufstellst, was optimal zu sein hat.
Offenbar hast Du den totalen Überblick, was unsinnig ist und was nicht.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?
CStoll schrieb:
Xin schrieb:
Mein Held. Dann setz das mal um.
Wenn ich Zeit habe, gerne. Edit: Bis dahin kannst du dir ja mal das hier zu Gemüte führen.
Wie gesagt... Physik LK. Würde ich Einheiten nicht schätzen, hätte ich sie nicht als Beispiel hier verwandt.
Wir sind hier aber nicht in der Physik, sondern in der Informatik. Und Informatik bedeutet einer typlosen Rechenmaschine typlose Zahlen korrekt zu verarbeiten beizubringen.
Informatik ist ein Zwischending zwischen Mathematik/Physik und Handwerk. Wir arbeiten mit formellen Einheiten und manchmal auch mit dem Vorschlagshammer. Ich bin für absolut jede formal korrekte Ausdrucksmöglichkeit sehr dankbar, werde auch mit Begeisterung jede benutzen.
Aber wenn Du hier Anstalten machst, mir meinen Vorschlagshammer abzunehmen, dann kannst Du Dich mit Deinen Klassen sonstwohin verziehen.CStoll schrieb:
Nein, ich spreche hier nicht für alle C++ Programmierer. Aber selbst dir sollte nicht entgangen sein, daß du so ziemlich alleine auf weiter Flur stehst.
Ich stehe häufig alleine auf weiter Flur, das höre ich jetzt schon so oft... bei dem OOP Thread stand ich noch alleine auf weiter Flur, als minhen schon die komplette Argumentation übernommen hat, die identisch mit meiner war.
Nur weil ich jemanden oder allen im Weg stehe, sehe ich keinen Grund mich zu bewegen.Das hatte ich mal bei meinen Dekan. Da war ich auch immer der einzige, der sich beschwert hat. Da ich wußte, dass ich recht habe und definitiv auch nicht der einzige war, habe ich ein öffentliches Forum eröffnet, Informationszettel in der FH aufgehängt und Studenten eingeladen.
Es war eine interessante Erfahrung, dass auf einmal Professoren mir heimlich Tipps gaben, um das Forum betreiben zu können und rechtliche Gefahren zu minimieren oder andere Profs an mir vorrüber gingen und im Vorbeigehen mir "Finde ich gut, Herr Atrops" als Begrüßung zuriefen, weil die Hochschule bezogen auf das Forum allen Profs den Maulkorb verpasst hatte.
Auf einmal stand ich allein auf weiter Flur vor einer Reihe Studenden, die sich ebenfalls beschwerten und einer Reihe von Profs, die sich nicht offen zeigen durften.
Viele, sich öffentlich beschwerende Studenten sorgen für schlechte Presse.Ich habe überhaupt kein Problem damit, alleine auf weiter Flur zu stehen und ich gehe auch niemandem aus dem Weg, solange ich von meinem Standpunkt überzeugt bin.
Somit war ich immernoch derjenige, der alleine (mit seinem Mit-Forums-Admin) auf weiter Flur stand und dem vom Dekan eine "50000 Euro Unterlassungsklage" und die Exmatrikulation wegen Rufschädigung angedroht wurden, wenn ich das Forum nicht sofort schließe. Der Rest der Studenten wurde schließlich nicht verklagt und würde mir auch nicht helfen.
50000 Euro ließen mich dann aber doch mal überlegen. Etwa 2-3 Sekunden, um die Konsequenzen abzuschätzen. Möglicherweise ein Verfahren, Schulden, Exmatrikulation oder einfach die Klappe halten und meinen Standpunkt aufgeben. Ich halte meinen Standpunkt für richtig. Alternativ volles Programm: Anwalt suchen, Verfahren laufen lassen, Öffentlichkeitsarbeit anleiern und sich verklagen lassen und meiner Hochschule weiterhin im Weg stehen.
Also sagte ich meinem Mitadmin, dass er auf Wunsch aus der Sache raus ist und dem Dekan, dass ich Rechtsberatung zu dem Forum habe und ich es darauf ankommen lasse.Ich habe das Forum nicht geschlossen.
Ich wurde nicht verklagt. Ich wurde nicht exmatrikuliert. Der Dekan hat das Forum fortan ignoriert.Direkt ändern konnte ich allerdings leider auch nichts.
Da der Dekan jede Kritik ignorierte, schwand auch das Interesse im Forum Kritik (wie auch Positives!) zu sammeln. Das Forum hat aber wohl zu heftigen Diskussion unter den Professoren geführt. Zwei oder drei Monate nach der Geschichte trat der Dekan zurück. Ich weiß nicht, ob ich etwas damit zu tun habe, aber die zeitliche Nähe war schon interessant, zumal der Dekan vielleicht ein halbes Jahr im Amt war und seine Amtzeit definitiv noch nicht um war.Ich nehme einen Platz in diesem Forum ein und ich bin gerne bereit mich zu bewegen, wenn mir jemand Grund dazu gibt. Ansonsten stehe ich an meinem Standpunkt - ob alleine oder mit anderen - und der einzige, dem ich das Recht zuspreche, mich ohne für mich nachvollziehbaren Grund von meinem Standpunkt in diesem Forum zu vertreiben ist Marcus.
Wenn Du mich bewegen möchtest, liefere mir eine größere Weisheit oder überrede Marcus mich zum Gehen aufzufordern.
Solange Du mich nur alleine auf weiter Flur siehst, zuckt hier nichtmals der kleine Zeh.CStoll schrieb:
OK, dein Ansatz ist (etwas) besser als die Arbeit mit nackten int's - war es das, was du hören wolltest? Aber es ist immer noch meilenweit davon entfernt, wirklich typsicher zu sein (und ein "Zugewinn von Typ-Informationen", der sich beim ersten Anzeichen von Gefahr verflüchtigt, ist imho noch unsicherer als keine Typinformation).
Es gibt Dinge, die kann ein Compiler oder eine Sprache nunmal nicht entscheiden. Und dafür braucht man Programmierer, die für ein Programm die Bahnen vorlegt. Was Du als "verflüchtigen" von Typinformationen bezeichnest, sind genau die Punkte, an denen der Programmierer die Bahnen klar vorgeben muss.
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.
scrub_ schrieb:
Außerdem sagt Xin ja selbst, daß sein Weg eine Alternative ist (und er sagt auch, eine schlechtere). Nix progressiv.
...in C++...
Undertaker schrieb:
Xin ist wenigstens einer, der sich eigene gedanken macht, auch wenn dabei nicht unbedingt was gescheites rauskommt, aber allein der versuch ist schon was wert.
Ja... Danke für das ähh... Kompliment, hehehe
-
Meter n, m; Kilogramm kg; int i = m*n; int j = m+kg;entspricht nicht
Meter m; Kilogramm k; int i_m = m; // Für Shade meinetwegen auch m.AsInt() int i_k = k; int result = m+k;Denn zu Code 1 kann ich:
Hoehe h=m*n;machen.
Bei Beispiel 2 ist das, sofern du mein asInt() nimmst, nicht möglich.
Und genau das ist die Typsicherheit die du beschrieben hast.
Du wirst jetzt argumentieren dass Hoehe keinen non explicit CTor für int hat - damit wird aber das Problem nicht gelöst sondern lediglich verschoben - bis man irgendwann mal einen non explicit CTor für int hat.
Du behauptest dass ein int sowieso immer etwas Typenloses ist - das stimmt ja auch. Aber genau deshalb führt man ja komplexere Typen ein. Indem ich Kraft und Gewicht in eine eigene Klasse stecke gehe ich von reinen integers weg. Ich bekomme dadurch eben eine Typsicherheit die es mir verbietet Breite * Gewicht = Geschwindigkeit zu setzen. Du erlaubst es aber - aber damit verlierst du fast alle Vorteile die Breite, Gewicht und Geschwindigkeit dir zu bieten haben. Du hast nur ein nettes typedef gemacht - nicht mehr.
Aber diese Klassen erstellt man genau deswegen um nichts mehr mit integer zu tun zu haben. Ints sind doof, sie haben keine Einheiten - das hast du ja auch richtig erkannt. Nur fehlt der Schritt das Problem zu lösen. Ints sind Einheitenlos - warum also nicht ihnen Einheiten geben?
Indem man die Konvertierung nicht erlaubt, löst man alle Probleme dieser Welt.
@Undertaker:
Klar ist es nett wenn jemand selber nachdenkt und versucht selber Lösungen zu finden. Aber wie ich schonmal geschrieben habe: die meisten Ideen dieser Welt sind leider komplett unbrauchbar. Jeder Mensch erfindet soviele kreative Lösungen die aber kompletter Mist dass es nicht mehr zählbar ist. Es kommt darauf an die guten Ideen zu erkennen.Das macht die Argumentation gegen die bewährten Lösungen natürlich sehr schwer. Aber im Prinzip, wenn man die Vorteile und die Nachteile aufzählt und Nebeneinander schreibt sollte man erkennen ob ein Ansatz gewinnversprechend ist.
Wir haben hier jetzt fast 16 Seitenlang Probleme aufgezählt und es ging immer nur darum ob ein Problem jetzt als echtes Problem gilt. Vorteile gibt es keine (mit Ausnahme der netteren Syntax). Und das ist, was man sich vor Augen halten sollte.
Vielleicht sollte jemand eine schöne Liste mit den Vor und Nachteilen anlegen. Dann können wir ja weiter sehen.
-
Ok, mal anderst ausgedrückt was mich daran stört.
Meter(3) * Butterbrote(8) * Kilometer(4) * 7 * Milimeter(9)
Butterbrote(8) * 7 * Milimeter(9) * Meter(3) * Kilometer(4)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.
Eigentlich ist dies doch genau der Punkt auf den man deuten will, der Entwickler hat keinen blassen Schimmer wann genau welche Maßeinheiten verrechnet werden und wann man es mit Integer Werten zu tun hat.
Anderst gesagt, wann wird die Standard Multiplikation verwendet und wann existiert da doch eine abweichende Variante ... der Entwickler muss das genau im Auge behalten und wehe da werden Operatoren nachträglich hinzugefügt, das wäre ja ganz fies.Ich finde da andere Variante von CStoll / Schade of Mine bedeutend besser, wenn man schon bei der Programmierung genau weiß, dass durch asInt (oder anderes) die normalen Operatoren verwendet werden. Sehe darin einfach bedeutend weniger Fehlerquellen.
-
Shade Of Mine schrieb:
Du behauptest dass ein int sowieso immer etwas Typenloses ist - das stimmt ja auch. Aber genau deshalb führt man ja komplexere Typen ein. Indem ich Kraft und Gewicht in eine eigene Klasse stecke gehe ich von reinen integers weg. Ich bekomme dadurch eben eine Typsicherheit die es mir verbietet Breite * Gewicht = Geschwindigkeit zu setzen. Du erlaubst es aber - aber damit verlierst du fast alle Vorteile die Breite, Gewicht und Geschwindigkeit dir zu bieten haben. Du hast nur ein nettes typedef gemacht - nicht mehr.
Aber diese Klassen erstellt man genau deswegen um nichts mehr mit integer zu tun zu haben. Ints sind doof, sie haben keine Einheiten - das hast du ja auch richtig erkannt. Nur fehlt der Schritt das Problem zu lösen. Ints sind Einheitenlos - warum also nicht ihnen Einheiten geben?
Indem man die Konvertierung nicht erlaubt, löst man alle Probleme dieser Welt.
Dem ist nichts hinzuzufügen. Es klingt logisch, einleuchtend, und es gibt keine vernünftigen "besseren" Alternativen´, zumindest wurden hier keine dargelegt. Daß nun auch noch die Mehrheit dahintersteht (alle BILD-Leser sozusagen), ist gar nicht weiter von Belang.
-
Shade Of Mine schrieb:
Du wirst jetzt argumentieren dass Hoehe keinen non explicit CTor für int hat - damit wird aber das Problem nicht gelöst sondern lediglich verschoben - bis man irgendwann mal einen non explicit CTor für int hat.
Das ist irgendwo witzlos, findest Du nicht?
Auf einmal kommt da irgendwo ein impliziter Konstruktor vom Himmel gefallen, oder wie darf ich mir das vorstellen?Du willst mir doch nicht damit argumentieren, dass wenn etwas falsch programmiert ist, falsche Ergebnisse entstehen!? Wow. Wie gut, dass das ein Problem ist, dass ausschließlich auf die Entwicklung meiner Klassen zutrifft.
Shade Of Mine schrieb:
Ich bekomme dadurch eben eine Typsicherheit die es mir verbietet Breite * Gewicht = Geschwindigkeit zu setzen. Du erlaubst es aber - aber damit verlierst du fast alle Vorteile die Breite, Gewicht und Geschwindigkeit dir zu bieten haben. Du hast nur ein nettes typedef gemacht - nicht mehr.
Sorry, aber solange Du in die Klassen nachträglich keine Fehler einbaust, sind die typsicher.
Und wenn Du die Klassen nachträglich umschreibst, dann kannst Du Dich nicht hier hinstellen und erzählen, dass meine Klassen nicht funktionieren würden... okay, ich korrigiere, Du kannst, immerhin tust Du es ja.Wenn Scrub das dann ernst nimmt, habe ich damit kein Problem, aber ich hoffe Du verstehst, dass ich es nicht ernstnehmen kann, wenn Du die Typsicherung entfernst und dann feststellst, dass nie Typsicherheit gegeben hätte, denn der explizite Konstruktor verbietet es Geschwindigkeit = Breite * Gewicht zu setzen.
Man verzeihe mir, wenn das arrogant klingt, aber was für ein Argumentationsniveau soll das denn sein!?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.Das muss der Entwickler festlegen, wenn er ein int einem Typ zuweisen möchte.
-
Xin schrieb:
CStoll schrieb:
Typsicherheit bedeutet bei mir im optimalen Fall, daß physikalisch korrekte Zuweisungen wie "geschwindigkeit = distanz / zeit;" anstandslos geschluckt werden und unsinnige wie "kraft = laenge * breite;" schon am Compiler hängen bleiben
Das bleibt am Compiler hängen, da Kraft weder mit Quadratmetern, noch mit int zugewiesen werden kann.
=> Typsicher.Solange du mit einzelnen, differenzierten Maßtypen arbeitest, wird es immer technisch legale Zuweisungen geben, die vom Compiler zurückgewiesen werden, weil du sie nicht bedacht hast. Und für alle möglichen Typkombinationen eine Multiplikation zu erfassen, ist zeitlich nicht machbar (schon bei einer einzigen Grundeinheit hast du abzählbar unendlich viele Potenzen, die du berücksichtigen mußt).
Xin schrieb:
CStoll schrieb:
Dann haben wir wohl ein anderes Verständnis von Typ-Sicherheit. Wäre nett zu erfahren, was du darunter verstehst.
Super... warum darf ich denn hier eine (selbstverständlich perfekte) Beschreibung von Typsicherheit hinlegen? Warum legst Du nicht einfach mal vor? Wäre nett, wenn Du Dich traust Dein Wissen auch mal zum Zerpflücken zu offenbaren.
Ohne den Anspruch zu stellen, eine perfekte Beschreibung zu liefern oder diesen Versuch als garantiert fehlerfrei zu bezeichnen:
Typsicherheit ist für mich dann da, wenn eine Operation nicht auf einen Datentyp zugewiesen werden kann, der nicht seiner Darstellung entspricht.
Beispiel:Meter m, n; Kraft k = m*n; // geht nicht, k entspricht keiner Darstellung von Quadratmeter. Haus * h; Baum * b = h; // geht nicht, b entspricht keiner Darstellung von Haus.Typsicherheit besteht, wenn auf eine übergeordnete Darstellung zugewiesen wird. Hier gehen Informationen verloren, aber es wird dem Zieltyp entsprochen.
Katze * k; Tier * t = k; Meter n, m; Kilogramm kg; int i = m*n; int j = m+kg;Hier wird mit j mit zwei Integern berechnet. Int ist verlangt, also muss operator + int zurückliefern. Für int operator +( int, int ) ist das gegeben und m und kg dürfen als int auf die Basis zugewiesen werden, die Addition ist also legitim und gibt einen korrekten Typ zurück: int vom Typ "Unbekannt".
Das entspricht:
Meter m; Kilogramm k; int i_m = m; // Für Shade meinetwegen auch m.AsInt() int i_k = k; int result = m+k;Typsicherheit besteht auch dann, wenn sie vom Entwickler abgesegnet wird. Sie liegt hier in der Verantwortung des Entwicklers, dem es selbstverständlich auch zusteht, Beliebiges durch Aufforderung als korrekt zu definieren:
Meter m, n; Kraft k = Kraft( m * n ); // Hier wird Kraft auf Kraft zugewiesen.Die Definition, dass m*n als Kraft interpretiert wird, wurde vom Entwickler so angeordnet. Der Entwickler muss immer die Möglichkeit haben, sich über die Vorstellungen des Compilerherstellers hinwegsetzen zu dürfen.
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.
Mal ein Beispiel: Ich will errechnen, wie hoch ich einen Gegenstand mit einer gegebenen Anfangsgeschwindigkeit werfen kann, also bemühe ich die Energieerhaltung:
E_pot + E_kin == const //Reibung vernachlässigen wir E_pot0+E_kin0 == E_pot1+E_kin1 (E_kin=1/2 m v^2, E_pot=m g h - h0=0m,v1=0m/s 1/2*m*v0^2 == m*g*h1 h1 == v*v/(2*g)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.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Der Compiler sichert mir keinen Typ zu, das tut er sonst auch nicht, also kein Verlust an Information und ich kann weiterarbeiten, in dem ich die Typsicherung notfalls selbst zusichern muss.
Bei allen bekannten Operatoren, kann er mir einen Typen zusichern, also ein Gewinn an Information.Um mit der Leistung (sinnvoll) weiterarbeiten zu können, mußt du dem Compiler klar machen, was er da vor sich hat (durch einen Cast) - und da kann er nicht mehr kontrollieren, ob sich hinter der übergebenen Zahl wirklich eine Leistung verbirgt oder nicht doch eine Stromstärke.
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.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Abgesehen davon, dass Du mir erzählst, dass ich keine Typsicherheit favorisiere, hast Du in der Richtung nichts gemacht. Also erzähl mir etwas von "nutzlos".
OK, ich geb's zu - das Template Measure<> dort oben habe ich nur im Netz entdeckt und dann im Hinterkopf behalten. Aber nichtsdestotrotz sorgt so eine Lösung dafür, daß die Basiseinheiten typsicher miteinander interagieren können.
Spricht ja auch nichts dagegen. Du musst dennoch jedes Gesetz aufschreiben, Du musst garantieren, dass Du keins vergessen hast, Du übergehst das Recht des Entwicklers, selbst zu definieren, was er ausdrücken möchte, Du beschränkst Dich auf "Basiseinheiten".
Was für Gesetze muß ich deiner Meinung nach aufschreiben? Daß das Produkt aus zwei Längen eine Fläche ist, geht direkt aus dem Template hervor, wie man die Kapazität eines Kondensators ermittelt, gehört in eine Formelsammlung - aber auch hier sorgt das Template dafür, daß die verwendeten Einheiten passen.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Du hast selbst eine Möglichkeit angerissen, dass für grundlegende Operationen wie m*m=m² zu automatisieren...
Du lieferst die Lösung und beschwerst Dich, dass es ein Problem wäre?Ja, ich habe eine Lösung - aber ich frage mich (oder besser gesagt dich, da du ja der Experte für solche Fragen zu sein scheinst), inwieweit man diese Lösung noch verbessern könnte, wenn die Klassen von int erben würden.
Wenn Du Dich dafür interessierst, wie Du etwas verbesserst, solltest Du Fragen stellen, um fragen zu stellen und nicht, um darin derartige Comments unterzubringen.
Du kommst mit Template, wie ohne nicht darum herum, Beziehungen zwischen Einheiten ausführlich zu beschreiben.
Mit einem Unterschied: Das Template beschreibt mit einem Schlag alle Beziehungen zwischen den Einheiten des Systems - du wählst eine endliche Menge aus und sammelst sie (oder baust ein eigenes Template, um automatisch alle Beziehungen zu ermitteln). Und jetzt erkläre mir bitte den Mehrwert von "Template+Vererbung von int" gegenüber "Template".
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Weiterhin sind die SI-Einheiten nur vier von tausenden Einheiten.
Du weißt hoffentlich, daß ALLE physikalischen Größen aus diesen Grundeinheiten (btw, es sind sieben) abgeleitet werden können.
Yepp, weiß ich. Physik LK... frage mich nur grade, warum ich vier 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". 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?)
Xin schrieb:
CStoll schrieb:
Und du meinst, durch die Aussage "ich weiß nicht, was für ein Typ das ist" wird dein System in irgendeiner Weise sicherer?
Yepp. Die Information wirst Du an den Stellen bekomme, wo Du besonders gut nachdenken musst. Eine Typ-Konvertierung kennzeichnet damit immer einen Punkt, der besonderer Beachtung bedarf.
Soweit stimmt's - aber daraus folgt auch, daß an einer unkritischen Stelle (und die Formel für die Wurfhöhe ist physikalisch unkritisch) keine explizite Typkonvertierung nötig sein sollte.
Xin schrieb:
CStoll schrieb:
Nochmal: Die optimale Lösung ist, daß der Compiler erlaubte Operationen anstandslos zulässt und unsinnige Operationen abblockt.
Wieso bin ich hier eigentlich der Experte, wenn Du hier eine Behauptung aufstellst, was optimal zu sein hat.
Offenbar hast Du den totalen Überblick, was unsinnig ist und was nicht.Ich habe zumindest soweit den Überblick zu wissen, was in meiner Anwendung unsinnig ist. Und wenn ich eine physikalische Formelsammlung aufbaue, ist klar, daß die verwendeten Einheiten zusammenpassen müssen (und ich nicht explizit angeben muß, welche Einheit bei einer Rechnung herauskommen sollte).
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.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Mein Held. Dann setz das mal um.
Wenn ich Zeit habe, gerne. Edit: Bis dahin kannst du dir ja mal das hier zu Gemüte führen.
Wie gesagt... Physik LK. Würde ich Einheiten nicht schätzen, hätte ich sie nicht als Beispiel hier verwandt.
Wir sind hier aber nicht in der Physik, sondern in der Informatik. Und Informatik bedeutet einer typlosen Rechenmaschine typlose Zahlen korrekt zu verarbeiten beizubringen.
Informatik ist ein Zwischending zwischen Mathematik/Physik und Handwerk. Wir arbeiten mit formellen Einheiten und manchmal auch mit dem Vorschlagshammer. Ich bin für absolut jede formal korrekte Ausdrucksmöglichkeit sehr dankbar, werde auch mit Begeisterung jede benutzen.
Aber wenn Du hier Anstalten machst, mir meinen Vorschlagshammer abzunehmen, dann kannst Du Dich mit Deinen Klassen sonstwohin verziehen.Nicht immer ist der Vorschlaghammer das ideale Werkzeug für eine Aufgabe. Und du solltest eventuell daran denken, ihn als letzte Reserve zurückzustellen und öfter zu Werkzeugen greifen, die für dein Problem bestimmt sind.
Xin schrieb:
Ich nehme einen Platz in diesem Forum ein und ich bin gerne bereit mich zu bewegen, wenn mir jemand Grund dazu gibt. Ansonsten stehe ich an meinem Standpunkt - ob alleine oder mit anderen - und der einzige, dem ich das Recht zuspreche, mich ohne für mich nachvollziehbaren Grund von meinem Standpunkt in diesem Forum zu vertreiben ist Marcus.
Wenn Du mich bewegen möchtest, liefere mir eine größere Weisheit oder überrede Marcus mich zum Gehen aufzufordern.
Solange Du mich nur alleine auf weiter Flur siehst, zuckt hier nichtmals der kleine Zeh.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. 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".
Xin schrieb:
CStoll schrieb:
OK, dein Ansatz ist (etwas) besser als die Arbeit mit nackten int's - war es das, was du hören wolltest? Aber es ist immer noch meilenweit davon entfernt, wirklich typsicher zu sein (und ein "Zugewinn von Typ-Informationen", der sich beim ersten Anzeichen von Gefahr verflüchtigt, ist imho noch unsicherer als keine Typinformation).
Es gibt Dinge, die kann ein Compiler oder eine Sprache nunmal nicht entscheiden. Und dafür braucht man Programmierer, die für ein Programm die Bahnen vorlegt. Was Du als "verflüchtigen" von Typinformationen bezeichnest, sind genau die Punkte, an denen der Programmierer die Bahnen klar vorgeben muss.
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.
Xin schrieb:
Shade Of Mine schrieb:
Ich bekomme dadurch eben eine Typsicherheit die es mir verbietet Breite * Gewicht = Geschwindigkeit zu setzen. Du erlaubst es aber - aber damit verlierst du fast alle Vorteile die Breite, Gewicht und Geschwindigkeit dir zu bieten haben. Du hast nur ein nettes typedef gemacht - nicht mehr.
Sorry, aber solange Du in die Klassen nachträglich keine Fehler einbaust, sind die typsicher.
Und wenn Du die Klassen nachträglich umschreibst, dann kannst Du Dich nicht hier hinstellen und erzählen, dass meine Klassen nicht funktionieren würden... okay, ich korrigiere, Du kannst, immerhin tust Du es ja.Wenn Scrub das dann ernst nimmt, habe ich damit kein Problem, aber ich hoffe Du verstehst, dass ich es nicht ernstnehmen kann, wenn Du die Typsicherung entfernst und dann feststellst, dass nie Typsicherheit gegeben hätte, denn der explizite Konstruktor verbietet es Geschwindigkeit = Breite * Gewicht zu setzen.
Der explizite Konstruktor verbietet aber auch, Geschwindigkeit = Distanz / Zeit zu setzen (und selbst wenn du genau für diese Kombination einen Operator überladen hast - du wirst immer irgendwo an einen Punkt stoßen, wo der Compiler auf die Standard-Operatoren zurückgreift, um eine gegebene Formel auswerten zu können).
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).
