Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[Tellerrand]

Xin schrieb:

Tellerrand schrieb:

Warum ändert man nicht die Grundidee und hat Ruhe?

Ich benutze meine Wert-Klassen erfolgreich und habe Ruhe.
Ich glaube nicht, dass hier viele der hier 'Diskutierenden' Erfahrungen in Typsicherung haben, alleine schon die Diskussion über explizite Konstruktoren lässt mich daran etwas zweifeln.

Ah, zwei Sätze die alles erklären.

Weil du sie erfolgreich nutzt ist an der Idee nichts falsches dran.
Und dann bist du ja noch einer der wenigen die das Ding mit der Typsicherheit verstehen.

Dann ist die Sache jetzt ja auch klar, ... dein Design ist top!

[Xin]

Öhm, ich will nicht stören, wenn ihr den Thread jetzt gegen ein Moderatorklatschen austauschen wollt. Für mich wäre das nur der Beleg des Kindergartens. Also von mir aus, macht ruhig weiter... (Die letzte Aussage war ironisch.)

Shade Of Mine schrieb:

Xin schrieb:

Selbstverständlich kannst Du in Deinen Klassen implizite Konstruktoren benutzen und dennoch meine Klassen verwenden. Meine produktiv eingesetzten Typ-Klassen (Bildschirmkoordinaten usw.) sind so ziemlich die einzigen, die explizite Konstruktoren haben.

Du kannst lediglich meine Klassen nicht ohne explizite Konstruktoren verwenden.

Exakt. Das ist der Punkt. Ich muss meine Klassen mit explicit CTors schreiben wenn ich interopability mit deinem Code will. Wenn ich dein Framework verwende liegt es relativ nahe dass ich das will.

Du musst explizite CTors von meinen Klassen in Deinen Klassen verwenden. Deine Klasse class ShadesKlasse, benötigt aber keinen expliziten Konstruktor.

Shade Of Mine schrieb:

Man muss sich an die Vorgaben des Frameworks halten wenn man will dass der Code gut läuft.

Du musst Dich in der Verwendung meines Frameworks natürlich an die Vorgaben halten, damit es überhaupt läuft.
Ist das jetzt irgendwas besonderes?

Shade Of Mine schrieb:

finix schrieb:

Wo bleibt denn deine Analogie wenn du z.B. die Begriffe Länge, Meter und Fuß betrachten musst?

Genau da, wo Millimeter und Kilometer landen: Eine Einheit, beliebig viele Umrechnungsfunktionen.

Doof nur wenn diese Einheit die man gewählt hat einfach unpassend ist. In Metern zu rechnen wenn ich einen Laser positionieren will ist einfach furchtbar unangenehm. In Millimetern zu rechnen wenn ich ein Gebäude plane ist es ebenfalls - man wird irgendwann auf Rundungsfehler stoßen.

Niemand zwingt Dich Ein- oder Ausgaben in Metern zu machen. Nur intern gibt es genau eine Längen-Einheit.

Shade Of Mine schrieb:

Ich habe Mr.Ns Idee mit dem Einheiten wegkürzen ja schon gezeigt - damit hat man das Problem nicht. Allerdings klappt das mit deinem Ansatz nicht. Denn dein Ansatz verlangt eine Menge Kleinigkeiten die der Programmierer nicht anders machen darf.

Mr.Ns Ansatz bzw. der herkömmliche verlangt nichts vom Programmierer. Er kann wenn er will explizit die Typsicherheit aufgeben indem er einen operator int() schreibt oder aber beliebig viele operationen definieren wie er es für richtig erachtet. und wenn er etwas ungewöhnliches will, kann er jederzeit die typsicherheit explizit mit einem asInt() oder einem Einheiten Kürzen umgehen.

Das ist gutes Design. Wenn jemand etwas falsches macht, kommt ein Compilerfehler. Wenn er es aber trotzdem machen will, hat er die Möglichkeit dazu.

Bei deinem Ansatz darf jeder alles - es gibt keinen Schutz vor Tippfehlern oder ähnlichem. Dazu gibt es noch eine handvoll böse Fallstricke die leicht zu übersehen sind und keiner davon führt zu einem compiler fehler.

Sorry, aber Du hast die Interaktion der Klassen nicht verstanden und offenbar auch keins meiner Posts wirklich gelesen, ansonsten wären diese Behauptungen einfach nicht möglich.
Also die Kurzfassung...

Meter m=Meter(1), n=Meter(2); 
Butterbrot b = Butterbrot(1);
Meter mresult = m + b; // geht nicht, weil m+b ergibt Unit bzw. int und int muss explizit zugewiesen werden: Fehlerfall - unbekannte (inkompatible?) Einheiten
Unit result = m + b; // geht, hat eine Einheit, man weiß nur leider nicht welche: Unit ist Warnschild an den Programmierer. Ausnahmefall.
Meter result = uresult; // geht nicht ohne expliziten int-Konstruktor, weil nicht typsicher. 
int iresult = m + b;  // geht, hat aber keine Einheit mehr - entspricht MrN.asInt().
Meter result = iresult; // geht nicht ohne expliziten int-Konstruktor, weil nicht typsicher.

Meter result = m + n; // Typsichere Zuweisung über impliziten CopyConstructor. Das hier ist der Regelfall.

Shade Of Mine schrieb:

PS: was das Moderatoren Bashing betrifft - es ist In, ich weiss. Aber die Moderatoren hier stellen sich nicht gegen die Community und streiten gegen sie - sondern wir sind ein Teil von ihr. Deshalb wird auch Leuten wie Xin oder TGGC nicht der Mund verboten. Niemand wird hier sagen "Ich bin Moderator als halte die Fresse" - und Posts werden auch nicht dauernd gelöscht nur weil mal jemand etwas energischer geworden ist.

Das wäre dann auch kein Forum, sondern eine Diktatur. Ich kenne TGGC nicht, aber aus einem anderen Posting habe ich nicht das Gefühl, dass der Vergleich schmeichelhaft war.
Ich erwarte von einem Moderator in allen Subforen und allen Foren, dass er sich so verhält, dass das Diskussionen am Boden der Tatsachen hält.

Shade Of Mine schrieb:

Es werden natürlich Fehler gemacht - das bringt das "etwas tun" einfach mit sich. Aber wenn ihr euch andere Foren anseht - was es zB teilweise für Bann-Orgien gibt und man hier bei uns sogar unregistriert posten kann, dann muss ich sagen, dass es auf c++.de richtig gemütlich ist.

Derartige Foren, wie Du sie beschrieben hast, kenne ich nicht. Allerdings ist C++.de auch das größte Forum, in dem ich schreibe. Dass man als Unreg. schreiben darf, halte ich inzwischen für arg grenzwertig.

CStoll schrieb:

Ich unterscheide zumindest Spannungen von Leistungen - du mischst beides bunt durcheinander, wenn es dir in den Kram passt.

Jow... ist gut, CStoll, wenn nichtmals das bei Dir angekommen ist, dann dann bist Du als C++ Moderator beim Thema Kompetenz eine Fehlbesetzung.
Auch das ist keine Beleidigung, sondern die logische Schlussfolgerung daraus, dass seitenlang die Bedeutung des expliziten Konstruktors nicht bei Dir ankommt.

CStoll schrieb:

Ich habe weder die nötige Zeit noch die Kompetenz, um in diesem Board als Moderator wirken zu können.

Wenn Dir die Kompetenz fehlt, dann halt Dich einfach raus, aber poste nicht seitenweise, dass Du gegen Lösungen bist, bei denen Du nichtmals verstanden hast, dass sie Leistung und Spannung sehr wohl trennen.

CStoll schrieb:

Und außerdem bin ich nicht nur Moderator, sondern zufälligerweise auch ein Mensch (und Programmierer) - und als solcher nehme ich mir das Recht, eine eigene Meinung zu einem Thema zu haben und zu vertreten.

Die ich Dir nie abgesprochen habe.

CStoll schrieb:

Btw, wenn du der Meinung bist, ein Moderator darf keine eigene Meinung haben, wie konntest du dann dein Anti-Dekan-Forum betreiben? (ich gehe mal davon aus, daß du dort der Betreiber warst - und damit erst recht auch als Moderator gearbeitet hast)

Soll ich Dir jetzt mehrere Quotes bringen, wo ich sogar darum Bitte, dass Du Kritik äußerst - aber konstruktiv.
Ansonsten war es kein Anti-Dekan Forum, sondern der Versuch Kritik zu sammeln, um Negatives aus dem Weg zu räumen - am Liebsten so, dass man mit dem Dekan an einem Strang zieht. Dass sich der Dekan gegen Dutzende Studenten stellt und kein Interesse an einer Zusammenarbeit signalisiert - sogar offen Desinteresse äußert - und jegliche Kritik, die auch von einem Teil der Professoren gesehen wurde, als Prolemik abtut, konnte ich nicht ahnen. Das war absolut dumm, eine Position, die ein Dekan in meinen Augen nichtmals andeutungsweise einnehmen darf.
Ich vermute, dass ihm diese Ignoranz seinen Dekansstuhl gekostet hat, aber das sind natürlich Interna, an die exakte Information komme ich nicht heran.

