Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[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

[Xin]

CStoll schrieb:

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

Eigentlich nicht. Wie gesagt, es gibt nur drei Personen, die es zur Zeit benutzen und da kamen bisher wenig Rückfragen.

CStoll schrieb:

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

Komisch... wenn ich meine Postings lese, lese ich da, dass Du das gleiche machst, wie ich, aber keinen Schritt kommst, als ich. Ich spreche von gleichwertig. Unsere "Ansätze" unterscheiden sich bei Komposition/Vererbung und das war's. Ich würde nichtmals sagen, ob wir überhaupt von "Deinem"/"meinem" Ansatz sprechen können.

Du bringst vereinzelt Punkte, wo die Beibehaltung der Typsicherheit durch die Operatoren geringfügige Vorteile bringt (s.u.), aber den schätze ich nicht wichtiger ein, als die Möglichkeit Objekte zu zählen. Es bleibt bei einer Geschmackssache.

Ich lese mir meine Postings durch und ich lese mir auch Deine Postings durch.
Was wir (Du und ich) hier machen, ist uns über eine Geschmacksfrage in die Wolle bekommen, ausgehend davon, dass ich auf die Schnelle mal ein Beispiel für die Ableitung von int reinwerfen sollte - nicht gleich ein perfektes Typsystem. Seitdem pfefferst Du dagegen und das meiste stimmt so nicht, jedenfalls hast Du nichts, was über Geschmackssache hinausgeht.

Ganz ehrlich: Ich übernehme gerne das bißchen mehr Verantwortung, um mich dafür ein ganzes Stück freier bewegen zu können.
Die Ableitungen sind nicht schlecht, sie sind eine andere Möglichkeit, die Dinge zu sehen und sie funktionieren deutlich besser als nichts zu machen. Und das tun sie, egal, wie sehr Du Dich für andere Lösungen stark machst, das ist die Position, die ich hier erst freigebe, wenn Du oder sonstwer etwas wirklich Nennenswertes bringst.
Solange verteidige ich es eine Möglichkeit unter anderen Möglichkeiten.

Daher sind auch alle Rückschlüsse unsinnig, die sich auf meine Programmierung beziehen oder ob mein Framework kompliziert oder nicht wäre.

CStoll schrieb:

Xin schrieb:

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

Dann habe ich ja alles mitbekommen.

CStoll schrieb:

Xin schrieb:

Dann wiederhole ich mal, dass ich nicht verbiete, meine Klassen per Template zu erzeugen.

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

*lach* und das zu erkennen hat bis hierhin gedauert? Ich schrieb es schon ein paar mal.
Naja, auch kleine Fortschritte führen hoffentlich zu einem baldigen Ende hier.

CStoll schrieb:

Xin schrieb:

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.

Selbstverständlich. Und ich mache keine Unterschiede zwischen zählbar und meßbar. Du auch nicht.
Ich kann sie machen, aber meine ursprüngliche Aufgabe waren Beispiele für Ableitungen von int zu geben und nicht ein ganzes Typsystem aufzubauen. Ich soll jetzt nicht wirklich noch mal eben zwei Klassen dazwischensetzen, oder?

CStoll schrieb:

Xin schrieb:

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.

Korrekt. Das ist ein Argument. (<- man beachte!)

Und dann kommt man zu der Frage der Wertung. Es spricht definitiv für Deinen Ansatz. Die größere Freiheit beim Zählen von Objekten für meinen. Wie oft zählt man Objekte, wie oft muss man sich dem Risiko des acos aussetzen?

Für einen wirklichen Vorteil, reicht's bei beiden nicht. Es bleiben zwei gleichwertige Möglichkeiten, die die entsprechend ihres Aufbaus (Vererbung oder Komposition) sich in einigen Details unterscheiden.
Wer was nimmt, ist eine Geschmacksfrage.

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

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.

Es gibt keinen größeren Zusammenhang, weil Du nichts änderst, denn dafür müsstest Du irgendwann zuweisen.

CStoll schrieb:

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)

Das hatten wir alles schonmal. Sie sind gleichwertig, mit Ableitungen muss man lediglich etwas anders damit arbeiten, als üblich, vergleichbar mit Dot-COM-Programmierung.

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

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.

DAS halte ich für Kindergartenverhalten.

Da habe ich gestern abend noch auf MrN geantwortet, dass das eben nicht der Fall ist. Derartiges legt ihr mir - der Tatsache zum Trotz, dass ich das Gegenteil schrieb - in den Mund und anschließend kommen die Unregs und erzählen sich einen.

