Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
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.
-
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???
-
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.
-
Ich sehe eigentlich zwei Nachteile Deiner Methode gegenüber der von CStoll (und keine Vorteile):
-
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 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?
-
-
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.
-
Jester schrieb:
Ich sehe eigentlich zwei Nachteile Deiner Methode gegenüber der von CStoll (und keine Vorteile):
- 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:
- 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.
-
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.
-
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?
-
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?
-
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.
-
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.
-
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...
-
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.
-
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()?
-
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.
-
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.
-
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.
-
Xin schrieb:
Häuser auch.
Also sind 4 Stück Häuser == 4 Stück Butterbrote und kein Stück Typsicher.Meinetwegen kannst du auch je einen Typen für Butterbrote und Häuser verwenden, ich glaube nur nicht, dass man das benötigt (subjektive Einschätzung). Das Framework sollte trotzdem damit umgehen können.
Xin schrieb:
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.
Das schadet nicht, zumindest GCC kann sowas wegoptimieren. Das habe ich getestet. Andere Compiler können es sicher genauso, aber bei denen habe ich es nicht getestet.
Xin schrieb:
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.Doch, lässt sich rausoptimieren. Siehe oben.
Xin schrieb:
Mr. N 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.Wie auch immer.
-
So viele Geisterfahrer wieder auf Xins Autobahn.
-
Xin schrieb:
Mr. N 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.Kommen wir da doch mal auf Typsicherheit zu sprechen von der ich ja keine Ahnung habe. Es gibt 2 Arten um int und Meter miteinander zu verbinden: über einen non-explicit CTor und über operator int.
operator int erlaubt Typenverlust, CTor erlaubt Typengewinn. Generell verwendet man deshalb operator int sehr sehr selten. Denn viele Typen wie zB std::string sind kein char*, wohl kann aber ein char* problemlos in einen std::string umgewandelt werden.
Ähnlich ist es mit Meter. Meter ist kein int - er ist mehr als ein int. Er ist ein int mit Typ-Information. Wenn wir einen operator int implementieren dann erlauben wir impliziten Typverlust. Das ist zB deswegen doof, weil es keine Compilerwarnungen gibt:
Meter m(7); cout<<m;Es sollte "7 Meter" ausgegeben werden, aber leider haben wir den op<< vergessen zu implementieren. Es wird 7 ausgegeben. Ohne Warnung. Das ist dann ein Problem wenn der int Wert keinen direkten Sinn macht: zB bei dem Umrechnungsproblem Millimeter <-> Meter wo wir nicht wissen ob das jetzt Millimeter oder Meter sind.
Compiler warnt nicht.
Bei einem non-explicit CTor gibt es nur ein Risiko: dass der Programmierer in einen Typenlosen Wert zuviel reininterpretiert.
m=getRandomInt();Das ist natürlich auch ein Problem - aber der Programmierer kann das kaum aus versehen machen. Denn wenn er einen falschen integer zuweist, dann kann er das auch explizit machen:
m=Meter(getRandomInt());