CStoll schrieb:

Xin schrieb:

Ich stimme Dir (hier nicht zum ersten Mal) zu, dass ein System, dass keine Typinformationen verliert, besser ist, als meins.
Aber ich habe noch keins. Und Du hast auch keins.
Du hast ein unfertiges Template aus dem Internet für SI-Einheiten, dass aber kein Argument ist, denn (wie bereits gesagt) auch dieses kannst Du mit meinen Klassen verwenden. Du widerlegst Deine "Argumente" mit hundertausenden Klassen also selbst - warum muss ich Dir das alles immer wieder vorkauen? Auch das ist Zeitverwendung.

Mag sein, daß ich kein fertiges System zu bieten habe, aber ich habe einen funktions- und ausbaufähigen Lösungsansatz, der Typinformationen nur auf Anforderung wegschmeißt. Du ergänzt dieses System um die Fähigkeit, Typinformationen implizit zu verlieren, also was hast du dadurch nun gewonnen?
(zumal du selbst eingesehen hast, daß das schlechter ist)

Erstens: Ich verliere EVENTUELL IM AUSNAHMEFALL - nicht grundsätzlich - die Typinformation.
Zweitens: Du hast einen Lösungsansatz, der nicht weiter kommt als ich.
Drittens: Ich habe nicht eingesehen, sondern selbstverständlich ist die perfekte Lösung besser als meine, aber wir haben keine. Wir müssen also damit leben, dass weder Du noch ich, weiter kommen als bis zu dem Punkt, an dem wir beide EVENTUELL IM AUSNAHMEFALL - nicht grundsätzlich - Typinformationen verlieren.
Viertens: Was ich eingesehen habe, war die Trennung WindowFlag und WindowFlags, Du holst Dir Deine Argumentation aus einem vollkommen anderen Bereich, um hier kompetent auszusehen. Verfolgt man Deine "Argumentation", in dem man wirklich jedes Deiner Postings genau liest, ist das ein wildes Rumgehampel um aus allen Ecken irgendwas hervorzukramen, um dagegen zu sein. Und wie hier, gerne aus Bereichen, die überhaupt nichts mit dem Thema zu tun haben.

Deine Formulierung ist regelmäßig so gewählt, als wäre das, was ich habe schlecht. Es ist nicht nur nicht schlecht - es ist das beste, was wir bisher haben. Auch wenn Du nicht verstehst, dass man damit Leistung und Spannung nicht aufeinander zweisen kann.

Du hast - in diesem Zusammenhang geschrieben, dass was ich mache besser ist und dass Du das perfekte System auch nicht bieten kannst. Also wenn Du nichts zu bieten hast, dann akzeptiere doch einfach, dass was ich mache besser ist, als nichts zu machen und rede es dann nicht weiter schlecht oder erkläre mir, dass ich ein sturer oder unintelligenter Mensch bin, nur weil ich Deine Texte ernst genommen und gelesen habe und sie daher für nicht für voll nehmen kann.

CStoll schrieb:

Mein Template kann mir zumindest sagen, daß ich Butterbrote und Häuser nicht durcheinanderwerfen sollte - wenn ich der Meinung bin, es doch tun zu müssen, muß ich ihm das explizit klarmachen.

Jow. Und bei mir darfst Du durcheinanderwerfen, wie Du willst, aber wenn Du das Ergebnis verwenden willst, musst Du ebenfalls explizit werden.
MrN wird vor dem Operator typlos und ich implizit durch den Operator. Was kommt bei beiden als Ergebnis raus? Etwas typloses, dass Du nicht zuweisen kannst, wenn Du keinen expliziten Konstruktor hast. Ich muss dafür lediglich nicht .asInt() schreiben, was mir keine Nachteile bringt.
Wer gegen den expliziten Konstruktor argumentiert, hat hier soeben eine implizite Konstruktion des Zieltyps abgesegnet, die absolut nicht typsicher war.

Du hast nichts im Angebot, was weiter geht, als ich. Und selbiges gilt für MrN.asInt(), denn die Typsicherheit kommt nicht dadurch, dass ints durch asInt() explizit erstellt werden, sondern dass sie nicht implizit zugewiesen werden können.
Ich habe nichts gegen 'asInt()'. Aber es ändert nichts daran, dass der Entwickler die Verantwortung für den Umgang mit den Typen tragen muss. Da spielt es auch einfach keine Rolle, ob ich meter.asInt() oder int(meter) schreibe. Es hat keinen Mehrwert, im Gegenteil, ich besetze zusätzlich und unnötig einen Bezeichner.

CStoll schrieb:

PS: Ich sage übrigens nicht "das ist Unsinn", sondern "das ist Unsinn, weil ..." - aber wenn du nach dem ersten Komma aufhörst, einen Satz zu lesen, kann ich nichts dafür

Leider kam nach dem "Weil" nie viel, in der Regel eine Formulierung mit dem Klang, als wäre was ich tue schlecht, einigen Fachbegriffen, die zusammenhanglos dahergesagt wurden und häufig nichtsmals etwas mit dem eigentlichen Problem zu tun hatten.
Wie in diesem Posting auch mal wieder, wo Du das "Du hast eingesehen" aus vollkommen aus dem Zusammenhang gerissen hast, weil es mit der Thematik hier nichts zu tun hat.

Deine Texte waren keine Argumente, sondern erweckten den Anschein von KnowHow, solange man sie nur überflogen hat. Die Stelle, wo Du auf Spannung != Volt rausvoltest, war zum einen inhaltlich vollständig hohl. Ohne Jesters Meldung, wäre ich nie drauf gekommen, dass Du derartiges ausdrücken wolltest und weiterhin vollkommen uninteressant zum Thema Typsicherheit.
Selbst mit Jesters Meldung konnte ich das nicht daraus lesen und ob Du das nun ausdrücken wolltest, weiß ich immernoch nicht, denn Du hast Dich dazu nach "Du kapierst es nicht" nicht mehr geäußert.
Ich kapiere wirklich nicht, dass der Unterschied zwischen A und B der ist, dass x ein A ist und y ein A.
Das klingt mit physikalischen Begriffen unheimlich kompetent, aber es bleibt heiße Luft.
Deine Texte hier waren Geblubber ohne fachlichen Inhalt. Und nun erklärst Du, dass ich Watt und Volt nicht auseinanderhalten könne, was zeigt, dass Du - der sich seit 20 Seiten hier mit dem Thema auseinander setzt - absolut keinen Schimmer hast, worüber hier gesprochen wurde.

Ich kann Dich nicht beleidigen. Selbst wenn ich es wollte, so ist die Beschreibung dessen, was Du hier getextet hast, eine Tatsache, die mir an Deiner Stelle auch nicht gefallen würde, aber es ist keine Beleidigung. Der einzige, der Dich hier beleidigt hat, bist Du. Du präsentierst Texte und möchtest ernstgenommen werden und wenn die Texte dann auf das Problem angewandt werden und Dir die Konsequenz Deiner Texte nicht gefällt, dann hättest Du Dir mehr Gedanken machen sollen, bevor Du sie abgeschickt hast.

Ich habe einen Vorteil: Ich habe eine ähnliche (!=identische) Lösung im produktiven Einsatz und weiß daher, dass der explizite Konstruktor den Schlüssel zur Typsicherheit darstellt. Irgendwas wird sich der Stroustrup und das Komitee wohl dabei gedacht haben, als sie das Schlüsselwort abgesegnet haben. Was zusätzliche Schlüsselwörter angeht, sind die ja eher zurückhaltend.
Du warst halt "nur" dagegen und mehr kam nicht. Und als Moderator - besonders als C++-Moderator - erwarte ich von Dir hier die Kompetenz, zu erkennen, dass Du nunmal kein besseres Werkzeug in der Hand hast. Auch im Interesse daran, die Diskussion wertfrei und auf dem Boden zu halten, denn das ist die Kompetenz, die Du als Moderator in allen Subforen dieses und aller anderen Foren zu beweisen hast.

Wenn Du in C++ etwas besseres findest, was universell einsetzbar ist, dann lass es mich wissen. Du wirst mit einer guten Lösung niemanden besser überzeugen können als mich.

[CStoll]

Xin schrieb:

Shade Of Mine schrieb:

Ich habe Mr.Ns Idee mit dem Einheiten wegkürzen ja schon gezeigt - damit hat man das Problem nicht. Allerdings klappt das mit deinem Ansatz nicht. Denn dein Ansatz verlangt eine Menge Kleinigkeiten die der Programmierer nicht anders machen darf.

Mr.Ns Ansatz bzw. der herkömmliche verlangt nichts vom Programmierer. Er kann wenn er will explizit die Typsicherheit aufgeben indem er einen operator int() schreibt oder aber beliebig viele operationen definieren wie er es für richtig erachtet. und wenn er etwas ungewöhnliches will, kann er jederzeit die typsicherheit explizit mit einem asInt() oder einem Einheiten Kürzen umgehen.

