Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
Xin schrieb:
Mr. N schrieb:
Xin schrieb:
Als schäbiger FH-Absolvent, kömmt mein Ego ganz gut mit der Kritik der Uni-Studenten zurecht - ich habe die Postings ja gelesen.
Offensichtlich kommst du mit der Kritik nicht zurecht. Wunderst dich ja sogar, dass nicht alle über deine Beleidigungen lachen. Und konterst mit noch mehr Beleidigung.
?
Wo beleidige ich hier denn schon wieder? Und wieso sollte irgendwer über Beleidigungen lachen, ich mich darüber wundern!? Willst Du auf "Grüße vom Planeten Erde" raus? Darüber konnte ich lachen, das reicht mir vollkommen und das Posting hatte es definitiv verdient veräppelt zu werden, zumal ich auch ernsthaft argumentiert habe. Als Beleidigung sehe ich das nicht, wer Winkel in Quadratmetern rechnet, muss auch mit entsprechenden Comments rechnen.Auch wenn du das nicht Beleidigung nennen willst, es ist eine. "Comments"... was für ein herrlicher Versuch, die wahre Bedeutung hinter einem Anglizismus zu verstecken!
Xin schrieb:
Mr. N schrieb:
Zum Thema "Wissen, das man nicht braucht"... wer nutzt enum-Klassen, weil er denkt, enum wäre nicht typsicher?
Keine Ahnung, ich nutze enum äußerst selten, weil sie keinen Namensraum erzeugen. Außerdem - und das habe ich in diesem Thread erfahren, sind sie nur in C mit int typisiert. Deswegen sind sie dennoch nur bedingt einsetzbar, denn sie erzeugen immernoch keinen eigenen Namensraum.
Du hättest selber wissen müssen, dass enums nicht mit int typisiert sind. Das ist "Basiswissen C++".
Xin schrieb:
Mr. N schrieb:
Wer glaubt, ein C++-Optimierer könne nicht optimieren, was erwiesenermaßen optimiert wird? Du hast deine Pflicht, dich auf dem laufenden Stand zu halten sträflich vernachlässigt und ...
Du übernimmst also die Garantie, dass "ein" C++-Optimierer das (was war's noch gleich?) erwiesenermaßen optimieren kann.
Was ist "ein"? Irgendein? Gilt das für genau einen oder alle? Und wenn es nur für einen gilt, dann ist es kein C++ Optimierer, sondern ein GCC-C++-Optimierer.
Garantierst Du die Optimierung für GCC, Intel, MSVC, Watcom, StormC++, SAS/C++, dem Digital Mars Compiler, und die etlichen Compiler, die sonst noch nachweislich entwickelt wurden?Wenn ein Compiler schlechter ist als ein anderer, dann nehme ich eben den besseren. Also reicht es, zu wissen, dass GCC das kann. Bei anderen Compilern kann ich es nicht prüfen, da ich sie nicht habe.
Wenn dir das nicht reicht, prüf es selber! Du hast deine Aussage, dass Division nicht optimierbar sei, selbst zu belegen, ich muss sie nicht für jeden einzelnen Compiler widerlegen.
Xin schrieb:
Habe ich die Pflicht vernachlässigt, mich auf dem Laufenden zu halten, in dem ich erstmal davon ausgehe, dass leichter zu optimierende Dinge von mehr Compilern geschluckt wird, als schwierigere?
Es ist nicht erwiesen, dass der Ausdruck wirklich schwerer zu optimieren ist.
Xin schrieb:
Oder warst Du etwas vorschnell, als Du diese Äußerung schriebst?
Nein.
Xin schrieb:
Mr. N schrieb:
CStoll und Shade Of Mine sind - ganz im Gegensatz zu mir, das gebe ich gerne zu - nicht kindisch, sondern überaus konstruktiv und bereit zu einer ernsthaften Diskussion gewesen.
Stopp...!?
Du sagst, Du hast Dich hier kindisch verhalten. Das finde ich erstmal gut, das einzugestehen, das ist nämlich mal etwas Konstruktives, was von Dir kommt. Das kann ich respektieren.
Gut, nur ich kann dich nicht respektieren.
Xin schrieb:
Nimm's mir nicht übel, wenn ich diese Äußerung trotzdem konsequent weiterführe: Du sagst damit nämlich auch, dass es hier durchaus einen Forumskindergarten gibt: Leute, die kindisch sind.
Ergo kann meine Aussage, dass hier ein Forumskindergarten existiert keine Beleidigung sein, denn Du stimmst mir ja zu, dass hier Leute sind, die noch kindisch sind und führst Dich selbst als Beispiel an.Dreh nicht deine eigenen Worte im Mund herum. Du hast nicht nur mir, sondern allen vorgeworfen, ein Kindergarten zu sein. Pauschal. Und das ist eine Beleidigung.
Xin schrieb:
Darf ich fragen, ob ein Meldung der "Unregistrierten" auch von Dir stammt und bekomme von Dir dann ein ehrliches "Nein"? Ich akzeptiere ein ehrliches "Nein", ich respektiere ein ehrliches "Ja".
Ja, eine Aussage eines Unregistrierten stammt von mir, aber bei weitem nicht alle. (Ich saß an einem Rechner, an dem ich mich nicht unbedingt einloggen wollte, zuhause schreibe ich immer als Registrierter.)
Xin schrieb:
CStoll und Shade haben sicherlich versucht konstruktiv zu diskutieren. Mit etlichen Ausrutschern,
Nein, ohne Ausrutscher. Du bist ausgerutscht. (Und von mir reden wir einfach gar nicht, ok?)
Xin schrieb:
aber der Versuch wurde durchaus bemerkt, oder meinst Du ich texte hier über die ganze Zeit mit für den Schwachsinn, den die meisten Unregistrierten hier abladen? Wenn der Versuch nicht erkennbar wäre, wäre ich schon lange nicht mehr hier.
Von wegen. In anderen Threads hast du gleich mehrfach behauptet, nicht mehr da zu sein, und es kam immer noch eine Antwort von dir.
Xin schrieb:
Und klar habe ich nicht immer die perfekte Laune, um ohne zynischen Kommentar jedem mit einem Lächeln den Kopf grade zu rücken.
Rücke dir lieber selbst den Kopf gerade. "Zynisches Kommentar" werte ich als Euphemismus für "Beleidigung".
Xin schrieb:
Du wirst also sicher auch böse Kommentare von meiner Seite finden, ich wage aber zu bezweifeln, dass Du etwas Nennenswertes findest, bevor ich beleidigt werde.
Ich werde deine inhaltslosen Romane nicht durchforsten.
Xin schrieb:
Mr. N schrieb:
Wider besseres Wissen, denn das ist mit dir nicht möglich.
Die Aussage ist mit einem Gegenbeispiel widerlegt und die gibt es zu genüge.
Du kannst mit mir nicht konstruktiv diskutieren. Das liegt natürlich an mir, denn Du bist derjenige, der grade behauptet hat, sich kindisch zu verhalten.
Steht der Bann in #cpp noch?Genau das meine ich. Dieser exemplarische Seitenhieb tut nichts zur Sache und zeigt, dass man mit dir nicht diskutieren kann.
Xin schrieb:
Wenn Du Dich wie ein Erwachsener verhältst und mich darauf hinweisen kannst, dass Du dem Forumskindergarten entwachsen bist, dann habe ich kein Problem Dich neutral anzusprechen.
Selbstreflektion ist nicht dein Ding?
---------
CStoll schrieb:
(die gelegentlichen Einwürfe von unregistrierten hier im Thread nerven mich wohl genauso wie dich - aber ich bemühe mich, sie zu ignorieren.)
Da einige Unregs (und nicht nur mein Post als Unreg) durchaus sinnvolle Dinge gesagt haben, ist das kontraproduktiv.
-
Mr. N schrieb:
CStoll schrieb:
(die gelegentlichen Einwürfe von unregistrierten hier im Thread nerven mich wohl genauso wie dich - aber ich bemühe mich, sie zu ignorieren.)
Da einige Unregs (und nicht nur mein Post als Unreg) durchaus sinnvolle Dinge gesagt haben, ist das kontraproduktiv.
OK, wenn du das in den falschen Hals bekommen hast, entschuldige ich mich - und präzisiere meine Aussage: Ich bezog mich nicht auf alle unregistrierten, die sich hier geäußert haben, sondern auf so "sinnvolle" Beiträge wie "aha, mhm, aah, ich merke." - oder "[Zitat vom Vorgänger]
". Xin schien solche Einwürfe sehr persönlich zu nehmen.(PS: Seitdem ich hier einen Account habe, habe ich nicht mehr als unreg gepostet - soviel Zeit habe ich noch, daß ich micht vor einer Antwort einloggen kann)
-
CStoll schrieb:
(PS: Seitdem ich hier einen Account habe, habe ich nicht mehr als unreg gepostet - soviel Zeit habe ich noch, daß ich micht vor einer Antwort einloggen kann)
Vielleicht will man nicht überall seine Login-Daten und Cookies rumliegen lassen? Naja, was solls.
-
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
du willst nicht konstruktiv diskutieren
-
Xin schrieb:
Das ist nicht notwendig, aber es ist wirklich leichter Professionalität zu erreichen, indem man Halbwissen über Programmierung abschaltet - ob durch entsprechende Bildung oder indem man wirklich eine Grenze einbaut, die man man als Professioneller problemlos überschreiten kann und als Halbwissender nicht überschreiten möchte.
Professionalität erreicht man dadurch, in dem man lernt, 1000 Codezeilen gleichzeitig zu überblicken und nicht durch "immer nur eine zur Zeit".
Xin schrieb:
Nein, nicht alles.
Aber an das, was besser war, könnte man sich gelegentlich erinnern und sich fragen, warum hat sich das verschlechtert?Aber Du solltest das "früher" nicht so weit nach hinten setzen. "Früher" heisst heute bereits "Vor 2 Jahren" und nicht "Vor 20 Jahren".
Xin schrieb:
Fortschritt bedeutet eben auch Rückschritt zu vermeiden und dafür muss nunmal in beide Richtungen schauen.
Fortschritt bedeutet immer "Rückschritt vermeiden".
-
Undertaker schrieb:
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
du willst nicht konstruktiv diskutieren
Das war nicht auf dich bezogen.
- Deine Meinung ist zwar oft das genaue Gegenteil von meiner, aber du hast noch nie jemanden beleidigt, wenn ich mich richtig erinnere.
-
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Wir haben das, was ich vorgeschlagen habe, als Grenze des praktisch machbaren, vor ~15 Seiten im Detail durch Unit verbessert. Wir haben CStolls Klassen, die gleichwertig sind. Er macht das gleiche wie ich, er erzeugt sie nur über ein Template. Ich habe nie verboten, meine Klassen per Template zu erzeugen.
Wir haben eine theoretisch perfekte Lösung.Ich mache nicht das gleiche - ich frage den Programmierer, ob er wirklich mit nackten int-Werten hantieren will.
Ich lasse ihn und verbiete ihm die implizite Zuweisung. Das Ergebnis ist, dass er sich damit auseinandersetzen muss, wie er etwas ausdrückt, um zuweisen zu können. Solange er nur rumrechnet und nichts zuweist, kann er keinen Programmfehler auslösen.
5+Meter( 4 );ist eine gültige Anweisung und selbst wenn Dir das nicht gefällt und Du sagst, es ist nicht typsicher... den Compiler interessiert es nicht, die Anweisung ist sinnlos, legal und ungefährlich.
Ich greife nur an dem Punkt ein, wo es gefährlich werden kann: der Zuweisung.In Hoffnung ...
Du sagst es ja selbst, du kontrollierst nur bei der Zuweisung, indem du dich auf explicit CTors beschränkst. Man hat somit nur die Kontrolle das irgendein Typ verloren gegangen ist.
Bei Variante B (Shade/CStoll) bekommt man die Information wann, wo, welcher Typ verloren geht.Wenn also der Verlust eines Typs zu einem falschen Ergebnis führt, dann wird das bei Variante B (Shade/CStoll) immer bemerkt, bei dir aber nur, wenn eine explizite Zuweisung vorher nicht nötig war.
Beispiel (altbekannt):
Unit() u = Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4)
Die Zuweisung macht man immer, weil man durch Baum(4) + Haus(3) schon den Typ verloren hat, dass auch der Typ Millimeter(4) verloren geht kann übersehen werden, weil vom Compiler nicht bemängelt.
Bei Variante B bekommt man zu jedem einzelnen Typverlust einen passenden Fehler.Dein Gegenargument ist es zu sagen Millimeter und Meter sind dann total schlecht und sowas macht man nciht, falsches Design ... bla.
Dazu das Argument, dass der Programmierer ja drauf achten muss und es schon genug Deppen gibt die programmieren. Man muss halt darauf achten welcher Typ verloren geht.Der Punkt ist aber, dass Millimeter/Meter nur ein Beispiel dafür ist, dass es einen Unterschied geben kann zwischen:
1: TypA(3) + TypA(3) + Unit(0)
2: TypA(3) + Unit(0) + TypA(3)
Sobald 1 und 2 unterschiedliche Ergebnisse liefern ist eine potentielle Fehlerquelle geboren.
Wie gesagt, Millimeter/Meter war nur ein Beispiel dafür, dass ein Typverlust zu einem falschen Ergebnis führen kann und das Beispiel ist dazu noch sehr sehr einfach gehalten.Folglich:
Eine Beschränkung auf Typen, bei denen 1 und 2 das selbe Resultat liefern (also auf Typen, bei denen ein Typverlust zu keinem falschen Ergebnis führt), oder die ehrenvolle Aufgabe keinen Typenverlust zu übersehen, nehme ich nicht hin, wenn eine Variante B (CStoll/Shade) existiert die damit keine Probleme hat und mich rundum versorgt!
Warum sollte man das auch?
Und wieso ist deine Variante dennoch das beste was wir hier haben?
-
Ich antworte mal kurz für Xin auf Tellerrand...
Such dir was aus:
Antwort 1: Es kann aber nicht zugewiesen werden und ist damit typsicher!
Antwort 2: Und auch du hast den expliziten Konstruktor nicht verstanden!
Antwort 3: Ihr habt gar nix!
Antwort 4: Kindergarten!
-
Xin ist für mich ein heißer Anwärter auf den "Troll des Jahres 2007" Award
-
Kleine Korektur:
Unit() u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4))
sollte es natürlich sein.
-
Tellerrand schrieb:
Kleine Korektur:
Unit***()*** u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4))
sollte es natürlich sein.Du meinst eher das?
Unit u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4));
-
Mr. N schrieb:
Undertaker schrieb:
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
du willst nicht konstruktiv diskutieren
Das war nicht auf dich bezogen. :)...
ich weiss, aber dein posting kam so rüber, als hätte dir Xin extrem auf den schlips getreten (ja fast schon gesprungen).
immer schön --> <-- bleiben.
-
Mr. N schrieb:
Du meinst eher das?
[...]Ja, so wäre es natürlich ordentlich.
Habe halt den CTor vergessen und der ist ja wichtig
-
Xin schrieb:
Es macht einen Unterschied eine Möglichkeit zu diskutieren oder "FACTS" (unregistriert, aber afair als scrub kenntlich gemacht), die einfach mal in den Raum posaunt werden.
Das war eigentlich ein kleines Wortspiel, das ich ganz witzig fand.
Xin schrieb:
Scrub war nebenher der einzige, der sagte, dass er unter unterschiedlichen unregistrierten Pseudonymen gepostet hat, aber nicht, um den Eindruck zu erwecken, dass mehr Leute gegen mich wären, sondern weil er davon ausgeht, dass jeder seine unterschiedlichen Nicks kennt. Ich kenne sie nicht.
Nicht "jeder", sondern Du- weil Du ihn ja sicher im Channel gelesen hast, als Du Dich dort wie ein verkleidetes Kind in den Kindergarten geschlichen hast.
Außerdem spielt hier für niemanden die Personenzahl eine große Rolle. Wäre Deine Argumentation überzeugend, störte sich niemand daran, daß Du allein bist. Aber Du überzeugst eben nicht mit Unkenntnis von enum oder mit dem immer noch im Raum stehenden Wortwechsel (CStoll)"Fenster haben Flags, sind aber keine Flags" - (Xin)"Man kann sich vieles von verschiedenen Perspektiven ansehen. Ich würde mich an Deiner Stelle nicht so allgemeingültig festlegen." -> (mathematiklegasthenisch veranlagter Informatiker[1])"Schon die Voraussetzungen sind falsch."[1] Jester
-
CStoll schrieb:
Und wieviel Anlernzeit bekommt jemand zugewiesen, um alle Eigenheiten deines Systems zu verstehen?
Da ich eigentlich immer das selbe mache, ist das Framework eigentlich ganz gut gelungen.
Da es eigentlich aber eh nur die Test-Version darstellt, bin ich für die Final eigentlich optimistisch.CStoll schrieb:
Xin schrieb:
CStoll schrieb:
(btw, wenn du jeden, der nicht deiner Meinung bist, dem "Forumskindergarten" zuordnest, hilft das der Diskussion überhaupt nicht.
Das tue ich nicht. Ich sage, dass hier eine Menge Kiddies rumlaufen.
Ich wiederhole immer wieder, dass man meine Lösungen nicht nehmen muss. Ich bin sogar dafür, dass sich jeder etwas eigenes entwickelt.
An den expliziten Ctors kommt man trotzdem nicht vorbei.
Wen ich in den Forumskindergarten schicke, der stellt mit fehlender Kenntnis von Fachwissen und fehlernder Kenntnis über bereits Geschriebenes innerhalb Threads Behauptungen auf, die sich keinen inhaltlichen Wert (mehr) haben. Es macht einen Unterschied eine Möglichkeit zu diskutieren oder "FACTS" (unregistriert, aber afair als scrub kenntlich gemacht), die einfach mal in den Raum posaunt werden.Und genau auf dem Niveau, das du hier bei anderen kritisierst (nicht nur an unregistrierten), diskutierst du selber.
Werde ruhig konkreter, ich höre zu.
CStoll schrieb:
(die gelegentlichen [edit] sinnfreien [/edit] Einwürfe von unregistrierten hier im Thread nerven mich wohl genauso wie dich - aber ich bemühe mich, sie zu ignorieren.)
Das ist einfacher, wenn man für toll erklärt wird statt beleidigt. ^^
CStoll schrieb:
Die Mehrdeutigkeit weist in C++ doch darauf hin, dass einer der Faktoren hakt. Also eigentlich hast Du damit doch genau das, was Du als fehlend kritisierst.
Afair kommen Dir dann nur noch die Fehlermeldung der Compiler in den Weg. Der GCC meckert bei derartigen Dingen zwar und nennt Möglichkeiten, sagt aber nicht warum es überhaupt geknallt hat.
Die Methode ist typsicher, denn sie ist nicht übersetzbar.Und dich sollte die Mehrdeutigkeit eher darauf hinweisen, daß etwas am grundlegenden Design nicht stimmt.[/quote]In C++ sicherlich. In der prinzipiellen Möglichkeit sicherlich nicht.
CStoll schrieb:
Xin schrieb:
CStoll schrieb:
(btw, wenn du darüber stolperst, daß man von int nicht ableiten kann - dann ersetze ich es gerne durch eine Pseudo-Int-Klasse)
Warum sollte ich jetzt meckern? Mein Part ist schließlich als Gedankenspiel von Möglichkeiten gestartet und nicht als C++-Produktivlösung. Das darf meinetwegen sogar noch ein Shade verwechseln, aber Du warst bei der Geburt des Gedankenspiels dabei... schon vergessen?
Und wieso betonst du dann in regelmäßigen Abständen, daß man in C++ nicht von int ableiten kann?
Um darauf hinzuweisen, dass ich nicht ausschließlich von C++ spreche? Dass Du ein Gedankenspiel angeleiert und dann kritisiert hast?
Weil Gedankenspiel und reine C++ Programmierung laufend durcheinander geworfen werden?CStoll schrieb:
Ja, niemand ist perfekt - aber in einer längeren Formel ist mir trotzdem eine Meldung "du kannst Längen und Gewichte nicht addieren" (bezogen auf einen Teilausdruck irgendwo in der Mitte) lieber als "du kannst einer Kraft keine nackte Unit zuweisen" (bezogen auf den Gesamtausdruck, bei dem der Compiler irgendwo aufgegeben hat, mit korrekten Einheiten zu rechnen).
Ich hab's mal ausprobiert. Der GCC liefert die Fehlermeldung jedenfalls nicht... der sagt "Geht nicht", such Dir eine Alternative aus folgnden operator Überladungen aus... <Liste>.
Das hilft jetzt nicht wirklich weiter.CStoll schrieb:
Und nichts gebracht, was wirklich weiter gehen würde.
Doch, habe ich - du hast die entsprechenden Teile meiner Antwort(en) nur gekonnt überlesen.[/quote]
Was war denn so wichtig, dass ich es trotzdem überlesen habe?CStoll schrieb:
OK, ich teile mal das Problem in zwei Teile auf:
Erstens: Einzelne Klassen gegen Templatelösung?
Einzelne Klassen zu schreiben ist aufwendig und potentiell fehleranfällig - also dürfte die Lösung in beiden Fällen darauf hinauslaufen, die Klassen automatisiert (via Template) anzulegen.Dann wiederhole ich mal, dass ich nicht verbiete, meine Klassen per Template zu erzeugen.
CStoll schrieb:
Zweitens: Besteht eine Verwandschaft zwischen verscheidenen Größen-Klassen?
Hier besteht noch eine (vorsichtig ausgedrückt) Unstimmigkeit zwischen unseren Lösungsansätzen - bei mir sind die einzelnen Klassen unabhängig voneinander und interagieren nur über die vorgegebenen Operatoren, du siehst eine Verwandschaftsbeziehung und rechtfertigst damit, alle physikalischen Größen auf int bzw. Unit zurückzuführen.Ich sehe eine "Verwandtschaft" darin, dass Objekte zählbar sind.
CStoll schrieb:
Der Quotient zweier (gleichartiger) Größen ist nunmal ein (einheitenloses) Größenverhältnis, das kannst du drehen und wenden wie du willst. Das ist möglicherweise eine Grenze der Physik, aber wenn alle Einheiten rausgekürzt sind, bleibt wirklich nur eine nackte Zahl zurück (der kannst du von mir aus ein 'rad' oder 'dB' dranschreiben, aber effektiv bleibt's eine nackte Zahl).
Wem erzählst Du das? Schreib das denjenigen, die aus Deinen Templates eine Einheit "Meter/Meter" hevorzaubern.
CStoll schrieb:
Xin schrieb:
Vielleicht war Dir aufgefallen, dass ich typsichere Versionen von cos usw. forderte, die Winkelgrade (ob die jetzt mit 0..2Pi oder Winkelgrade oder gon dargestellt werden, who cares) übergeben bekommen würden => expliziter Konstruktor => typsicher => Meter * Kg ist kein Winkelmaß => Compilermecker.
OK, was du vorne in cos() reinsteckst bzw. hinten aus acos() herausbekommst, ist ein Winkel. Aber in welcher Einheit misst du den Cosinus eines Winkels?
In der Einheit, die das Ergebnis der cosinus-Funktion bringt...?
Keine...
Was für eine Frage...<kopfschüttel>CStoll schrieb:
Xin schrieb:
Ich lasse ihn und verbiete ihm die implizite Zuweisung. Das Ergebnis ist, dass er sich damit auseinandersetzen muss, wie er etwas ausdrückt, um zuweisen zu können. Solange er nur rumrechnet und nichts zuweist, kann er keinen Programmfehler auslösen.
5+Meter( 4 );ist eine gültige Anweisung und selbst wenn Dir das nicht gefällt und Du sagst, es ist nicht typsicher... den Compiler interessiert es nicht, die Anweisung ist sinnlos, legal und ungefährlich.
Ich greife nur an dem Punkt ein, wo es gefährlich werden kann: der Zuweisung.Hast du mal daran gedacht, daß dieser Ausdruck nur selten alleine in der Landschaft steht?
Yepp... und weil man nichts verändern kann, spielt es bei der Typsicherung keine Rolle.
CStoll schrieb:
Ja, du hast ein Beispiel gebracht, wo du eine Ableitung von int sehen könntest. Aber um es mal auf den Punkt zu bringen: Du hast bisher niemanden hier davon überzeugt, daß diese Ableitung irgendeinen Vorteil bringen würde. Und wenn du es noch nichtmal bei "uns" schaffst, sehe ich schwarz für das ISO-Kommitee.
*lach*, ich habe nie gesagt, dass es einen Vorteil hätte.
Ich bin derjenige, der sagt, dass Komposition und Ableitung gleichwertig ist.
Ableitungen braucht kein Mensch, um irgendwas zu programmieren.
Du kannst absolut alles mit Komposition ausdrücken. Und du kannst auch alles in Ableitungen ausdrücken.
Ableitung ist eine Möglichkeit, die eine andere Sicht auf einen Datensatz erlaubt. Es ist ein Wechsel der Perspektive, nicht der Möglichkeiten.
Ob Du Ableitungen als Vorteil ansiehst...
Die Ableitung von int erlaubt die Sicht auf die Zahl, was die so Komposition so nicht erlaubt.
Und was das ISO-Komitee davon hält kann ich Dir sagen: man kann es durch eine Zwischenklasse abbilden und alles bereits abzubilden ist, wird nicht eingeführt oder geändert.
Ich persönlich halte von einer Sonderregelung für Primitive nichts; ich halte allgemein nichts von Sonderregelungen. Das Fehlen von Sonderregelungen vereinfacht eine Sprache.Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
Ich finde die Information recht ehrlich am Anfang Deines Postings. Du hast bewiesen, dass ich meine Aussage über den Forumskindergarten korrekt ist und entziehst damit jedem die Grundlage, der sich darüber beschwert, dass ich das so offen anspreche.
Deine Form von Ablehnung stützt meine Aussagen, wieso sollte ich gegen jemanden vorgehen, der meine Aussagen so eindeutig belegt?Tellerrand schrieb:
Xin schrieb:
Ich greife nur an dem Punkt ein, wo es gefährlich werden kann: der Zuweisung.
In Hoffnung ...
...
Tellerrand schrieb:
Beispiel (altbekannt):
Unit() u = Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4)
Die Zuweisung macht man immer, weil man durch Baum(4) + Haus(3) schon den Typ verloren hat, dass auch der Typ Millimeter(4) verloren geht kann übersehen werden, weil vom Compiler nicht bemängelt.
Bei Variante B bekommt man zu jedem einzelnen Typverlust einen passenden Fehler.Wie ich schon sagte - den Punkt halte ich für eine Geschmackssache. Ich halte eine Typkonvertierung auf einen Basistyp nicht zwangsläufig für einen Fehler. Also warte ich hier erstmal und gucke, was passiert.
Die Möglichkeit ist zum einen nicht verkehrt und zum anderen interessant.Tellerrand schrieb:
Dein Gegenargument ist es zu sagen Millimeter und Meter sind dann total schlecht und sowas macht man nciht, falsches Design ... bla.
Ich "blahte", dass mehrere Klassen für einen Zweck redundant sind. Redundanz ist in meinen Augen ein Designmangel, daher sollte Millimeter() eine Funktion, die auf Meter umrechnet, und kein Konstruktor sein - wie immer "Meter" auch implementiert ist.
Tellerrand schrieb:
Der Punkt ist aber, dass Millimeter/Meter nur ein Beispiel dafür ist, dass es einen Unterschied geben kann zwischen:
1: TypA(3) + TypA(3) + Unit(0)
2: TypA(3) + Unit(0) + TypA(3)
Sobald 1 und 2 unterschiedliche Ergebnisse liefern ist eine potentielle Fehlerquelle geboren.Kommt doch in beiden Unit(6) raus? Keine unterschiedlichen Ergebnisse, also keine potentielle Fehlerquelle!?
Tellerrand schrieb:
Eine Beschränkung auf Typen, bei denen 1 und 2 das selbe Resultat liefern (also auf Typen, bei denen ein Typverlust zu keinem falschen Ergebnis führt), oder die ehrenvolle Aufgabe keinen Typenverlust zu übersehen, nehme ich nicht hin, wenn eine Variante B (CStoll/Shade) existiert die damit keine Probleme hat und mich rundum versorgt!
Warum sollte man das auch?
Und wieso ist deine Variante dennoch das beste was wir hier haben?Was die Typsicherheit angeht, macht CStoll das gleiche wie ich. Das ist gleichwertig. Mehr geht nicht. Wir kompilieren beide falsche Typzuweisungen nicht.
Was die Reihenfolge der Kombinationen angeht, erlaube ich mehr als CStoll. Die Ableitungen erlauben das. Ich finde das nicht schlimm, eigentlich sogar interessant, weil es eben das Zählen von Objekten erlaubt.
Ihr seht das anders, kein Problem. Es ist eine Geschmackssache.
Typsicher ist beides. CStoll löst es über die Komposition, ich über die Ableitung. Andere Unterschiede gibt es nicht.Tellerrand schrieb:
Kleine Korektur:
Unit u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4))
sollte es natürlich sein.Unter Berücksichtigung der von mir genannten Funktion Millimeter() kommt u = 19.004 Unit raus, unabhängig davon, ob Du Unit explizit aufführst oder nicht. (Natürlich nicht, wenn die Basis wirklich int wäre, dann käme 19 raus).
scrub schrieb:
Xin schrieb:
Scrub war nebenher der einzige, der sagte, dass er unter unterschiedlichen unregistrierten Pseudonymen gepostet hat, aber nicht, um den Eindruck zu erwecken, dass mehr Leute gegen mich wären, sondern weil er davon ausgeht, dass jeder seine unterschiedlichen Nicks kennt. Ich kenne sie nicht.
Nicht "jeder", sondern Du- weil Du ihn ja sicher im Channel gelesen hast, als Du Dich dort wie ein verkleidetes Kind in den Kindergarten geschlichen hast.
Nopes, ich kannte ihn nicht.
Bevor Du mir die E-Mail geschrieben hast, wo Du Dich auch unter Deinem anderen Nick geoutet hast, wußte ich nicht, dass Du mehr als einen Nick verwendest. Ich habe nur den Bildschirm hier, keine Kristallkugel. Und ich führe auch nicht Buch über jeden einzelnen Nick, also nehme ich Dich mit einem anderen Nick als neue Person wahr.scrub schrieb:
Außerdem spielt hier für niemanden die Personenzahl eine große Rolle.
Posten hier mehr Nicks als Personen, dann verschiebt sich das Meinungsverhältnis.
Damit verliert auch die "wir"-Schreibweise an Wert, weil gar nicht mehr geklärt ist, wieviele "wir" eigentlich sind.
Ich poste hier ausschließlich unter diesem einem Nick. Du unter verschiedenen, was ich für ziemlich daneben halte. Inzwischen schreibst Du Deinen Namen drunter, was die Sache immerhin nachvollziehbar macht - so witzig finde ich es deswegen nicht.
-
Xin schrieb:
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
Ich finde die Information recht ehrlich am Anfang Deines Postings. Du hast bewiesen, dass ich meine Aussage über den Forumskindergarten korrekt ist und entziehst damit jedem die Grundlage, der sich darüber beschwert, dass ich das so offen anspreche.
Deine Form von Ablehnung stützt meine Aussagen, wieso sollte ich gegen jemanden vorgehen, der meine Aussagen so eindeutig belegt?Du kannst MIR "Kindergartenverhalten" vorwerfen, ABER NICHT DEM FORUM.
-
Mr. N schrieb:
Xin schrieb:
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
Ich finde die Information recht ehrlich am Anfang Deines Postings. Du hast bewiesen, dass ich meine Aussage über den Forumskindergarten korrekt ist und entziehst damit jedem die Grundlage, der sich darüber beschwert, dass ich das so offen anspreche.
Deine Form von Ablehnung stützt meine Aussagen, wieso sollte ich gegen jemanden vorgehen, der meine Aussagen so eindeutig belegt?Du kannst MIR "Kindergartenverhalten" vorwerfen, ABER NICHT DEM FORUM.
Du gehörst definitiv dazu, was den Rest angeht:
Xin schrieb:
Ich weiß nicht, warum sich hier jemand aufregt, wenn ich von Kindergarten spreche.
Wer sich darüber aufregt und in den Unmengen der Mitglieder keine Kiddies findet, die sich um ihre Schäufelchen kloppen, da denke ich, dass diejenigen sich fragen könnten, warum ihnen die Kiddies nicht auffallen...Ein anderer Moderator wies mich allerdings schon freundlich darauf hin, dass hier nicht nur Kiddies rumtexten. Die Erfahrung ist mir nicht entgangen. Leider nur seltener als ich hoffte.
Hau ab (Unregistriert) schrieb:
Xin, hau ab, und komm nicht wieder.
So gering ist die Quote dann zum Glück auch nicht. Tut mir leid...
Schönen Abend noch.
-
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Vielleicht war Dir aufgefallen, dass ich typsichere Versionen von cos usw. forderte, die Winkelgrade (ob die jetzt mit 0..2Pi oder Winkelgrade oder gon dargestellt werden, who cares) übergeben bekommen würden => expliziter Konstruktor => typsicher => Meter * Kg ist kein Winkelmaß => Compilermecker.
OK, was du vorne in cos() reinsteckst bzw. hinten aus acos() herausbekommst, ist ein Winkel. Aber in welcher Einheit misst du den Cosinus eines Winkels?
In der Einheit, die das Ergebnis der cosinus-Funktion bringt...?
Keine...
Was für eine Frage...<kopfschüttel>Hat es dich jetzt völlig gepackt?
CStoll versucht dir seit Stunden zu erklären, dass er es problematisch wird, wenn gewisse Größen ohne Einheit auftauchen, du konterst mit "Wir geben dem Winkel einfach ne Einheit", jetzt fragt er dich rhetorisch welche Einheit der Cosinus eines Winkels hat und du antwortest ihm völlig selbstverständlich "keine" und lachst ihn quasi noch aus? Verstehst du eigentlich ein Wort, von dem, was er sagt?
Und das Meter/Meter hast du offensichtlich auch nicht verstanden.
-
Mich versteht er auch nicht
-
Xin schrieb:
Tellerrand schrieb:
Der Punkt ist aber, dass Millimeter/Meter nur ein Beispiel dafür ist, dass es einen Unterschied geben kann zwischen:
1: TypA(3) + TypA(3) + Unit(0)
2: TypA(3) + Unit(0) + TypA(3)
Sobald 1 und 2 unterschiedliche Ergebnisse liefern ist eine potentielle Fehlerquelle geboren.Kommt doch in beiden Unit(6) raus? Keine unterschiedlichen Ergebnisse, also keine potentielle Fehlerquelle!?
Nein!
Wie gesagt, Millimeter ist ein Beispiel.
Millimeter(3) + Unit(3) + Meter(3) => Unit(9)
Millimeter(3) + Meter(3) + Unit(3) => Unit(6,03)
Sowas kann verschiedene Ergebnisse liefern, kommt eben drauf an welche Operanden wie überschrieben wurden.
Und das Operanden wie Meter() * Meter() einen neuen Typ wie Quadratmeter() liefern ist ein Vorteil den auch du vorgebracht hast.
Jetzt liefert dein Design Fehlerquellen, sofern man mit Typen hantieren will, welche z.B. die standard addition überschreiben.Das ist bei allen wertverwandten Einheiten der Fall, wie z.B. Joule & WH & Nm, km/h & m/s, etc
Dann auch bei den "Konstanten" (falls man sie als Einheit behandeln muss) c, e, etc.
Sowie bei allen Einheiten, welche nicht aus den Basis SI-Einheiten zusammengesetzt sind, sondern sich z.B. durch cm, oder anderes defineiren.
Dann bleiben da noch höhere Formeln z.B. aus der Relativitätstheorie.
Und so weiter ...Allgemein gesagt, du hast die Fehlerquelle bei allen Typen, welche durch einen Typverlust falsch verrechnet werden können.
Und das sind nicht nur redundante EinheitenAls Fazit muss ich da leider sagen, Basis Physik ist damit noch recht gut machbar. (Wenn man sich auch an die Einschränkungen gewöhnen muss)
Aber tieferes will ich damit nicht umsetzen müssen.Xin schrieb:
Was die Typsicherheit angeht, macht CStoll das gleiche wie ich. Das ist gleichwertig. Mehr geht nicht. Wir kompilieren beide falsche Typzuweisungen nicht.
Ja, beschränkt auf Typzuweisungen hebt sich das eine vom anderen nicht ab.
Das jedoch mehr geht als Kontrolle bei der Zuweisung haben CStoll und Shade gezeigt!
(Kontrolle bei den Operatoren)Dann halt nochmal:
Tellerrand schrieb:
Eine Beschränkung auf Typen, bei denen 1 und 2 das selbe Resultat liefern (also auf Typen, bei denen ein Typverlust zu keinem falschen Ergebnis führt), oder die ehrenvolle Aufgabe keinen Typenverlust zu übersehen, nehme ich nicht hin, wenn eine Variante B (CStoll/Shade) existiert die damit keine Probleme hat und mich rundum versorgt!
Warum sollte man das auch?
Und wieso ist deine Variante dennoch das beste was wir hier haben?