Das ist der Punkt, den ich an die registrierten Unregistrierten nicht abkann: Die Masse bestimmt, was Wahrheit zu sein hat - unabhängig davon, was wirklich gesagt wurde.

Ich schiebe hier nicht jeden in den Kindergarten, ich habe hier einige Leute kennengelernt, die ich zum einen für kompetent halte und mit denen ich ansonsten auch gut zurecht komme. Ich sage, dass sich viele der Kiddies in diesem Thread wiederfinden.

CStoll schrieb:

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?

Schöne Frage, eigentlich ein Kandidat für die Ignoreliste. Wäre das dann wieder ein ignoriertes "Argument"? Sorry, das soll keine Beleidigung darstellen, es ist wirklich nur der Hinweis, dass die Frage ziemlich unsinnig ist.

Keine Ahnung, wer's war, ich war's nicht, denn ich sehe hier absolut kein Problem. Ich sehe Probleme, wenn man redundante Klassen verwendet.
Mehrere Klassen für eine Datenklasse bedeutet das man numerische Probleme von Hand nachbaut.

Erstens: für einfache Genauigkeit, nehme man ein double. Wieviel Dezimalstellen sind das? 15? Das deckt grob geschätzt von 1000stel Millimeter bis zum Umfang der Erde alles ab. Für Uhrmacher bis hin zum Erbauer der chinesischen Mauer ausreichend genau.

Braucht man mehr, kann man beliebig genaue Typen verwenden. Zieh Dir eine Float über 256kB rein, damit kannst Du notfalls die Distanz zur nächsten Galaxie in Billiardstelmillimetern angeben. So what?

Was man eben nicht nehmen sollte, wären unterschiedliche Typen. Ist class Millimeter nur Bruchteil von class Meter und beide haben einen unzureichend genauen Datentyp, so nutzt das auch nichts.
Addiere ich 5 Meter + 100 Millimeter => int( 5 ) + int( 100 / 1000 ) => ergibt das 5 Meter.

CStoll schrieb:

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

Die Entscheidung was sinnlos ist und was nicht, überlasse ich dem Entwickler.

CStoll schrieb:

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?

Danke für die Anführungszeichen...
Ich sagte schonmal, dass ich keine Fenster in meinem Framework beschreibe.

Ansonsten funktioniert ein Setter grundsätzlich nur auf einen Datensatz. Da das Fenster die Abhängigkeit zwischen den einzelnen Datensätzen beschreibt, bedeutet das Verändern eines Punktes auch die Änderung der abhängigen Punkte.

Und zum letzten... wer sagt denn, dass Fenster unbedingt rechtwicklig seien?! Wenn ich mir die Darstellung von 3D Fenstern ansehe, so sehen die überhaupt nicht rechtwinklig aus.

@Shade & chrische5: So eindeutig bestimmt, wie ihr eure Diagnosen über meine Psyche schreibt, müsstet ihr ja eigentlich schon ein Diplom in Psychologie haben. Falls nicht, gibt es immer noch Möglichkeit zur Weiterbildung.
Sollten eure Aussagen keine fundierte Diagnosen sein, so sind es haltlose Beleidigungen. Wenn ihr sonst nichts mehr beizutragen habt, so danke ich für eure wertvollen Beiträge.

[CStoll]

Xin schrieb:

CStoll schrieb:

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

Komisch... wenn ich meine Postings lese, lese ich da, dass Du das gleiche machst, wie ich, aber keinen Schritt kommst, als ich. Ich spreche von gleichwertig. Unsere "Ansätze" unterscheiden sich bei Komposition/Vererbung und das war's. Ich würde nichtmals sagen, ob wir überhaupt von "Deinem"/"meinem" Ansatz sprechen können.

Wenn du noch nichtmal erkennst, was gleich ist und was nicht, hast du ein Problem (oder eine andere Vorstellung von OOP als der Rest der Welt). Denn du bist der einzige, der hier denkt, daß "unsere" Ansätze gleich sind.

Xin schrieb:

Du bringst vereinzelt Punkte, wo die Beibehaltung der Typsicherheit durch die Operatoren geringfügige Vorteile bringt (s.u.), aber den schätze ich nicht wichtiger ein, als die Möglichkeit Objekte zu zählen. Es bleibt bei einer Geschmackssache.

Vorteile, die dir nützen, sind von Bedeutung, Vorteile anderer Lösungen sind "geringfügig" oder "Geschmackssache" - also auf dieser Grundlage kommen wir definitiv nicht weiter.

Xin schrieb:

Ich lese mir meine Postings durch und ich lese mir auch Deine Postings durch.
Was wir (Du und ich) hier machen, ist uns über eine Geschmacksfrage in die Wolle bekommen, ausgehend davon, dass ich auf die Schnelle mal ein Beispiel für die Ableitung von int reinwerfen sollte - nicht gleich ein perfektes Typsystem. Seitdem pfefferst Du dagegen und das meiste stimmt so nicht, jedenfalls hast Du nichts, was über Geschmackssache hinausgeht.

Du hast damit angefangen, daß du gerne von int ableiten wolltest, ich habe dich gefragt, wofür - und seitdem versuche ich (leider erfolglos) dir zu zeigen, daß deine Lösung allen Prinzipien des OOP widerspricht.

Xin schrieb:

Ganz ehrlich: Ich übernehme gerne das bißchen mehr Verantwortung, um mich dafür ein ganzes Stück freier bewegen zu können.
Die Ableitungen sind nicht schlecht, sie sind eine andere Möglichkeit, die Dinge zu sehen und sie funktionieren deutlich besser als nichts zu machen. Und das tun sie, egal, wie sehr Du Dich für andere Lösungen stark machst, das ist die Position, die ich hier erst freigebe, wenn Du oder sonstwer etwas wirklich Nennenswertes bringst.
Solange verteidige ich es eine Möglichkeit unter anderen Möglichkeiten.

Da haben wir zwei Sichtweisen, die aufeinanderprallen:
Du (als Anwender) traust dir die Verantwortung zu, deshalb entwickelst du (als Bibliotheksentwickler) ein komplexes System und sagst den Anwendern, daß sie selber Schuld sind, wenn sie es falsch anwenden.
Ich (als Anwender) will lieber ein einfaches und sicheres System) und baue deshalb (als Entwickler) eine Lösung, die einfach angewendet - und nur durch bewußte Entscheidungen umgangen werden kann.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Dann wiederhole ich mal, dass ich nicht verbiete, meine Klassen per Template zu erzeugen.

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

*lach* und das zu erkennen hat bis hierhin gedauert? Ich schrieb es schon ein paar mal.
Naja, auch kleine Fortschritte führen hoffentlich zu einem baldigen Ende hier.

So genau liest du also. Daß man die int-Derivate auch per Template erzeugen kann, habe ich schon vor einer Weile zugegeben. Aber das war wohl auch eine der Bemerkungen, die du ignoriert hast.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

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.

Selbstverständlich. Und ich mache keine Unterschiede zwischen zählbar und meßbar. Du auch nicht.
Ich kann sie machen, aber meine ursprüngliche Aufgabe waren Beispiele für Ableitungen von int zu geben und nicht ein ganzes Typsystem aufzubauen. Ich soll jetzt nicht wirklich noch mal eben zwei Klassen dazwischensetzen, oder?

Und wenn du zehn Hilfsklassen dazwischensetzt, ändert das nichts an deinem Denkfehler.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

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.

Korrekt. Das ist ein Argument. (<- man beachte!)

Und dann kommt man zu der Frage der Wertung. Es spricht definitiv für Deinen Ansatz. Die größere Freiheit beim Zählen von Objekten für meinen. Wie oft zählt man Objekte, wie oft muss man sich dem Risiko des acos aussetzen?

Also in einer Physik-Bibliothek kommen Winkelfunktionen auf jeden Fall häufiger vor als Versuche, Meßgrößen zu "zählen".

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

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.

Es gibt keinen größeren Zusammenhang, weil Du nichts änderst, denn dafür müsstest Du irgendwann zuweisen.

Es gibt immer einen größeren Zusammenhang - und vielleicht kommt die Zuweisung erst einige Ebenen weiter oben, nachdem das Zwischenergebnis weiter verrechnet wurde. Oder ich will das Ergebnis "nur" ausgeben. Oder...

Xin schrieb:

CStoll schrieb:

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)

Das hatten wir alles schonmal. Sie sind gleichwertig, mit Ableitungen muss man lediglich etwas anders damit arbeiten, als üblich, vergleichbar mit Dot-COM-Programmierung.

Ja, das hatten wir schonmal - das Ergebnis dieser Frage ist aber irgendwo hinter der Frage "sollte man von int ableiten?" und "wie stellt man physikalische Größen in C++ am besten dar?" untergegangen.

Xin schrieb:

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

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.

DAS halte ich für Kindergartenverhalten.

Was genau, etwa andere als "Kindergarten" einzustufen? Damit hast du angefangen und wirklich jeden "Gegner" dem Forumskindergarten zugeordnet - inklusive Shade und mir.