Das ist gutes Design. Wenn jemand etwas falsches macht, kommt ein Compilerfehler. Wenn er es aber trotzdem machen will, hat er die Möglichkeit dazu.

Bei deinem Ansatz darf jeder alles - es gibt keinen Schutz vor Tippfehlern oder ähnlichem. Dazu gibt es noch eine handvoll böse Fallstricke die leicht zu übersehen sind und keiner davon führt zu einem compiler fehler.

Sorry, aber Du hast die Interaktion der Klassen nicht verstanden und offenbar auch keins meiner Posts wirklich gelesen, ansonsten wären diese Behauptungen einfach nicht möglich.
Also die Kurzfassung...

Meter m=Meter(1), n=Meter(2); 
Butterbrot b = Butterbrot(1);
Meter mresult = m + b; // geht nicht, weil m+b ergibt Unit bzw. int und int muss explizit zugewiesen werden: Fehlerfall - unbekannte (inkompatible?) Einheiten
Unit result = m + b; // geht, hat eine Einheit, man weiß nur leider nicht welche: Unit ist Warnschild an den Programmierer. Ausnahmefall.
Meter result = uresult; // geht nicht ohne expliziten int-Konstruktor, weil nicht typsicher. 
int iresult = m + b;  // geht, hat aber keine Einheit mehr - entspricht MrN.asInt().
Meter result = iresult; // geht nicht ohne expliziten int-Konstruktor, weil nicht typsicher.

Meter result = m + n; // Typsichere Zuweisung über impliziten CopyConstructor. Das hier ist der Regelfall.

Schon die Möglichkeit, Meter und Butterbrote ohne Kennzeichnung addieren zu können, ist imho schlechtes Design - die Tatsache, daß du das Ergebnis weder als Meter noch als Butterbrot interpretieren kannst, verbessert die Lage zwar etwas, aber nur unwesentlich.
Eine bessere Lösung würde jedes Auftauchen von "m+b" als Fehler einstufen und den Anwender darauf hinweisen, daß er Unsinn verzapft hat - wenn er dann der Meinung ist, die Formel ist doch richtig, kann er die Werte immer noch explizit in einen int umwandeln und damit rechnen (und das ist der Unterschied zwischen deiner "Lösung" und dem genannten asInt()).

Xin schrieb:

Shade Of Mine schrieb:

PS: was das Moderatoren Bashing betrifft - es ist In, ich weiss. Aber die Moderatoren hier stellen sich nicht gegen die Community und streiten gegen sie - sondern wir sind ein Teil von ihr. Deshalb wird auch Leuten wie Xin oder TGGC nicht der Mund verboten. Niemand wird hier sagen "Ich bin Moderator als halte die Fresse" - und Posts werden auch nicht dauernd gelöscht nur weil mal jemand etwas energischer geworden ist.

Das wäre dann auch kein Forum, sondern eine Diktatur. Ich kenne TGGC nicht, aber aus einem anderen Posting habe ich nicht das Gefühl, dass der Vergleich schmeichelhaft war.
Ich erwarte von einem Moderator in allen Subforen und allen Foren, dass er sich so verhält, dass das Diskussionen am Boden der Tatsachen hält.

Aha, und das heißt im konkreten Fall?

Xin schrieb:

CStoll schrieb:

Ich unterscheide zumindest Spannungen von Leistungen - du mischst beides bunt durcheinander, wenn es dir in den Kram passt.

Jow... ist gut, CStoll, wenn nichtmals das bei Dir angekommen ist, dann dann bist Du als C++ Moderator beim Thema Kompetenz eine Fehlbesetzung.
Auch das ist keine Beleidigung, sondern die logische Schlussfolgerung daraus, dass seitenlang die Bedeutung des expliziten Konstruktors nicht bei Dir ankommt.

Wenn ich meinen Computer frage "was ergibt 1000 Millimeter plus 1 Meter", erwarte ich entweder die physikalisch korrekte Antwort "2 Meter" oder die technisch verständliche Gegenfrage "Was ist ein Millimeter?" - mit der Antwort "1001 - was das darstellen soll, weiß ich selber nicht" ist niemandem geholfen. Genauso erwarte ich bei der Frage "Was ist 1 kg plus 1 Meter?" bestenfalls die Antwort "das kann ich nicht addieren" und kein "2 was-auch-immer's" (oder kommt doch 1001 raus, weil Gewichstangaben intern in Gramm verwaltet werden?).

Du unterstellst mir hier, etwas nicht verstanden zu haben, aber selber hast du noch nicht die Bedeutung (und Auswirkungen) der impliziten Typumwandlung verstanden, die du in deinem Design integriert hast.

Xin schrieb:

CStoll schrieb:

Ich habe weder die nötige Zeit noch die Kompetenz, um in diesem Board als Moderator wirken zu können.

Wenn Dir die Kompetenz fehlt, dann halt Dich einfach raus, aber poste nicht seitenweise, dass Du gegen Lösungen bist, bei denen Du nichtmals verstanden hast, dass sie Leistung und Spannung sehr wohl trennen.

OK, sagen wir es so - ich traue mir genug Kompetenz zu, um fachlich über C++ zu reden. Aber ich würde mir nicht anmaßen, außerhalb "meiner" Boards als Moderator in Erscheinung zu treten. Also tu mir einen Gefallen und ignoriere die Tatsache, daß unter meinem Namen nicht "Mitglied" steht - und konzentriere dich lieber auf die fachliche Seite.

Xin schrieb:

CStoll schrieb:

Und außerdem bin ich nicht nur Moderator, sondern zufälligerweise auch ein Mensch (und Programmierer) - und als solcher nehme ich mir das Recht, eine eigene Meinung zu einem Thema zu haben und zu vertreten.

Die ich Dir nie abgesprochen habe.

Da muß ich dich irgendwo falsch verstanden haben, aber in den letzten Beiträgen hast du wiederholt auf meinen Titel als "Moderator" hingewiesen und erklärt, daß ich in dieser Funktion nur die Diskussion entschärfen düfte.

Xin schrieb:

CStoll schrieb:

Btw, wenn du der Meinung bist, ein Moderator darf keine eigene Meinung haben, wie konntest du dann dein Anti-Dekan-Forum betreiben? (ich gehe mal davon aus, daß du dort der Betreiber warst - und damit erst recht auch als Moderator gearbeitet hast)

Soll ich Dir jetzt mehrere Quotes bringen, wo ich sogar darum Bitte, dass Du Kritik äußerst - aber konstruktiv.

Ich bemühe mich ja, konstruktiv zu sein. Aber um das zu bemerken, solltest du mir auch ein wenig entgegenkommen und aus meinen Beiträgen nicht nur die angebliche "ich bin dagegen"-Haltung herausinterpretieren.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Ich stimme Dir (hier nicht zum ersten Mal) zu, dass ein System, dass keine Typinformationen verliert, besser ist, als meins.
Aber ich habe noch keins. Und Du hast auch keins.
Du hast ein unfertiges Template aus dem Internet für SI-Einheiten, dass aber kein Argument ist, denn (wie bereits gesagt) auch dieses kannst Du mit meinen Klassen verwenden. Du widerlegst Deine "Argumente" mit hundertausenden Klassen also selbst - warum muss ich Dir das alles immer wieder vorkauen? Auch das ist Zeitverwendung.

Mag sein, daß ich kein fertiges System zu bieten habe, aber ich habe einen funktions- und ausbaufähigen Lösungsansatz, der Typinformationen nur auf Anforderung wegschmeißt. Du ergänzt dieses System um die Fähigkeit, Typinformationen implizit zu verlieren, also was hast du dadurch nun gewonnen?
(zumal du selbst eingesehen hast, daß das schlechter ist)

Erstens: Ich verliere EVENTUELL IM AUSNAHMEFALL - nicht grundsätzlich - die Typinformation.

