Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[Gast]

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

[Mr. N]

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.

[Tellerrand]

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?

[Kurzer Witz am Rande]

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!

[Jurymitglied]

Xin ist für mich ein heißer Anwärter auf den "Troll des Jahres 2007" Award

[Tellerrand]

Kleine Korektur:
Unit() u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4))
sollte es natürlich sein.

[Mr. N]

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

[Undertaker]

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.

[Tellerrand]

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

[scrub]

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

[Xin]

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.

[Mr. N]

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.

[Xin]

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.

[Theston]

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.

[2 + 2 = 5]

Mich versteht er auch nicht

[Tellerrand]

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 Einheiten

Als 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?

[Xin]

Theston schrieb:

Und das Meter/Meter hast du offensichtlich auch nicht verstanden.

Und mein Schäufelchen darfst Du auch nicht haben.

Tellerrand schrieb:

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)

In dem Fall kommt immer Unit(6,003) raus, weil Millimeter() kein Konstruktor sein darf, sondern eine Umrechnungsfunktion auf Meter, andernfalls hast Du zwei unhänge, aber redundante Typen.
Ich mache überhaupt keine Konvertierung über Operatoren!
Unterschiedliche Daten, die auf einer einzigen Dimension dargestellt werden, was eine Fehlerquelle darstellt.
Und Redundanz ist böse, also lassen wir das.

Definierst Du Millimeter als eigenständigen Typ, der vollkommen unabhängig von Meter existiert, Du betonst also, dass Meter und Millimeter überhaupt keine Gemeinsamkeiten besitzen, Meter und Millimeter haben eigene Dimensionen, so kommt immer Unit(9) raus.
Dann sind die Typen aber auch absolut nicht verwandt.

Es liefert immer eindeutige Ergebnisse, je nachdem ob Du Millimeter als Verwandtschaftsverhältnis zu Meter ausdrückst oder als eigene Datenklasse.

Tellerrand schrieb:

Dann halt nochmal:

Ich könnte darauf nun auch meine Antwort wiederholen, aber was hätte das für einen Sinn?

[CStoll]

Xin schrieb:

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.

Hast du es schonmal versucht, jemand anderen in das System einzuarbeiten?

Xin schrieb:

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.

Liest du dir deine Postings überhaupt durch? Seit Seiten versuche ich, dir zu erklären, warum Design der falsche Weg ist - mit dem Erfolg, daß du genauso lange alle (konstruktiven) Argumente wahlweise als "sinnloses Blabla" einstufst oder gleich ganz ignorierst. Klar, auf diese Weise wirst du deine Ansätze recht gut bestätigt finden, aber eine sinnvolle Diskussion erreichst du damit nicht.

Xin schrieb:

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.

In C++ sicherlich. In der prinzipiellen Möglichkeit sicherlich nicht.

Wenn du eine eigene Sprache erfinden willst, bist du völlig frei, was für ein Design sie unterstützt - aber hier geht es immer noch um C++ (bzw. hypothetische Erweiterungen von C++).

Xin schrieb:

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.

Ich habe hier zwar keinen Compiler zur Hand - aber ich könnte wetten, daß er genau den Teilausdruck kritisieren würde, bei dem die Datentypen nicht zusammenpassen.

Xin schrieb:

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.

Was war denn so wichtig, dass ich es trotzdem überlesen habe?

In Kurzfassung: Ich habe einen Ansatz, der keine impliziten Umwandlungen erlaubt, wo Typinformationen verloren gehen könnten. Also ist der Entwickler in der Pflicht, dem Compiler mitzuteilen "Ja, genau hier habe ich vor, die Typinformationen aufzugeben".

Xin schrieb:

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.

OK, dann sind wir uns wenigstens in einem Punkt einig.

Xin schrieb:

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.

Objekte (Butterbrote, Häuser, Autos etc) sind eventuell zählbar (selbst da hängt davon ab, wer damit umgehen will), physikalische Größen sind nicht zählbar, sondern bestenfalls messbar.

Xin schrieb:

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

Gut erkannt - das bedeutet, die Rechnung "alpha = acos(distanz/hoehe);" ist absolut legal (eine einheitenlose Größe kommt vorne rein - der ArcCos macht daraus einen Winkel), die Rechnung "alpha = acos(laenge*gewicht);" ist physikalisch sinnlos (ein "kg*m" kommt rein, aber ArcCos erwartet eine einheitenlose Größe) - wird aber bei deinem Ansatz kommentarlos geschluckt.

Xin schrieb:

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.