Xin schrieb:

CStoll schrieb:

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?

Schöne Frage, eigentlich ein Kandidat für die Ignoreliste. Wäre das dann wieder ein ignoriertes "Argument"? Sorry, das soll keine Beleidigung darstellen, es ist wirklich nur der Hinweis, dass die Frage ziemlich unsinnig ist.

Keine Ahnung, wer's war, ich war's nicht, denn ich sehe hier absolut kein Problem. Ich sehe Probleme, wenn man redundante Klassen verwendet.
Mehrere Klassen für eine Datenklasse bedeutet das man numerische Probleme von Hand nachbaut.

Erstens: für einfache Genauigkeit, nehme man ein double. Wieviel Dezimalstellen sind das? 15? Das deckt grob geschätzt von 1000stel Millimeter bis zum Umfang der Erde alles ab. Für Uhrmacher bis hin zum Erbauer der chinesischen Mauer ausreichend genau.

Braucht man mehr, kann man beliebig genaue Typen verwenden. Zieh Dir eine Float über 256kB rein, damit kannst Du notfalls die Distanz zur nächsten Galaxie in Billiardstelmillimetern angeben. So what?

Ich mag aber nicht die Rundungsprobleme von double und co. Und außerdem will ich automatisch die "richtige" bzw. passende Einheit für ein Rechenergebnis ausgegeben haben. Da wäre mein Ansatz vermutlich keine eigene Klasse, aber innerhalb der Klasse eine Trennung zwischen reinem Zahlenwert und Einheitenpräfix.

Xin schrieb:

CStoll schrieb:

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

Die Entscheidung was sinnlos ist und was nicht, überlasse ich dem Entwickler.

Du bist der Entwickler der Bibliothek - wer damit arbeiten will, richtet sich also nach deinen Vorgaben (oder sagt dir, daß er etwas anders haben will). Ich denke zumindest, daß ich ein Grundverständnis für physikalische Relationen habe, also baue ich mein System so, daß physikalisch sinnlose Kombinationen nicht erlaubt sind (und wer der Meinung ist, sie trotzdem verrechnen zu wollen, kann die Einheiten gerne rauskürzen).

Xin schrieb:

CStoll schrieb:

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?

Danke für die Anführungszeichen...
Ich sagte schonmal, dass ich keine Fenster in meinem Framework beschreibe.

Ansonsten funktioniert ein Setter grundsätzlich nur auf einen Datensatz. Da das Fenster die Abhängigkeit zwischen den einzelnen Datensätzen beschreibt, bedeutet das Verändern eines Punktes auch die Änderung der abhängigen Punkte.

Und das heißt in Code ausgedrückt?

Xin schrieb:

Und zum letzten... wer sagt denn, dass Fenster unbedingt rechtwicklig seien?! Wenn ich mir die Darstellung von 3D Fenstern ansehe, so sehen die überhaupt nicht rechtwinklig aus.

Ich - bzw. der Kunde, der von dir ein funktionsfähiges Fenster-System erwartet.

btw, auch wenn ich keine Ausbildung in Psychologie habe, erkenne ich bei dir trotzdem mangelnde Diskussionsbereitschaft. Ich würde ja gerne meinem Vater den Thread präsentieren, aber dazu ist der Thread schon zu umfangreich (und vermutlich würde er vor lauter Fachbegriffen den Überblick verlieren).

[OMG]

[quot="Xin"]

CStoll schrieb:

Xin schrieb:

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.

Korrekt. Das ist ein Argument. (<- man beachte!)

Und dann kommt man zu der Frage der Wertung. Es spricht definitiv für Deinen Ansatz. Die größere Freiheit beim Zählen von Objekten für meinen. Wie oft zählt man Objekte, wie oft muss man sich dem Risiko des acos aussetzen?[/quote]
Nachdem es CStoll jetzt etwa das 10. Mal erklärt hat, was bereits 10 Leute vor ihm erwähnt haben , hast du es ja anscheinend mal verstanden. Schade nur, dass ein Cosinus abhängig vom Einsatzgebiet sehr häufig vorkommen kann, und ein Cosinus nicht die einzige einheitenlose Funktion ist. Und tritt er auf, gibt es keine Möglichkeit, ihn abzusichern, sinnlose Butterbrote mit Werkzeugkästen addieren kann man jederzeit mit AsInt oder "/Einheit(1)", aber deinen Cosinus kannst du nicht davor retten, mit Butterbrot*Haus verwechselt zu werden.