Der Punkt ist - du verlierst Typ-Informationen, ohne daß das direkt im Quelltext ersichtlich ist (nicht immer hast du eine einfache Addition, deren Ergebnis du in einer Variablen speichern willst - und bei umfangreichen Rechnungen mußt du erstmal herausfinden, wo der Typ verloren gegangen ist.

Btw, du hast selbst wiederholt darauf hingewiesen, daß eine implizite Umwandlung von int nach Meter unsinnig/fehleranfällig ist und du deshalb nur eine explizite Umwandlung anbietest. Warum macht in deinen Augen die implzite Umwandlung von Meter nach int mehr Sinn?

Xin schrieb:

Zweitens: Du hast einen Lösungsansatz, der nicht weiter kommt als ich.

Doch, er kommt weiter - er warnt einen Anwender bereits, wenn er unpassende Größen miteinander verrechnen will.

Xin schrieb:

Drittens: Ich habe nicht eingesehen, sondern selbstverständlich ist die perfekte Lösung besser als meine, aber wir haben keine. Wir müssen also damit leben, dass weder Du noch ich, weiter kommen als bis zu dem Punkt, an dem wir beide EVENTUELL IM AUSNAHMEFALL - nicht grundsätzlich - Typinformationen verlieren.

Nochmal - ich verliere keine Typinformationen, außer der Anwender sagt mir explizit, daß er sie nicht mehr benötigt. Das ist nicht perfekt, aber immerhin besser als dein Ansatz "hier hast du einen Wert - sieh zu, was du damit anfangen kannst".

[quote="Xin]Viertens: Was ich eingesehen habe, war die Trennung WindowFlag und WindowFlags, Du holst Dir Deine Argumentation aus einem vollkommen anderen Bereich, um hier kompetent auszusehen. Verfolgt man Deine "Argumentation", in dem man wirklich jedes Deiner Postings genau liest, ist das ein wildes Rumgehampel um aus allen Ecken irgendwas hervorzukramen, um dagegen zu sein. Und wie hier, gerne aus Bereichen, die überhaupt nichts mit dem Thema zu tun haben.
[/quote]Wo kommen denn nun auf einmal die WindowFlags wieder her? Ichz dachte, das Thema hätten wir bereits abgehakt.
Nur am Rande: Die Formulierung "du hast eingesehen,..." war eine (aus meiner Sicht) logische Schlussfolgerung aus deiner Aussage "Ich stimme dir zu, daß..." - ich biete keine implizite Umwandlung nach int (oder sonstwas), also können Typinformationen nicht verloren gehen.

Xin schrieb:

Deine Formulierung ist regelmäßig so gewählt, als wäre das, was ich habe schlecht. Es ist nicht nur nicht schlecht - es ist das beste, was wir bisher haben. Auch wenn Du nicht verstehst, dass man damit Leistung und Spannung nicht aufeinander zweisen kann.

Du hast - in diesem Zusammenhang geschrieben, dass was ich mache besser ist und dass Du das perfekte System auch nicht bieten kannst. Also wenn Du nichts zu bieten hast, dann akzeptiere doch einfach, dass was ich mache besser ist, als nichts zu machen und rede es dann nicht weiter schlecht oder erkläre mir, dass ich ein sturer oder unintelligenter Mensch bin, nur weil ich Deine Texte ernst genommen und gelesen habe und sie daher für nicht für voll nehmen kann.

Ja, such dir nur die Passagen heraus, die dir in den Kram passen.

Aber extra für dich nochmal: Dein System ist besser als nackte int's - aber wenn du die implizite (wenn du nicht verstehst, was das bedeutet, schlag im Wörterbuch nach) Umwandlung nach int rauslässt, wird es imho noch besser. Also bitte erkläre mir nochmal ausführlich, welchen Vorteil diese Umwandlung haben soll - dann hätten wir womöglich wieder eine klare Grundlage, auf der wir aufbauen können.

Xin schrieb:

CStoll schrieb:

Mein Template kann mir zumindest sagen, daß ich Butterbrote und Häuser nicht durcheinanderwerfen sollte - wenn ich der Meinung bin, es doch tun zu müssen, muß ich ihm das explizit klarmachen.

Jow. Und bei mir darfst Du durcheinanderwerfen, wie Du willst, aber wenn Du das Ergebnis verwenden willst, musst Du ebenfalls explizit werden.
MrN wird vor dem Operator typlos und ich implizit durch den Operator. Was kommt bei beiden als Ergebnis raus? Etwas typloses, dass Du nicht zuweisen kannst, wenn Du keinen expliziten Konstruktor hast. Ich muss dafür lediglich nicht .asInt() schreiben, was mir keine Nachteile bringt.
Wer gegen den expliziten Konstruktor argumentiert, hat hier soeben eine implizite Konstruktion des Zieltyps abgesegnet, die absolut nicht typsicher war.

Auch wenn du es nicht begreifst - ich argumentiere NICHT gegen den expliziten Konstruktor, sondern gegen die implizite Typumwandlung.
(ich hoffe immer noch, daß diese Aussage irgendwann bis in dein Bewußtsein durchdringt)

Xin schrieb:

CStoll schrieb:

PS: Ich sage übrigens nicht "das ist Unsinn", sondern "das ist Unsinn, weil ..." - aber wenn du nach dem ersten Komma aufhörst, einen Satz zu lesen, kann ich nichts dafür

Leider kam nach dem "Weil" nie viel, in der Regel eine Formulierung mit dem Klang, als wäre was ich tue schlecht, einigen Fachbegriffen, die zusammenhanglos dahergesagt wurden und häufig nichtsmals etwas mit dem eigentlichen Problem zu tun hatten.
Wie in diesem Posting auch mal wieder, wo Du das "Du hast eingesehen" aus vollkommen aus dem Zusammenhang gerissen hast, weil es mit der Thematik hier nichts zu tun hat.

Ja, du kannst gerne meine Beiträge in einzelne Buchstaben zerpflücken und neu zusammenpuzzeln. Aber wenn du meine Aussagen nach herzenslust verdrehst, kommen wir hier kein Stück weiter.

Xin schrieb:

Deine Texte hier waren Geblubber ohne fachlichen Inhalt. Und nun erklärst Du, dass ich Watt und Volt nicht auseinanderhalten könne, was zeigt, dass Du - der sich seit 20 Seiten hier mit dem Thema auseinander setzt - absolut keinen Schimmer hast, worüber hier gesprochen wurde.

Dieses Kompliment gebe ich ungesehen zurück. Du suchst dir aus meinen Beiträgen ein paar Punkte heraus, ignorierst den Rest - und stufst dann diese Fragmente als "Geblubber" oder "sinnlose Worthülsen" einzustufen. Wenn du nicht bereit bist, fachlich zu diskutieren, dann lass es lieber ganz.

Xin schrieb:

Ich kann Dich nicht beleidigen. Selbst wenn ich es wollte, so ist die Beschreibung dessen, was Du hier getextet hast, eine Tatsache, die mir an Deiner Stelle auch nicht gefallen würde, aber es ist keine Beleidigung. Der einzige, der Dich hier beleidigt hat, bist Du. Du präsentierst Texte und möchtest ernstgenommen werden und wenn die Texte dann auf das Problem angewandt werden und Dir die Konsequenz Deiner Texte nicht gefällt, dann hättest Du Dir mehr Gedanken machen sollen, bevor Du sie abgeschickt hast.

Diesen Absatz kannst du auch völlig auf deine Beiträge beziehen. (und btw, wie sieht denn dein Entwurf im Moment aus?)

Ich habe einen Vorteil: Ich habe eine ähnliche (!=identische) Lösung im produktiven Einsatz und weiß daher, dass der explizite Konstruktor den Schlüssel zur Typsicherheit darstellt. Irgendwas wird sich der Stroustrup und das Komitee wohl dabei gedacht haben, als sie das Schlüsselwort abgesegnet haben. Was zusätzliche Schlüsselwörter angeht, sind die ja eher zurückhaltend.
Du warst halt "nur" dagegen und mehr kam nicht. Und als Moderator - besonders als C++-Moderator - erwarte ich von Dir hier die Kompetenz, zu erkennen, dass Du nunmal kein besseres Werkzeug in der Hand hast. Auch im Interesse daran, die Diskussion wertfrei und auf dem Boden zu halten, denn das ist die Kompetenz, die Du als Moderator in allen Subforen dieses und aller anderen Foren zu beweisen hast.

Noch einmal: Ich habe kein Problem mit deinen expliziten Konstruktoren (explizite Typumwandlungen sind eine feine Sache) - aber ich habe ein Problem mit den impliziten Typumwandlungen in deinem Entwurf. Und ich habe einen Lösungsansatz (kein fertiges Werkzeug), der ohne diese impliziten Umwandlungen auskommt.

[Mr. N]

Xin schrieb:

MrN.asInt()

Du hast da was verwechselt. Ich war für:

int operator/(Meter, Meter);

Meter m = ...;
int i = m / Meter(1);

Oder ähnliches. Shade hat asInt() vorgeschlagen, aber wenn ich das richtig verstanden habe, findet er meine Division auch gut.

[scrub]

Xin schrieb:

Ansonsten war es kein Anti-Dekan Forum, sondern der Versuch Kritik zu sammeln, um Negatives aus dem Weg zu räumen - am Liebsten so, dass man mit dem Dekan an einem Strang zieht. Dass sich der Dekan gegen Dutzende Studenten stellt und kein Interesse an einer Zusammenarbeit signalisiert - sogar offen Desinteresse äußert - und jegliche Kritik, die auch von einem Teil der Professoren gesehen wurde, als Prolemik abtut, konnte ich nicht ahnen. Das war absolut dumm, eine Position, die ein Dekan in meinen Augen nichtmals andeutungsweise einnehmen darf.

Der Dekan war schon in dem Moment erledigt, in dem Du dieses Forum eröffnet hast. Deine Professoren haben sich einen Dekan gewählt, der ihnen dann doch nicht in den Kram gepaßt hat, und haben dann auf eine günstige Gelegenheit zur "Entsorgung" gewartet. Du bist ja so ein Held.
Überleg Dir doch mal die Wirkung einer öffentlichen Plattform, auf der Kritik gesammelt wird. Es ist doch völlig logisch, daß er daran nicht "konstruktiv" mitarbeitet. Sowas macht man nicht öffentlich.
Das hättest Du alles viel vorsichtiger machen müssen. So hast Du ihm jede Chance genommen und ihn indirekt abgeschossen. Und das trägst Du jetzt euch noch stolz vor Dir her???

[Xin]

CStoll schrieb:

Schon die Möglichkeit, Meter und Butterbrote ohne Kennzeichnung addieren zu können, ist imho schlechtes Design - die Tatsache, daß du das Ergebnis weder als Meter noch als Butterbrot interpretieren kannst, verbessert die Lage zwar etwas, aber nur unwesentlich.

Das ist typsicher und darum geht es hier, also ist genau das wesentlich.
Ob die Möglichkeit Objekte beliebiger Natur ohne Typ zu zählen ein Designfehler ist, lasse ich hier als Geschmacksfrage gelten. Ich halte das für nützlich, Du hältst es für einen Designfehler.
Man kann sich nicht überall einig sein. Es schränkt die Typsicherheit nicht ein, damit sehe ich hier keinen Designfehler.
Vor der Verwendung der Klasse Unit wäre es tatsächlich einer gewesen, ich weiß nicht mehr wer, aber irgendeiner hat da mal eine richtig gute Kritik abgegeben und dieser Kritik konnte begegnet werden.

CStoll schrieb:

Xin schrieb:

Shade Of Mine schrieb:

PS: was das Moderatoren Bashing betrifft - es ist In, ich weiss. Aber die Moderatoren hier stellen sich nicht gegen die Community und streiten gegen sie - sondern wir sind ein Teil von ihr. Deshalb wird auch Leuten wie Xin oder TGGC nicht der Mund verboten. Niemand wird hier sagen "Ich bin Moderator als halte die Fresse" - und Posts werden auch nicht dauernd gelöscht nur weil mal jemand etwas energischer geworden ist.

Das wäre dann auch kein Forum, sondern eine Diktatur. Ich kenne TGGC nicht, aber aus einem anderen Posting habe ich nicht das Gefühl, dass der Vergleich schmeichelhaft war.
Ich erwarte von einem Moderator in allen Subforen und allen Foren, dass er sich so verhält, dass das Diskussionen am Boden der Tatsachen hält.

Aha, und das heißt im konkreten Fall?

Lass Dich drauf ein, spiel mit dem Gedanken, probiere es aus.
Das ermöglicht mir ebenso eine ganz andere Diskussionsgrundlage. Statt immer nur in die Defensive gedrängt zu werden und merkwürde Texte zu analysieren, um sie zu widerlegen, bleibt Zeit für den konstruktiven, für den wertvollen und wertschöpfenden Part einer Diskussion.
Man kann man als Team Probleme herausfiltern, lösen oder feststellen, dass wir mit dem Problem leben müssen und anschließend darüber diskutieren, ob vorhandene Problem schwerwiegender als die erhofften Vorteile sind.

Es ist immer gut wenn möglichst viele Perspektiven eine Möglichkeit beleuchten, so sieht man möglichst viele Schwachstellen. Schwachstellen zu erkennen (z.B. die fehlende class Unit) bedeutet dann aber nicht zwangsläufig, dass eine Möglichkeit nichts taugt, sondern dass gegebenenfalls man eine Lösung entwickeln kann.

CStoll schrieb:

Wenn ich meinen Computer frage "was ergibt 1000 Millimeter plus 1 Meter", erwarte ich entweder die physikalisch korrekte Antwort "2 Meter" oder die technisch verständliche Gegenfrage "Was ist ein Millimeter?" - mit der Antwort "1001 - was das darstellen soll, weiß ich selber nicht" ist niemandem geholfen. Genauso erwarte ich bei der Frage "Was ist 1 kg plus 1 Meter?" bestenfalls die Antwort "das kann ich nicht addieren" und kein "2 was-auch-immer's" (oder kommt doch 1001 raus, weil Gewichstangaben intern in Gramm verwaltet werden?).

Du unterstellst mir hier, etwas nicht verstanden zu haben, aber selber hast du noch nicht die Bedeutung (und Auswirkungen) der impliziten Typumwandlung verstanden, die du in deinem Design integriert hast.

Doch, habe ich.
Wenn ich zwei Klassen haben, die das identische Problem (Strecke) beschreiben, dann habe ich Redundanz. Redundanz ist ein Designfehler. Also darf es keine class Millimeter geben, die eine Strecke beschreibt. Es darf eine Umrechnungsfunktion Millimeter() geben, die eine Anzahl von 1000stel Meter in Meter umwandelt und es darf Umrechnungsfunktionen geben, die eine Meterangabe als Anzahl von 1000stel Meter ausgibt.

Wenn nun jemand hingeht und eine zweite Klasse Millimeter schreibt, so besteht zwischen class Millimeter und class Meter keine Beziehung. 1000 Millimeter + 1 Meter ergibt 1001 Unit.
Das ist eine korrekte Berechnung zweier Klassen, die keine Beziehung zueinander haben. Der Wert ist weder als Millimeter, noch als Meter zu lesen und das wird im Ergebnis deutlich. Wenn Du als Programmierer zwischen Millimeter und Meter eine Beziehung siehst, die Du in Form eines Designfehlers implementiert hast, dann hast Du einen Bug produziert und sogar den Hinweis darauf bekommen, weil die Einheit unpassend ist, wenn sie eine Beziehung haben sollten.
Mir ist kein Framework, keine Sprache bekannt, die Entwickler zuverlässig davor schützt Bugs zu produzieren. Ich sehe auch kein Framework in der Verantwortung, wenn ein Entwickler Bugs schreibt.
Den Hinweis der Units empfinde ich sogar als vorbildliche Hilfe.

CStoll schrieb:

OK, sagen wir es so - ich traue mir genug Kompetenz zu, um fachlich über C++ zu reden. Aber ich würde mir nicht anmaßen, außerhalb "meiner" Boards als Moderator in Erscheinung zu treten. Also tu mir einen Gefallen und ignoriere die Tatsache, daß unter meinem Namen nicht "Mitglied" steht - und konzentriere dich lieber auf die fachliche Seite.

Ich erwarte diese Fähigkeiten von allen Mitgliedern. Ich erwarte sie sie nur im besonderen von den Moderatoren.

Xin schrieb:

Da muß ich dich irgendwo falsch verstanden haben, aber in den letzten Beiträgen hast du wiederholt auf meinen Titel als "Moderator" hingewiesen und erklärt, daß ich in dieser Funktion nur die Diskussion entschärfen düfte.

Deswegen musst Du doch nicht auf Deine Meinung verzichten?
Du könntest darauf verzichten, ausschließlich dagegen zu sein.

CStoll schrieb:

Ich bemühe mich ja, konstruktiv zu sein. Aber um das zu bemerken, solltest du mir auch ein wenig entgegenkommen und aus meinen Beiträgen nicht nur die angebliche "ich bin dagegen"-Haltung herausinterpretieren.

Ich komme Dir gerne entgegen. Ich kann aber nicht, solange mir Texte um die Ohren fliegen, die ich nur mit "ich bin dagegen" interpretieren kann.

CStoll schrieb:

Der Punkt ist - du verlierst Typ-Informationen, ohne daß das direkt im Quelltext ersichtlich ist (nicht immer hast du eine einfache Addition, deren Ergebnis du in einer Variablen speichern willst - und bei umfangreichen Rechnungen mußt du erstmal herausfinden, wo der Typ verloren gegangen ist.

Ich erhalte einen anderen Typ, als ich erwarte. Ich erhalte Unit. In komplexen Rechnungen passiert es auch ohne meine Klassen immer mal wieder, dass etwas geschieht, was ich nicht erwartete und ich muss debugge.
Hier besteht eine hohe Chance, dass ich Unit nicht zuweisen kann und entsprechend schon einen Compilerfehler erhalte.
Wo ist der Unterschied?

CStoll schrieb:

Btw, du hast selbst wiederholt darauf hingewiesen, daß eine implizite Umwandlung von int nach Meter unsinnig/fehleranfällig ist und du deshalb nur eine explizite Umwandlung anbietest. Warum macht in deinen Augen die implzite Umwandlung von Meter nach int mehr Sinn?

Die implizite Umwandlung von Tier & nach Katze & ist unsinnig/fehleranfällig und du deshalb nur über eine explizite Umwandlung möglich ist. Warum macht in deinen Augen die implzite Umwandlung von Katze & nach Tier & mehr Sinn?

CStoll schrieb:

Nochmal - ich verliere keine Typinformationen, außer der Anwender sagt mir explizit, daß er sie nicht mehr benötigt. Das ist nicht perfekt, aber immerhin besser als dein Ansatz "hier hast du einen Wert - sieh zu, was du damit anfangen kannst".

Da du diesen Wert letztendlich wieder zuweisen musst, ist es typsicher. Weist Du ihn nicht zu, spielt es eh keine Rolle, was da rauskommt oder welchen Typ es hat.
Du bist also dann typsicherer, wenn der Wert nur verworfen wird. Wenn Dir das so wichtig ist, siehe oben: "Geschmacksfrage".

CStoll schrieb:

Xin schrieb:

Viertens: Was ich eingesehen habe, war die Trennung WindowFlag und WindowFlags, Du holst Dir Deine Argumentation aus einem vollkommen anderen Bereich, um hier kompetent auszusehen. Verfolgt man Deine "Argumentation", in dem man wirklich jedes Deiner Postings genau liest, ist das ein wildes Rumgehampel um aus allen Ecken irgendwas hervorzukramen, um dagegen zu sein. Und wie hier, gerne aus Bereichen, die überhaupt nichts mit dem Thema zu tun haben.

Wo kommen denn nun auf einmal die WindowFlags wieder her? Ichz dachte, das Thema hätten wir bereits abgehakt.
Nur am Rande: Die Formulierung "du hast eingesehen,..." war eine (aus meiner Sicht) logische Schlussfolgerung aus deiner Aussage "Ich stimme dir zu, daß..."

...dass was?

Das es besser sein könnte, aber in C++ keiner in diesem Thread was besseres hat.
Du schreibst es hier, als hätte ich eingesehen, dass meine Klassen Deinen unterlegen wären. Sie sind es nicht und ich habe das auch nicht behauptet. Was Du da geschrieben hast, war kein Argument, sondern Manipulation.

CStoll schrieb:

Ja, such dir nur die Passagen heraus, die dir in den Kram passen.

Das war bisher Niveau Unregistrierter - wenn Dir nicht gefällt, dass Deine Texte Angriffsfläche bieten, dann schreib sie entsprechend und beschwer Dich nicht.

CStoll schrieb:

Aber extra für dich nochmal: Dein System ist besser als nackte int's - aber wenn du die implizite (wenn du nicht verstehst, was das bedeutet, schlag im Wörterbuch nach)...

Du kannst es nicht lassen, hmm?

CStoll schrieb:

...Umwandlung nach int rauslässt, wird es imho noch besser.

imho... ein interessanter Punkt zu Relativierung.

Soso, Deiner "bescheidenen Meinung nach", die Du hier ganz bescheiden sogar mit manipulierten "Argumenten" bestätigt wissen möchtest. Meiner Meinung nach wird es nicht besser, es bleibt gleichwertig, man muss dafür gegebenfalls asInt() schreiben. Unterm Strich: siehe oben, Geschmackssache.

CStoll schrieb:

Also bitte erkläre mir nochmal ausführlich, welchen Vorteil diese Umwandlung haben soll - dann hätten wir womöglich wieder eine klare Grundlage, auf der wir aufbauen können.

Es hat keinen Nachteil und mir gefällt es besser: Geschmachssache.

CStoll schrieb:

Xin schrieb:

Wie in diesem Posting auch mal wieder, wo Du das "Du hast eingesehen" aus vollkommen aus dem Zusammenhang gerissen hast, weil es mit der Thematik hier nichts zu tun hat.

Ja, du kannst gerne meine Beiträge in einzelne Buchstaben zerpflücken und neu zusammenpuzzeln. Aber wenn du meine Aussagen nach herzenslust verdrehst, kommen wir hier kein Stück weiter.

:-\
Interessante Äußerung dazu...

Mr. N schrieb:

Xin schrieb:

MrN.asInt()

Du hast da was verwechselt. Ich war für:

int i = m / Meter(1);

Oder ähnliches. Shade hat asInt() vorgeschlagen, aber wenn ich das richtig verstanden habe, findet er meine Division auch gut.

Whoops, dann hätte ich wohl besser Shade.asInt() geschrieben.

Ich finde asInt() oder int() besser, weil asInt(), wie auch int(), inline zu nichts herrausoptimiert kann und m/Meter(1) eine Rechenoperation Operation verlangt, die nur sehr schwer rausoptimiert werden kann und vermutlich auch nicht rausoptimiert wird.
Trotzdem ist Deine Möglichkeit natürlich hier wie da möglich.

[Jester]

Ich sehe eigentlich zwei Nachteile Deiner Methode gegenüber der von CStoll (und keine Vorteile):

1. Durch die implizite int-Konvertierung ist nicht offensichtlich welche Zeilen potenziell gefährlich sind und welche nicht. Dazu muß man den Typ des Objektes, das links vom Gleichheitszeichen steht kennen. Der asInt-Ansatz ist da expliziter. Üblicherweise wird man sich wohl die meiste Zeit in mathematisch/physikalisch korrekten Bereichen bewegen und nur selten Sachen rechnen wo Typverlust da ist. Das asInt-Zeug sorgt dafür, dass diese automatisch gut gekennzeichnet sind.

2. Das Erzeugen der Klassen. Das template ist ziemlich kurz und erzeugt trotzdem eine riesige Menge an Einheiten. Wie begegnest Du dem mit Deinem Ansatz? Soweit ich es verstanden habe mußt Du die Klassen jedesmal von Hand schreiben und genau angeben, welche womit wie interagiert.

Was meinst Du dazu? Welche Vorteile sind mir entgangen? Wie fängst Du diese Nachteile auf?

[Xin]

scrub schrieb:

Xin schrieb:

Ansonsten war es kein Anti-Dekan Forum, sondern der Versuch Kritik zu sammeln, um Negatives aus dem Weg zu räumen - am Liebsten so, dass man mit dem Dekan an einem Strang zieht. Dass sich der Dekan gegen Dutzende Studenten stellt und kein Interesse an einer Zusammenarbeit signalisiert - sogar offen Desinteresse äußert - und jegliche Kritik, die auch von einem Teil der Professoren gesehen wurde, als Prolemik abtut, konnte ich nicht ahnen. Das war absolut dumm, eine Position, die ein Dekan in meinen Augen nichtmals andeutungsweise einnehmen darf.

Der Dekan war schon in dem Moment erledigt, in dem Du dieses Forum eröffnet hast. Deine Professoren haben sich einen Dekan gewählt, der ihnen dann doch nicht in den Kram gepaßt hat, und haben dann auf eine günstige Gelegenheit zur "Entsorgung" gewartet. Du bist ja so ein Held.
Überleg Dir doch mal die Wirkung einer öffentlichen Plattform, auf der Kritik gesammelt wird. Es ist doch völlig logisch, daß er daran nicht "konstruktiv" mitarbeitet. Sowas macht man nicht öffentlich.
Das hättest Du alles viel vorsichtiger machen müssen. So hast Du ihm jede Chance genommen und ihn indirekt abgeschossen. Und das trägst Du jetzt euch noch stolz vor Dir her???

Ich bin jahrelang regelmäßig beim Dekan gewesen und mir wurde immer gesagt, ich wäre der einzige, der sich beschwert, was definitiv nicht stimmte. Es ließ sich aber nie belegen, weil man war ja entweder allein oder eben nur zu zweit und bekam gesagt, dass außer mir bzw. uns zwei jeder Student alles toll findet.
Und als ich dann hörte, dass das den anderen Studenten das Gleiche erzählt wird, habe ich mich einem besagter anderen Studenten zusammengetan und das Forum aufgemacht.
Und auf schnell fanden sich mehrere Dutzend Studenten. Übrigens waren auch gute 2-5% dabei, die von der FH so wie sie ist, überzeugt waren.

Der Dekan hatte mehrere Chancen, ich schieße nicht scharf, ohne vielfach davor zu warnen. Ich warne sogar so oft, dass die meisten gar nicht glauben, dass ich wirklich mal aktiv werde. Und wenn ich ihn so indirekt abgeschossen habe, so war das eigenes Verschulden des Dekans.
Ich spreche nicht von Stolz davon. Er ist aber mein bestes Beispiel dafür, dass mich viele Leute oder besondere Autoritäten am Allerwertesten vorüberziehen, wenn sie keine Argumente haben.

Das Forum war im Internet öffentlich erreichbar. Allerdings gab es lediglich lokal und innerhalb der FH Werbung dafür. Die Öffentlichkeit war also durchaus erstmal eingeschränkt. Ich habe keine Zeitungen diesbezüglich angeschrieben, weil ich die Sache eigentlich klein halten wollte, das Forum fand allerdings sofort guten (lokalen) Anklang, besser als ich erwartete.

Als Dekan hätte man das Forum auch nutzen zu können, um zu demonstrieren, dass man sich für die Belange der Stundenten interessiert. Genau das Gegenteil wurde gemacht.
Ich habe keinen Dekan abgeschossen, ich habe ihm lediglich die Waffe gereicht, um sich selbst abzuschießen.
Das einzige worauf ich stolz sein kann ist, dass ich meinem Dekan nicht aus dem Weg gehen musste. Er hatte das Angebot, dass man gemeinsam ein Stück geht, um die Dinge für beide Seite zu verbessern und er hat sich dafür entschieden, seinen Karren in den Dreck zu setzen. Das war nicht meine Entscheidung, noch hatte ich die Position oder Intention, ihn abzuschießen.

[Xin]

Jester schrieb:

Ich sehe eigentlich zwei Nachteile Deiner Methode gegenüber der von CStoll (und keine Vorteile):

1. Durch die implizite int-Konvertierung ist nicht offensichtlich welche Zeilen potenziell gefährlich sind und welche nicht. Dazu muß man den Typ des Objektes, das links vom Gleichheitszeichen steht kennen. Der asInt-Ansatz ist da expliziter. Üblicherweise wird man sich wohl die meiste Zeit in mathematisch/physikalisch korrekten Bereichen bewegen und nur selten Sachen rechnen wo Typverlust da ist. Das asInt-Zeug sorgt dafür, dass diese automatisch gut gekennzeichnet sind.

Das ist okay. Ich sehe hier weniger Verwechslungswahrscheinlichkeit und spare mit daher asInt().
Siehe Posting an CStoll: Geschmachssache.

Jester schrieb:

2. Das Erzeugen der Klassen. Das template ist ziemlich kurz und erzeugt trotzdem eine riesige Menge an Einheiten. Wie begegnest Du dem mit Deinem Ansatz? Soweit ich es verstanden habe mußt Du die Klassen jedesmal von Hand schreiben und genau angeben, welche womit wie interagiert.

Das Template ist keine Lösung, sondern nur eine Möglichkeit Klassen für eine Lösung zu erzeugen. Ob Du damit nun Klassen erzeugst, die von einem Grundtypen erben oder die einen Grundtypen als Member erzeugst, spielt dabei keine Rolle.
Zumal die eigentliche Lösung ein theoretisches Konstrukt darstellt, weil man in C++ von einem Primitiv nunmal nicht ableiten kann. Die C++-Realität muss so oder eine Komposition sein.

Ansonsten reicht das Template alleine erstmal nur für SI-Einheiten. Es bietet im Alltag daher auch keinen Vorteil.
Ein weiteres Template für unabhängige Einheiten wie Butterbrot usw. muss dazu kommen. CStoll hat keine Lösung präsentiert, die einen Mehrwert (oder überhaupt einen interessanten Unterschied) zu meiner Lösung darstellt.

Jester schrieb:

Was meinst Du dazu? Welche Vorteile sind mir entgangen? Wie fängst Du diese Nachteile auf?

Dir sind keine Vorteile entgangen, aber Dir ist entgangen, dass es auch keine Nachteile/Unterschiede gibt.
Es ist gleichwertig.

Wenn Du also Vorteile suchst, frag CStoll, was er zu bieten hat, schließlich kommt von mir der Vorschlag und von ihm die Aussage, dass er was besseres will.

[Mr. N]

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

MrN.asInt()

Du hast da was verwechselt. Ich war für:

int i = m / Meter(1);

Oder ähnliches. Shade hat asInt() vorgeschlagen, aber wenn ich das richtig verstanden habe, findet er meine Division auch gut.

Whoops, dann hätte ich wohl besser Shade.asInt() geschrieben.

Ich finde asInt() oder int() besser, weil asInt(), wie auch int(), inline zu nichts herrausoptimiert kann und m/Meter(1) eine Rechenoperation Operation verlangt, die nur sehr schwer rausoptimiert werden kann und vermutlich auch nicht rausoptimiert wird.
Trotzdem ist Deine Möglichkeit natürlich hier wie da möglich.

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

[Jester]

Xin schrieb:

Ansonsten reicht das Template alleine erstmal nur für SI-Einheiten. Es bietet im Alltag daher auch keinen Vorteil.

Naja, aber es bietet immerhin auch alle Kombinationen davon. Wie willst Du das mit Deinem Ansatz erreichen?

Und eine weitere Dimension des template-vectors als Butterbrote aufzufassen löst auch das Problem der Butterbrote.

btw: dass du mir vorher noch schnell erklärst was template sind kann ich auch in die Schublade effekthascherei stecken, gell?

[Xin]

Mr. N schrieb:

int i = m / Meter(1);

Xin schrieb:

Ich finde asInt() oder int() besser, weil asInt(), wie auch int(), inline zu nichts herrausoptimiert kann und m/Meter(1) eine Rechenoperation Operation verlangt, die nur sehr schwer rausoptimiert werden kann und vermutlich auch nicht rausoptimiert wird.
Trotzdem ist Deine Möglichkeit natürlich hier wie da möglich.

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

[Mr. N]

Xin schrieb:

Mr. N schrieb:

int i = m / Meter(1);

Xin schrieb:

Ich finde asInt() oder int() besser, weil asInt(), wie auch int(), inline zu nichts herrausoptimiert kann und m/Meter(1) eine Rechenoperation Operation verlangt, die nur sehr schwer rausoptimiert werden kann und vermutlich auch nicht rausoptimiert wird.
Trotzdem ist Deine Möglichkeit natürlich hier wie da möglich.

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

So in etwa:

class MeterEinheit {};

inline int Meter::operator/(MeterEinheit) const {
  return this->value;
}

Aber wie gesagt, das sollte nichtmal nötig sein.

[Undertaker]

CStoll schrieb:

[*]dich stufe ich als (vereinfacht formuliert) "gelegentlich nervtötend" ein - du magst zwar recht gut im Umgang mit C sein, aber wenn du versuchst, das auf C++ Probleme anzuwenden, landest du schnell auf der ***
[/list]

sowas würde ich niemals machen. wenn ich im C++ forrum code poste, dann nur solchen, der anstandslos durch einen stinknormalen C++ compiler geht.

[Xin]

Jester schrieb:

Xin schrieb:

Ansonsten reicht das Template alleine erstmal nur für SI-Einheiten. Es bietet im Alltag daher auch keinen Vorteil.

Naja, aber es bietet immerhin auch alle Kombinationen davon. Wie willst Du das mit Deinem Ansatz erreichen?

Und eine weitere Dimension des template-vectors als Butterbrote aufzufassen löst auch das Problem der Butterbrote.

btw: dass du mir vorher noch schnell erklärst was template sind kann ich auch in die Schublade effekthascherei stecken, gell?

Nein, denn offenbar fällt Dir nicht auf, dass das Template in meinem Ansatz genauso gut funktioniert, ergo ebenso alle Klassen in meinem Ansatz erzeugen kann, erscheint mir das notwendig. Die Frage ist schließlich nicht, wie woher die Klassen kommen, sondern wie sie aussehen.

Da Du das template aber nicht unendlich dimensional erzeugen kannst, jedenfalls nicht in der Realität, ist wohl eindeutig.
Daher kommst Du mit dem Template nicht weiter als ohne. Schon mit den 7 Einheiten wird das ganze vollkommen unverständlich.

unit< 1, 1,-2, 0, 0, 0, 0> Kraft;
unit< 1, 0, 0, 0, 0, 0, 0> Masse = unit< 1, 0, 0, 0, 0, 0, 0>( 10 );
unit< 0, 1, 0, 0, 0, 0, 0> Strecke = unit< 0, 1, 0, 0, 0, 0, 0>( 5 );
unit< 0, 0, 1, 0, 0, 0, 0> Zeit = unit< 0, 0, 1, 0, 0, 0, 0>( 2 );

Kraft = Masse * Strecke / Zeit / Zeit;

Wenn das jemand kapieren soll, brauchst Du also jede Menge Typedefs oder Ableitungen oder sonst irgendwas, um brauchbare Namen in den Code zu bekommen. Oder halt viel Spaß beim Knobeln.
Und da möchtest Du weitere Dimensionen für Butterbrote hinzufügen?
Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

So in etwa:

class MeterEinheit {};

inline int Meter::operator/(MeterEinheit) const {
  return this->value;
}

Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

[Mr. N]

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Xin schrieb:

Jester schrieb:

Xin schrieb:

Ansonsten reicht das Template alleine erstmal nur für SI-Einheiten. Es bietet im Alltag daher auch keinen Vorteil.

Naja, aber es bietet immerhin auch alle Kombinationen davon. Wie willst Du das mit Deinem Ansatz erreichen?

Und eine weitere Dimension des template-vectors als Butterbrote aufzufassen löst auch das Problem der Butterbrote.

btw: dass du mir vorher noch schnell erklärst was template sind kann ich auch in die Schublade effekthascherei stecken, gell?

Nein, denn offenbar fällt Dir nicht auf, dass das Template in meinem Ansatz genauso gut funktioniert, ergo ebenso alle Klassen in meinem Ansatz erzeugen kann, erscheint mir das notwendig. Die Frage ist schließlich nicht, wie woher die Klassen kommen, sondern wie sie aussehen.

Da Du das template aber nicht unendlich dimensional erzeugen kannst, jedenfalls nicht in der Realität, ist wohl eindeutig.
Daher kommst Du mit dem Template nicht weiter als ohne. Schon mit den 7 Einheiten wird das ganze vollkommen unverständlich.

unit< 1, 1,-2, 0, 0, 0, 0> Kraft;
unit< 1, 0, 0, 0, 0, 0, 0> Masse = unit< 1, 0, 0, 0, 0, 0, 0>( 10 );
unit< 0, 1, 0, 0, 0, 0, 0> Strecke = unit< 0, 1, 0, 0, 0, 0, 0>( 5 );
unit< 0, 0, 1, 0, 0, 0, 0> Zeit = unit< 0, 0, 1, 0, 0, 0, 0>( 2 );

Kraft = Masse * Strecke / Zeit / Zeit;

Wenn das jemand kapieren soll, brauchst Du also jede Menge Typedefs oder Ableitungen oder sonst irgendwas, um brauchbare Namen in den Code zu bekommen. Oder halt viel Spaß beim Knobeln.
Und da möchtest Du weitere Dimensionen für Butterbrote hinzufügen?

In der Praxis würde man sicherlich nicht template<int, int, ...> class unit; nutzen sondern eher etwas basierend auf der MPL.

Ich denke da an sowas:

struct meter_tag {};
struct second_tag {};
struct kilogram_tag {};

typedef unit<
    mpl::map1<
      mpl::pair<meter_tag, mpl::int_<1> >
    > 
  > meter;
typedef unit<
    mpl::map3<
      mpl::pair<kilogram_tag, mpl::int_<1> >,
      mpl::pair<meter_tag, mpl::int_<1> >,
      mpl::pair<second_tag, mpl::int_<-2>
    >
  > newton;

Oder falls dir das zuviel Syntax ist:

typedef unit<
   UNIT_TYPEMAP((kilogram, 1)(meter, 1)(second, -2))
  > newton;

Das wäre aber MrN-typisch eine ziemlich komplexe API, wie ich gerne zugebe.

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

So in etwa:

class MeterEinheit {};

inline int Meter::operator/(MeterEinheit) const {
  return this->value;
}

Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

Wozu operator int()? Division ist viel kohärenter zum physikalischen Vorbild.

[Xin]

Mr. N schrieb:

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Ich garantiere für nichts, ich habe einen Ruf zu verlieren. ;->

Mr. N schrieb:

Das wäre aber MrN-typisch eine ziemlich komplexe API, wie ich gerne zugebe.

Wenn's funktioniert, wunderbar. Unabhängig davon musst Du dennoch alle Namen beschreiben. Je besser Du das automatisierst, desto besser. CStoll rechnete mal aus, dass bis zur 5. Potenz was um die 100000 Namen zu definieren wären.
Das artet auch mit dem besten Template immernoch in Arbeit aus.

Für die grundlegenden Größen, sieht's interessant aus, aber unterm Strich bist Du auch noch keinen Schritt weiter als ich.
Ich bilde die perfekte Welt schließlich nicht ab, weil ich zu blöd dafür wäre, sondern weil es zu aufwendig wird.

Mr. N schrieb:

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

"Butterbrot ist kein Relevanter Typ"?
Ob Butterbrot ein relevanter Typ ist, hängt vielleicht etwas von der zu schreibenden Anwendung ab.

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

Wozu operator int()? Division ist viel kohärenter zum physikalischen Vorbild.[/quote]
Hmm... operator int() ist viel kohärenter zur C++-Programmierung?
operator int() ist leicht zu optimieren und kostet keine Rechenzeit.
Und es verbietet die Division ja nicht.

Also wozu nicht operator int()?

[Mr. N]

Xin schrieb:

Mr. N schrieb:

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Ich garantiere für nichts, ich habe einen Ruf zu verlieren. ;->

...

Xin schrieb:

Mr. N schrieb:

Das wäre aber MrN-typisch eine ziemlich komplexe API, wie ich gerne zugebe.

Wenn's funktioniert, wunderbar. Unabhängig davon musst Du dennoch alle Namen beschreiben. Je besser Du das automatisierst, desto besser. CStoll rechnete mal aus, dass bis zur 5. Potenz was um die 100000 Namen zu definieren wären.
Das artet auch mit dem besten Template immernoch in Arbeit aus.

Ich definiere nur die Namen, für die es auch einen Physikalischen Namen gibt. Ansonsten überlege ich mir vielleicht eine Kurzsyntax für zusammengesetzte Einheiten - oder ich benutze C++0x auto / decltype bzw. schon jetzt BOOST_AUTO / BOOST_TYPEOF / typeof.

Xin schrieb:

Für die grundlegenden Größen, sieht's interessant aus, aber unterm Strich bist Du auch noch keinen Schritt weiter als ich.
Ich bilde die perfekte Welt schließlich nicht ab, weil ich zu blöd dafür wäre, sondern weil es zu aufwendig wird.

Und ich denke, mittelfristig würde es sich durchaus lohnen, das sauber abzubilden.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

"Butterbrot ist kein Relevanter Typ"?
Ob Butterbrot ein relevanter Typ ist, hängt vielleicht etwas von der zu schreibenden Anwendung ab.

Butterbrote kann man ganz toll in "Stück" messen, finde ich.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

Wozu operator int()? Division ist viel kohärenter zum physikalischen Vorbild.

Hmm... operator int() ist viel kohärenter zur C++-Programmierung?

Finde ich nicht.

Xin schrieb:

operator int() ist leicht zu optimieren und kostet keine Rechenzeit.

operator/ ist genauso gut optimierbar. Du solltest dir vielleicht mal die Optimierfähigkeiten von modernen C++-Compilern genauer anschauen.

Xin schrieb:

Und es verbietet die Division ja nicht.

Also wozu nicht operator int()?

Nun ja, meinetwegen könnte man auch asInt() und operator/ parallel erlauben. Warum operator int() schlecht ist, haben CStoll und Shade IMHO sehr schön erklärt.

[Xin]

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Ich garantiere für nichts, ich habe einen Ruf zu verlieren. ;->

...

Auch kein Humor... :-\

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

"Butterbrot ist kein Relevanter Typ"?
Ob Butterbrot ein relevanter Typ ist, hängt vielleicht etwas von der zu schreibenden Anwendung ab.

Butterbrote kann man ganz toll in "Stück" messen, finde ich.

Häuser auch.
Also sind 4 Stück Häuser == 4 Stück Butterbrote und kein Stück Typsicher.

Mr. N schrieb:

Xin schrieb:

operator int() ist leicht zu optimieren und kostet keine Rechenzeit.

operator/ ist genauso gut optimierbar. Du solltest dir vielleicht mal die Optimierfähigkeiten von modernen C++-Compilern genauer anschauen.

Vielleicht solltest Du überlegen, dass operator / () ein Argument hat, was sich Beachtung wünscht und operator int() nicht.
Wenn Du durch Metereinheit teilst, passt das, aber das ist ein billiges Hilfskonstrukt.
Teilst Du durch Meter(1) hast Du ein Argument, dass Du beachten musst und das lässt sich nicht gut rausoptimieren.

Xin schrieb:

Nun ja, meinetwegen könnte man auch asInt() und operator/ parallel erlauben. Warum operator int() schlecht ist, haben CStoll und Shade IMHO sehr schön erklärt.

IYHO.
Belassen wir es bei Geschmackssache, bevor wir hier noch eine Runde im Kreis drehen.

[Shade Of Mine]

Xin schrieb:

Jester schrieb:

Was meinst Du dazu? Welche Vorteile sind mir entgangen? Wie fängst Du diese Nachteile auf?

Dir sind keine Vorteile entgangen, aber Dir ist entgangen, dass es auch keine Nachteile/Unterschiede gibt.
Es ist gleichwertig.

Es werden massig Nachteile aufgezählt - du lässt nur keine gelten.

Das sollte zu denken geben. Denn auch wenn nicht jeder genannte Punkt ein kritischer Nachteil ist, so ist allein die Summe der Potenziellen-Nachteile bedenklich.

Was das Framework betrifft: du behauptest dass jeder mit dem Framework programmieren kann wie er will und du keine Restriktionen haben willst - deshalb ja auch die freie Mischung von Einheiten wie der Programmierer lustig ist -> aber im Endeffekt hast du sehr strikte Vorschriften an den Programmierer was er alles machen darf. Denn ein Fehler und es kommt nur noch blödsinn raus -> OHNE Compiler Fehler.

Weiters ist es halt auch wahnsinnig unpraktisch, dass man nicht:

void display(Kilogramm k) { ... }

Kilogramm k = ...;
display(k / 10);

schreiben kann.

Da ja k/10 ein int ist, aber ein int nicht in Kilogramm konvertierbar ist.

Die Idee von Mr.N mit dem Kürzen der Einheiten ist übrigens die perfekte Lösung für die meisten Probleme hier.

Wenn wir intern mit Metern rechnen - dann gibt es Rundungsfehler wenn wir im Millimeter Bereich oder Pikometer oder wie tief wir wollen. Deshalb ist eine interne fixe Einheit problematisch. Mit dem Einheiten Kürzen wird das gelöst und auch das Problem was 1000 Millimeter als integer ist.