Doch, spielt es - im größeren Zusammenhang wird der Typ/Einheit meiner Daten wieder gebraucht, um vernünftig weiterrechnen zu können.

Xin schrieb:

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

Ableitungen und Kompositionen sind eben nicht gleichwertig (vielleicht solltest du Meyers mal gründlich lesen, um die Unterschiede zu verstehen), ihre "Effekte" überschneiden sich gelegentlich in einigen Bereichen. (öffentliche) Ableitung steht zumindest in C++ für eine "ist ein" Beziehung, Komposition für "hat ein" oder "nutzt".
(ein PKW "ist" ein Auto und "hat" vier Räder, einen Motor etc)

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?

Mr.N hat vielleicht zugegeben, daß er sich "kindergartenhaft" verhält, bei einigen Unregs könnte man das aus dem Verhalten schließen - aber du stufst hier ja jeden als "Kindergarten" ein, der nicht deiner Meinung ist.

Xin schrieb:

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.

Warst du es oder Shade, der über die fehlende Genauigkeitsskalierung bei einer einzelnen Einheit debattiert hatte (um Häuser zu entwerfen, ist Millimeter zu fein aufgelöst, für elektrische Schaltungen zu grob)? Wie willst du das Problem behandeln, wenn du nur eine Klasse für Längen-Angaben hast?

Xin schrieb:

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.

Ja, du erlaubst mehr Kombinationen als ich - und viele davon sind physikalisch/technisch sinnlos.

Um nochmal auf dein "Produktivsystem" zurückzugehen, da ist anscheinend eine Frage untergegangen:
Ein ScreenObject (Fenster o.ä.) hat fünf "interessante Punkte", die ich abfragen und setzen möchte - vier Ecken und das Zentrum. Wie willst du (basierend auf der Ableitung von fünf Point-Derivaten) dafür sorgen, daß die Form des Objekts rechtwinklig bleibt?

[Shade Of Mine]

Theston schrieb:

Verstehst du eigentlich ein Wort, von dem, was er sagt?

Ne, das ist das Problem.

Manche Leute wollen ihre Meinung nur bestätigt hören, bzw ihre Meinung mitteilen. An konstruktiven Erkenntnissen sind sie nicht interessiert. Das führt zu gewissem Verhalten.

Zum Beispiel Argumente als falsch hinzustellen ohne es belegen zu können und generell den anderen Leuten Unwissenheit vorzuwerfen. Es hat keinen Sinn da zu diskutieren denn Niemand wird Xin auch nur dazu bringen sein Design in Frage zu stellen. Sein Design ist für ihn perfekt und auch nur daran zu denken nochmal zu überlegen ist nicht vorstellbar.

Wenn ich mir dagegen die Diskussionen in #cpp ansehe - da klatschen oft genug unterschiedliche Designvorstellungen aufeinander (das ist ja im Prinzip sogar etwas gutes). In den meisten Fällen wird ein Konsens gefunden - manchmal nicht. Der Punkt aber ist, dass beide Seiten versuchen die Gedankengänge des anderen zu verstehen. Oft gibt es mehrere gute Ansätze um ein Problem zu lösen - wenn man mehrere Blickwinkel vereint kann man einen sehr guten Ansatz finden.

Hier aber ist das Problem, dass Xin einen starren Blickwinkel hat der sich nicht ändern lässt. Sein Design hat Mängeln - und natürlich auch nette Features - man müsste nun versuchen die Features zu erhalten und gleichzeitig die Mängel zu beseitigen. Wenn aber ein abblocken oder leugnen der Mängel stattfindet, ist eine Unterhaltung fruchtlos.

[Gast]

Hallo

Xin macht den gleichen Fehler, den er den Großen der Zunft vorwirft. es ist beratungsresistent. Er gibt es aber nicht zu. Ere tarnt es einfach dadurch, dass er anderen Unkenntnis unterstellt oder ihnen vorwirft im Kindergarten zu sein. Er hat recht und alle anderen eben nicht . Ein Verschwörungstheoretiker. Je mehr seinen Ansatz schlecht finden, um so besser ist er. Je mehr Leute Fehler finden um so mehr fühlt er sich bestätigt. Dann kommt im jedem Thread, dass ihn das alles nervt und alle eh bloß keine Ahnung habne und wir doch dankbar sein sollen, dass er er hier kostenlosen Untericht gibt. desweiteren kündigt er an nicht ehr mitzuschrieben, um es dann doch wieder zu tun, weil das Sendungsbeweusstsein wohl zu groß ist. Ich glaube er scheibt nur, um überhaupt wahr genommen zu werden.

chrische