Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[CStoll]

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()) // besser

Vom 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).

[Undertaker]

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.

[Unreg, der Xin Böses will]

Schön, dass auch Undertaker wieder seiner Hauptbeschäftigung, dem Dummschwätzen, nachkommt.

[Undertaker]

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

[scrub_]

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.

[Unreg oder nicht Unreg?]

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.

[Undertaker]

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?

[CStoll]

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"

[Undertaker]

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.

[Super Spruch (äh zwei)]

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!

[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

[Shade Of Mine]

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.

[Tellerrand]

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.

[scrub_]

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.

[Xin]

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.

[CStoll]

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).

[Wozu asInt()?]

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

[Tellerrand]

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 Klasse Quadratmeter nahm ich als gegeben an.

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.

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)

Ein anderer Nachteil ist dann noch
Fall A: Meter m = 7 * Meter(2)
Fall B: Meter m = (Holz(2) * Stahl(3)) * Meter(7)
A ist eine alltägliche Rechnung, B ist erstmal Mist.
Ein Integer * EtwasMitMaßeinheit muss nicht immer einen Integer retunieren.
(Eigentlich sollte es das nie)
Da Holz(2) * Stahl(3) aber nun auf einen Integer hinausläuft frage ich mich wie man das alles noch unterscheiden und in geordnete Bahnen lenken kann.

[Xin]

CStoll schrieb:

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).

Gratuliere, Du hast das Problem endlich erkannt.
Du verbietest damit das Weiterrechnen, ich sage dem Entwickler, dass ich nicht weiß, welcher Typ das ist, ergo muss er das klarstellen.

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.

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.

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

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.

CStoll schrieb:

Xin schrieb:

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".

Das Template arbeitet toll für SI-Einheiten.
Und dann war's das auch. Dann kannst Du noch ein Template dazupacken, dass grundlegende Operatoren, wie Addition erzeugt. Und alle anderen Fragen sind erstmal typlos und können dank der Vererbung zumindest brauchbar gerechnet werden.

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.

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?

CStoll schrieb:

Xin schrieb:

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.

Jow... ich behaupte auch nicht, dass hier ein Problem vorliegen würde.

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.

CStoll schrieb:

Xin schrieb:

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.

Tolles Statement, mein Softwaretechnikprof hat gesprochen.
Du brauchst mir keine Ratschläge über die Verwendung meines Werkzeugs zu geben. Ich verwende schon Klassen für Einheiten, wenn auch nicht für die physikalischen Größen. Die funktionieren auch ohne Hammer.
Trotzdem behalte ich ihn.

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.

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.

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.

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.

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.

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()".

Ich habe nie behauptet zaubern zu können, die Vorstellung lief in einem anderen Theater. Nur weil ich die Versprechen anderer nicht einlöse, Versprechen, die ich nie gemacht habe, muss ich Dir kein Zaubertrick zeigen.

Das ist Programmierung. Wo Gefahr ist, kommentierst Du und stellst ein Schild auf.
Wenn du was Tolles sehen willst, geh ins Theater, da wird Dir was schönes vorgespielt.

CStoll schrieb:

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.

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).

Und an dem Punkt steht für den Nutzer der Klassen das Warnschild und für mich der Hinweis, dass hier etwas fehlt und er selbst denken muss.
Was natürlich in keinem Fall passieren kann, wenn ich das tolle Template nehme, dass Du im Internet gefunden hast. ^^

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.

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.

----------------------------------------------

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,

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

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

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 );

Tellerrand schrieb:

Ein anderer Nachteil ist dann noch
Fall A: Meter m = 7 * Meter(2)
Fall B: Meter m = (Holz(2) * Stahl(3)) * Meter(7)
A ist eine alltägliche Rechnung, B ist erstmal Mist.

Sehr gutes Beispiel

Tellerrand schrieb:

Ein Integer * EtwasMitMaßeinheit muss nicht immer einen Integer retunieren.
(Eigentlich sollte es das nie)
Da Holz(2) * Stahl(3) aber nun auf einen Integer hinausläuft frage ich mich wie man das alles noch unterscheiden und in geordnete Bahnen lenken kann.

Das ist ein wunderbares Beispiel für eine Schwachstelle in dieser Vererbung, die zeigt, dass hier etwas in der Hirachie fehlt: die Unterscheidung nicht mehr typisierte Zahl im vergleich zur typlosen Zahl.

class Unit : int { operatoren für Unit geben Unit zurück }
class Meter : Unit { operatoren für Meter geben Meter zurück }
class Holz : Unit { ... }
class Stahl : Unit { ... }

Fall A: Meter m = 7 * Meter( 2 ); // => Meter( 14 ) => zuweisbar
Fall B: Meter m = (Holz(2) * Stahl(3)) * Meter( 7 ); // => ( Unit(6) * Meter( 7 ) ) => Unit( 42 ) ist nicht als Meter darstellbar, der int-Konstruktor ist explizit => nicht zweisbar
Fall C: Ich beabsichtige das wirklich zu rechnen:
int i = (Holz(2) * Stahl(3)) * Meter( 7 ); // Unit(42) ist als int darstellbar => zuweisbar.

Das war mal eine richtig gute und vor allem gut begründete Kritik, die zu einer sinnvollen Verbesserung führt, statt nur dagegen zu sein. Sowas holt den Spaß an der Diskussion zurück

---------------------------------------

Wozu asInt()? schrieb:

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

Wozu eine Operatoren durchführen?

Kraft k;
int x = k;

[Butterbrot]

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.

Es ist doch nicht sinnvoll und entspricht nicht meiner Vorstellung von Typsicherheit, wenn der Programmierer dem Programm an jeder Ecke sagen muss, *was* vorliegt. Ein gutes Programm kann das selber wissen.

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.

Du hast natürlich alle abzählbar vielen Potenzen implementiert.

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.

Volt ist eine Festlegung für einen bestimmten Potentialunterschied. Volt ist keine Anzahl, es ist eine Einheit, 7 Volt sind das siebenfache eines Volts. Das Volt an sich hat nix mit einem Integer zu tun und es mach deshalb auch keinen Sinn, es von Integer erben zu lassen.

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.

Du hast nicht verstanden, was CStoll dir sagen wollte.

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.

Das ist ja wohl ne Frechheit. Selber haust du seit 10 Seiten reihenweise irgendwelche Beleidigungen raus, und jetzt gehst du Cstoll wegen etwas an, was IMHO nicht mal eine Beleidigung ist?!?!

Xin schrieb:

Wozu asInt()? schrieb:

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

Wozu eine Operatoren durchführen?

Kraft k;
int x = k;

Weil es eine Operation IST.