Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

Undertaker schrieb:

huch? ich dachte immer sprachen wie C++ können von haus aus *nur* statische vererbung, also wer von wem erbt, ist im fest im quellcode verankert. deshalb gibt es ja auch verschiedene software-tricks (z.b. decorator-pattern) und laufzeitumgebungen (sowas wie COM), um dynamik reinzubringen.

hm?
Shade hat doch erklärt, was er unter "statischer Vererbung" versteht, und wenn du dich mal umschaust oder google anwirfst, deckt sich dieses Verständnis mit dem der restlichen Programmierwelt.

CStoll

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Wow... aus einem Beispiel für eine int-Ableitung automatisch ein perfektes Typsystem entstehen, dass eine perfekte Physik-Bibliothek erzeugt, bevor einfach akzeptiert, wird, dass nichts gegen eine Ableitung von Primitiven einzuwenden ist.
Wenn Du mit dem Anspruch an Deine Software gehst, dass ein Hello World die Grundlage für ein Betriebsystem darstellen muss, dann sind wir wieder an dem Punkt, wo Dinge nicht handhabbar werden.

Nein, ich gehe mit dem Ansatz heran, ein Typ-System zu entwickeln, das mir die Arbeit abnimmt.

Dein Ansatz war "Xin, zeige ein Beispiel für eine int-Ableitung", "Xin mache daraus das perfekte Typsystem", "Xin mache daraus eine Physik-Lib".

Nein, ich sagte nur, du sollst ein Beispiel liefern - da du ein Beispiel aus der Umgebung Physik gewählt hast, mußt du auch mit Kritik über deinen Umgang mit der Physik auskommen.

Xin schrieb:

Schrieb ich schon, dass ich üblicherweise Techniken aussuche, um ein Problem zu beschreiben, und mir nicht Probleme auszusuche, um eine Technik zu verwenden? Ja, schrieb ich schon.

Ja, jeder von uns hat einen Vorrat an Techniken, die er je nach Bedarf auswählt, um gegebene Probleme zu lösen. Aber eine Technik, die nur in der hintersten Schublade liegt und "einstaubt", weil für jedes bekannte Problem eine bessere Lösung existiert, ist unnötig. Also bitte gib mir ein Beispiel, bei dem man mit "Ableitung von int" besser fahren könnte als mit "Komposition aus int-Werten".

Xin schrieb:

CStoll schrieb:

Wenn du mich wirklich überzeugen willst

Ich will Dich nicht überzeugen. Schrieb ich schon.
Ich gebe eine Möglichkeit vor, die ist da, die ist so und die ist nicht wegzudiskutieren. Punkt.
Und man kann sie auch benutzen, wenn man sie für angebracht hält. Ich bin der Meinung, dass man mehr mit Ableitungen arbeiten kann, Du nicht. Beides hat Vor- und Nachteile => Geschmackssache, Thema für mich erledigt.

Die Nachteile deines Ansatzes wurden schon öfter hier dargelegt (und von dir als unbedeutend eingestuft), die Vorteile kennst nur du.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Wenn Du Dir also eine Technik nimmst und feststellst, dass es andere Techniken gibt, die einem Ziel besser gerecht werden, beweist du damit nicht, dass die Technik schlecht wäre.
Ohne Grundlage hebelst Du Dich leider selbst aus.

Dann liefere mir doch eine Grundlage - gib mir eine mögliche Anwendung, wo ich mit einer Ableitung von int besser fahren würde als mit "meiner" Komposition. Irgendeinen Bereich muß es ja geben, wo diese Technik optimal ist, andernfalls ist sie nutzlos.

Ich sehe interessante Möglichkeiten, bei großen Frameworks, die somit zum einen dafür sorgen, dass Typen nicht für unpassende Informationen verwendet werden und zum anderen garantieren, dass jedes Objekt gleichartig Informationen auf- und wieder abgibt. Schrieb ich schon.

Nein, ich schreibe Dir kein großes Framework, damit Du es erkennst.

Ja, eine schöne Aussage - nur leider viel zu schwammig, um irgendetwas darauf aufbauen zu können. Liefere bitte entweder ein konkretes Beispiel (wenn du willst, auch ein etwas kleineres - oder machen sich die Vorteile erst ab 1000 beteiligten Klassen bemerkbar?), dann kann ich auch damit umgehen. Ich sehe bisher nur dein Beispiel mit einem physikalischen Einheitensystem - also muß ich dieses als Diskussionsgrundlage nehmen.

Xin schrieb:

CStoll schrieb:

Und ich habe dich wiederholt darauf hingewiesen, daß es einen konzeptionellen Unterschied zwischen Ableitung und Komposition gibt (wenn sie identisch/gleichwertig wären, gäbe es wohl keinen Grund, zwei Lösungen für das selbe anzubieten).

Es ist ein sprachsemantischer Unterschied, kein Unterschied in den Möglichkeiten, kein Unterschied der den Compiler überlebt. Es ist die Aussage darüber, was als implizit gilt und was als explizit angegeben werden muss.

Fakt ist, es gibt einen Unterschied - und wenn auch nur in der Semantik. Dieser Unterschied ist für mich groß genug, um beide Wege nicht als austauschbar einzustufen - ich würde nie die Beziehung zwischen PKW und Fahrzeug über Komposition beschreiben oder die Beziehung zwischen PKW und linkem Vorderrad über Vererbung.

Xin schrieb:

CStoll schrieb:

Ja, wir zwei kommen nicht weiter - aber das ist bestimmt nicht alleine meine Schuld (vielleicht zum Teil).

Sehe ich für mich ähnlich.

Interessiert mich das, um hier Schuldfragen zu klären?
Bin ich hier, um herauszufinden, wer an irgendwas Schuld trägt?
Nein.

Und warum versuchst du immer zu belegen, daß du der einzig vernünftige Mensch in diesem Thread bist und alle anderen nur auf einer "dagegen"-Haltung festhalten? Ich bin genauso offen wie jeder andere für neue Ideen - aber um sie einsetzen zu wollen, muß ich auch Vorteile erkennen, die sie mitbringen würde (und daran hapert es bei deiner Lösung).

Xin schrieb:

Ich bin an Austausch interessiert.

Dann tausch doch aus - bislang stehst du nur auf deiner "alle sind gegen mich" Position und wartest darauf, daß irgendwer hier aus eigener Kraft erkennt, wei genial deine Lösung ist.

Xin schrieb:

Dafür ist genau das praktisch, beim durchzählen von Objekten (Warenwirtschaft) oder bei der Verwendung mit Schnittstellen, die diese Typen nicht kennen.

Wenn du Objekte "zählen" willst, dann pack' sie in einen gemeinsamen Container (zur Not auch polymorph) und lass dir die Gesamtzahl der reingeworfenen Objekte ausgeben. Da macht es durchaus Sinn, Klassen wie "Butterbrot" oder "Haus" von einer gemeinsamen Oberklasse "Objekt" abzuleiten - dort besteht eine Verwandschaftsbeziehung zwischen den Klassen. Aber bei so einem Ansatz steht ein "Butterbrot"-Objekt für ein einzelnes Brot, das man mit Wurst belegen, betrachten - und notfalls auch aufessen kann. Bitte wirf das nicht mit physikalischen Einheiten durcheinander.

Xin schrieb:

Nicht jedes Programm braucht laufend acos(). Damit verschieben sich die Prioritäten man kann sich überlegen, je nach Situation überlegen, was man braucht. Es wird zu einer Geschmackssache - situationsabhängig, es gibt kein Gut und kein Böse, das allgemein gilt. Es gibt nur zwei Möglichkeiten und das muss so anerkannt werden.

Ich brauche in einem Physik-System häufiger mathematische Formeln, als daß ich inkompatible Größen zusammen"zählen" müsste.

Xin schrieb:

CStoll schrieb:

"Xin ist scheiße" hast du in das Thema reininterpretiert. Ich habe mich bemüht, dir (konstruktiv) klarzumachen, was an deinem Weg falsch ist (an einem Beispiel, das du ausgewählt hast).

*lach*, ich sehe hier nicht, wo ich interpretieren müsste.
Konstruktiv wäre gewesen, wenn Du eine Idee auffasst und die Möglichkeiten und Unmöglichkeiten auslotest. Du hast die Idee aus einem dahergeworfenen Beispiel genommen, das gleiche über die Komposition erstellt und es dann auf einen Crashtest angelegt.
Wenn ich für ein dahergeworfenes Beispiel erst Crashtests machen muss, dann wäre es von Vorteil, wenn Du das vorher ankündigst, so dass ich das Beispiel entsprechend gestalten kann.
Ich habe nie versprochen, dass mein Modell Crashtest sicher wäre. Es war ein Beispiel, um die Idee dahinter zu verdeutlichen. Trotzdem schlägt es nicht wirklich schlechter als die Komposition, denn es bringt nichts einen Crashtest unter ungleichen Bedingungen zu fahren.
Du hast ein dahergebrachtes Beispiel genommen, sämtliche Rahmenbedingungen festgelegt und willst so beweisen, dass ich etwas nicht einhalte, was ich nichtmals versprochen habe. Und blöderweise fällt "mein" Model auch nicht gleich auseinander, nur weil Du es gegen mal gegen die Wand gefahren hast.
An beiden Modellen sind nach Deinen Crashtests jetzt hier und da ein paar Kratzer dran - ich lasse mich aber nicht auf ein grundsätzliches Urteil herab. Das kann jeder selbst aussuchen, wo er mit Kratzern leben kann und wo nicht.

Ich habe deinen Ansatz genommen und unter realen Bedingungen probegefahren - und um bei deinem Auto-Vergleich zu bleiben: Wenn du der Meinung bist, der Schaltknüppel sollte lieber unter der Sonnenblende untergebracht werden als in der Mittelkonsole, dann solltest du deinen Kunden auch vermitteln, wo der Vorteil davon ist.

Xin schrieb:

Für Dich gilt nur "Es darf nicht sein, so muss es zerschlagen werden.". Dafür greifst Du Dir 50 Jahre Programmierwissen, um auf eine mal eben geborene Idee zu feuern.
Einen konstruktiven Diskussionsparter stellst Du jedenfalls so nicht dar. Du willst die Idee kaputtkriegen. Konstruktiv wäre gewesen, sie wachsen zu lassen und dann zu gucken, was Du individuell damit anfangen kannst.
Neue Konzepte fallen nicht einfach vom Himmel. Neue Konzepte sind auch nicht immer mit C++ direkt zu übersetzen.

Ich sehe mir an, was sich daraus entwickelt, aber von dir kam bisher nichts als ein (unbegründetes) "die Idee ist gleichwertig". (neue) Konzepte existieren numal nicht im freien Raum, sondern müssen sich in der Praxis - und im Vergleich mit älteren Ansätzen - bewähren.

Xin schrieb:

CStoll schrieb:

Und wer wählt aus, welche Punkte des Fensters nun per Getter gesucht werden und welche über Typumwandlungen?

Keine Komposition => keine Getter erforderlich.
Wer das auswählt: Der Entwickler der Klasse, war das früher was anderes?

Und nach welchen Kriterien wählt er aus, welche Eckpunkte des Fensters als Basisklasse verwendet werden und welche bei Bedarf berechnet werden?
(bei deinem Ansatz wirkt sich diese Auswahl auf den Nutzer-Quelltext aus, bei reiner Komposition bleibt es ein Implementierungsdetail, von dem niemand etwas bemerkt)

Xin schrieb:

CStoll schrieb:

Du hast als einen Vorteil deines Ansatzes präsentiert, daß ich mit "my_area = PointUpperLeft(47,11);" das Fenster strecken kann - also wie würde das in Quellcode umgesetzt werden?
Bei diesem Weg hast du entweder Redundanzen (UpperLeft und UpperRight haben die selbe x-Koordinate) oder Inkonsistenzen (UpperLeft wird per Zuweisung korrigiert, UpperRight per Setter). Was ist dir lieber?

Keine Ahnung, wo Du Inkonsequenzen siehst, ich sehe bestenfalls Programmierfehler und Programmierfehler habe ich auch nicht erfunden, die gibt's schon länger - auch bei Komposition.

Bitte lies mal richtig - ich sagte "Inkonsistenz". Zeig mir doch bitte mal, wie du die einfache Zuweisung "my_area = PointUpperLeft(47,11);" umsetzen würdest.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

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

Liebelein, ich fange mit Dir jetzt keine weitere 30 Seiten Diskussion an, um eine Möglichkeit(!) an Fenstern durchzuexerzieren. Kauf Dir ein Stofftier.

Muß ich mich dazu noch äußern?

Nein.
Was das Stofftier angeht, so gehe ich mal davon aus, dass Du das nicht verstehen kannst, es war eher eine Art "Insider": Ein Prof riet uns in seiner Vorlesung, uns ein Stofftier anzuschaffen. Es hört zu und hilft Gedanken zu sortieren, da man sie ausformuliert.
Es hatte nichts mit (Kindergarten-)Kindern zu tun.

Wenn ich Gedanken ausformulieren will, rede ich mit meinem Rechner (bzw. tippe Stichpunkte etc ein), da habe ich am Ende mehr davon Aber danke für das Angebot.

Xin schrieb:

CStoll schrieb:

Btw, noch ein Wort zur Bezeichnung "Produktivsystem": Normalerweise gibt es einen Entwickler und viele Anwender (dazu gehören auch andere Entwickler, die deine Bibliothek in ihren Programmen nutzen wollen). Solange du auf dem Standpunkt stehst, daß bestenfalls drei bis vier Leute mit deinem System umgehen wollen/sollen/..., brauchst du nicht wirklich von Produktivsystem zu sprechen.

Es ist produktiv im Einsatz, aber nicht öffentlich verfügbar. Wollen wir hier die Unterschiede von "produktiv im Einsatz" und "Produktivsystem" klären?

Ich habe auch noch einige Programmfragmente zu Haus rumliegen, die ich eventuell mal wiederverwenden will - aber bei denen würde ich nicht von einem "Produktivsystem" sprechen.

Xin schrieb:

CStoll schrieb:

Mr. N schrieb:

Xin schrieb:

CStoll schrieb:

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

Super, Deine Oma war ja auch schon im Thread, holen wir Deinen Vater dazu.
Hast Du denn eigentlich keinen großen Bruder?

Ich nehme an, sein Vater ist Psychologe.

Fast - er ist Lehrer.

Hmm... meiner (natürlich nicht allgemeinverbindlichen) Erfahrung von Pädagogenkindern bzw. Pädagogen als Eltern nach, hätte ein Warnhinweis in Deiner Signatur die Diskussion verkürzen können.
Sieh es positiv. Wir haben auch mehrere Psychologen im Bekanntenkreis. Also würde ich sagen, Dein Status als "Pädagogenkind" ist immernoch besser, als "Psychaterkind".

Wieso das - schlechte Erfahrungen gemacht?

Xin schrieb:

CStoll schrieb:

Und er würde Xin wohl mangelnde Sozialkompetenz diagnostizieren (ein Tip: zur Kritikfähigkeit gehört es auch, Kritik aufzunehmen und darüber nachzudenken).

Dein Vater ist Lehrer, kein Arzt.

Zu einem Lehrer gehört es nicht nur, den Schülern Wissen zu vermitteln (denk mal drüber nach)

Xin schrieb:

Weiterhin schreibt hier nicht der Lehrer, sondern der Student.

Ja, und deswegen stufe ich dich ja auch als "stur" ein - das sagt etwa das selbe aus, klingt nur nicht ganz so hochtrabend.

Xin schrieb:

Ich bezweifle, dass Du jemanden findest, der selbstkritischer ist als ich.
Ich stelle mein Wissen und meine Meinungen regelmäßig in Frage. Allerdings ziehe ich aus meiner Selbstkritik nicht nur Selbstzweifel. Ich bemühe mich meine Überzeugungen über eine Vielzahl von Wegen zu belegen. Wenn's richtig ist, muss auf allen Wegen das selbe rauskommen. Und das mache ich jetzt schon was länger so.
Und immer wieder trifft man auf Leute wie Dich, die gegangene Pfade nicht verlassen wollen und alles als falsch deklarieren, was nicht dem "üblichen" entspricht. Manche begehen recht einfache logische Fehler, die schnell auffallen, wie OMGs Feststellung, dass ich implizite Konstrukte nicht verstehen würde und durch sein implizites Mißverstehen leider selbst disqualifiziert. Macht ja nichts, solange man zu feige ist, eine Identität in die Waagschale zu legen.

Ich bin durchaus bereit, mitzugehen, aber wenn mir jemand einen neuen Weg anbietet, sollte er auch bereit sein, mir zu erklären, warum ich diesen Weg gehen sollte.

Xin schrieb:

Es sind auch schon Fälle dabei gewesen, die jahrelang gegen mich sticheln und mich für ignorant, arrogant usw. erklärten und wirklich böswillig gegen mich vorgingen, mir die Worte im Mund herumdrehten und damit auch erstmal kraftig Aufwind bekamen. Auf einer Welle mitschwimmen ist schließlich nicht schwer.
Die Welle bricht entweder mich oder die Welle bricht an mir.
Es ist noch kein Fall dabei gewesen, wo ein Derartiger sich auf Dauer nicht selbst mehr geschadet hat als mir oder ich einer Welle aus dem Weg gehen musste. Mit ein wenig Geduld hängt sich jeder irgendwann zu weit aus dem Fenster und stützt, dafür muss ich nicht eingreifen. Ich muss niemanden ans Fenster bringen, noch rausstoßen - aber ich fange auch nur die wenigsten auf.
Nur die Unregistrierten können sicher sein, dass sie nicht tief fallen.

Meinst du nicht, daß du dich mit dieser Aussage gerade selber sehr weit aus dem Fenster gelehnt hast?

Xin schrieb:

Dieser Thread war inspirierend - nur leider musste ich den inspirierenden Part für mich selbst übernehmen.

Tja, das ist wohl das Los des "Visionär's" - er muß seine Mitmenschen inspirieren.

btw, noch ein Wort zu "ich greife bei der Zuweisung an" und "Ausgaben sind Zuweisungen":

Ich nehme mal das Einheitensystem als Grundlagen - es gibt Typen für Längen, Flächen, Volumen etc. - alle notwendigen Operatoren sind vorhanden, inklusive Ausgabe-Operatoren. Nun schreibe ich zum Beispiel:

Laenge l,b,h;
...
cout<<"Das Volumen ist "<<l*b+h<<endl;

das Plus dort ist eigentlich ein Tipfehler und sollte ein Mal sein (kann vorkommen). Von einem primitiven System (ala typedef int Laenge; ) erwarte ich ja nicht, daß es so einen Fehler entdeckt, aber genau wegen solchen Problemen verwende ich es ja nicht. Damit haben wir jetzt eine Summe "Fläche+Länge", die physikalisch sinnlos ist.

Du schmeißt jetzt alle Typ-Informationen über Bord und addierst zwei Unit's, deren Summe dann als nackte Zahl ausgegeben wird (Gewinn gegenüber reiner int-Arithmetik: nicht vorhanden - das compiliert anstandslos und liefert unsinnige Werte). Ich blocke an dieser Stelle ab und sage "das kannst du nicht addieren" - nach einer Berichtigung compiliert das Programm dann tatsächlich und liefert korrekte Ergebnisse.

@Shade: Nette Zusammenfassung dessen, was ich auf den letzten Seiten versucht habe, Xin zu erklären.

Xin

Thread Post Mortem.

chrische5 schrieb:

Diese permanenten Beleidigungen die Xin hier aber loslässt sind einfach nicht zu ertragen. Immer das gleiche Schema: "Bei dem Blödsinn, den du schreibst, kannst du den Thread nicht gelesen haben, also beleidigst du mich."

Hier behauptet jeder, dass ich laufend Beleidigungen ablasse. Ich gehe eigentlich grade nach dem OOP Thread davon aus, dass ich eben nicht anfange hier irgendjemanden zu beleidigen.
Entweder habe ich eine andere Wahrnehmung, übersehe einfach alles oder die Behauptung ist erstunken und erlogen.
Also war ich mal neugierig, was ich alles so beleidigungstechnisch geschrieben habe und ob meine Erinnerung an den Threadverlauf vielleicht falsch wäre. (Btw: Thema Selbstkritik...)

Das erste, was eine unschön ausgedrückte Wertung enthält ist CStoll:

CStoll schrieb:

OK, du hast eine Lösung geliefert, die allerdings aus OOP-Sicht (entschuldige den Ausdruck) vollkommener Käse ist.

Damit positioniert sich CStoll für den restlichen Thread. In meinen Augen ziemlich früh und auch nicht optimal ausgedrückt, aber im Rahmen normaler Umgangssprache. Das ist der erste nennenswert wertende Ausdruck im Thread.

Brutal zerschmettere ich die arme Seele mit

Xin schrieb:

Ob das Käse ist, wie Du allgemeingültig behauptest, hast Du mir jetzt nicht schlüssig begründet.

Anders ausgedrückt: Normale Unterhaltung.
Das Level als beleidigend anzusehen, wäre nicht nur sinnfrei, sondern würde bedeuten, dass wir zukünftig nur noch per Anwalt ins Forum dürfen.

Dann kommt das erste Mal das Wort Beleidigung ins Spiel:

ulfbulf schrieb:

CStoll schrieb:

ulfbulf schrieb:

ach ne moment sind ja eh alles kiddies hier also schnauze cstoll shade etc.

Sagt wer? Wenn du uns beleidigen willst, dann bitte mit Namen und Anschrift.

merkst du nix

Ich poste hier nicht als Unregistrierter.

ulfbulf schrieb:

CStoll schrieb:

Edit @ulf: Ich merke, daß du ein Troll bist

macht nix, vielleicht gibts in diesem foru ja doch noch andere leute die ironie verstehen

Der Spaß mit ulfbuff und CStoll geht noch ein Weilchen weiter. Ich bin bei 1/6 des Threads und wirke leicht genervt, weil es tauchen da Shade schon Fragen anspricht, die bereits beantwortet wurden. Und sackt das Niveau dann auch mal.

Shade Of Mine schrieb:

Xin schrieb:

Dir gefällt die Idee nicht, das ist okay.
Die Idee scheint mir von Dir noch nicht ganz verstanden zu sein. Es steht Dir frei das ganze mal auszuprobieren und auszutesten und es steht Dir auch frei dagegen zu sein. Deine Argumentation haben aber nichts mit den Flag-Klassen zu tun.

Du ignorierst ja - genau wie bei der OOP Diskussion die Punkte die dir nicht gefallen.

Woraufhin ich auf schärfste beleidige:

Xin schrieb:

Jow, ich ignoriere euch immer.

Ich mache Dinge, die funktionieren, Du sagst, was ich mache ist Scheiße und ich ignoriere das.
Stimmt.
Wenn Du mir Argumente bietest, die mir unbekannt sind und ich dann feststelle, dass ich eine Einschätzung überdenken und ändern muss, dann ignoriere ich diese auf keinen Fall - selbst, wenn sie in einer Beleidigung verpackt wären.

ulfbuff nervt mal wieder.

Wir sind ganze Reihe von Postings weiter. Shade wiederkäut immernoch erledigtes Zeugs, ich bin etwas zynisch, aber nicht beleidigend.

Wieder viele Posts weiter zwischen denen ulfbuff der einzige ist, der sich beleidigungstechnisch konstruktiv äußert, habe ich mich zu einem Fehler hinreißen lassen und gebe das auch zu:

Xin schrieb:

CStoll schrieb:

Ich implementiere WindowFlags und Window und da wird es keinen operator bool() geben.

Was dann? Bzw. wie willst du sonst einzelne Flags abfragen?

Die Frage ist gut... ^^
Die Frage ist sogar so gut, dass ich mir meine Implementierung ansehen musste, weil hier irgendwas sonst nicht passen kann...
Und da steht: in C++ habe ich einen operator bool().

Wenn ich einen Rückzieher mache, dann mache ich das deutlicher, das sieht dann ungefähr so aus:
Was den operator bool() angeht, habe ich mich zu weit aus dem Fenster gelehnt, weil ich hier was durcheinander geworfen habe und es jetzt auch schon wieder einige Zeit her ist, seitdem ich die Flagklassen entworfen habe.
Ergo gilt auch das Argument von Shade, bzgl. if( win ). Ein offizielles und ernstgemeines Sorry an ihn und einen nicht ganz so ernstgemeinten Kniefall.

Ich bin einem Viertel des Gesamtthreads, was hier immerhin etwa 10 Seiten entspräche. Abgesehen von ulfbuff (Unregistriert) gibt es von allen ernsthaft beteiligten Feststellungen, die nicht perfekt formuliert sind, aber nichts, was irgendeine nennenswerte beleidigende Bedeutung hat. Weiterhin wurden Argumente angegangen, aber keine Personen, wenn ich mal über Shades einzelnen Ausrutscher hinwegsehe, auf den ich nicht beleidigend eingegangen bin und der dementsprechend im Fortverlauf keine Rolle spielt.

-------------- 25 % ---------------

Der Kindergarten trifft langsam ein, die Posts von Unregistrierten vermehren sich. Gleichzeitig haben CStoll eine recht konstruktive Diskussion über Mehrdeutigkeiten von Mehrfachableitungen. Die Sache läuft eigentlich wunderbar weiter, mittendrin kommt etwas zusammenhanglos:

.filmor schrieb:

Unfug hier war.

Einige Seiten später beginnt Shade - wenn auch ohne Beleidigung - den Thread ohne Argumente durch sinnlos Postings zu stören. Und wo mir grade (~40%) durch den Kopf geht, dass der Thread beleidigungstechnisch doch ziemlich langweilig ist, kommen wir endlich zum ersten vollkommen sinnlosen Posting, das eine Wertung enthält:

scrub_ schrieb:

Xin schrieb:

Ich finde den Kommentar "Kann Nüsse enthalten, bei Nussallergie nicht konsumieren" auf einer Packung Erdnüsse für lächerlich.

Wieder mal glaubst Du Dich im Besitz der absoluten Wahrheit. Anstatt einfach mal die Möglichkeit zu überdenken, daß Nüsse im Sinne dieses Hinweises etwas anderes sind als das, was Du Dir unter Nüssen vorstellst.

Zu Deinem restlichen Unfug braucht man schon nix mehr zu sagen. Fenster sind keine Flags, sondern haben (vielleicht) welche.
Ansonsten erklär einfach mal, was Deiner Meinung nach ein Flag ist. Ich bin an Deiner Meinung interessiert, jedoch nicht an Ablenkungsmanövern.

Das ist das erste Posting, dass mir auffällt, dass wertend und im Ton vollkommen daneben schlägt ohne dass der Absender wie ulfbuff offensichtlich die "Ich bin ein Troll"-Auszeichnung trägt.
Dass Erdnüsse eigentlich Bohnen und keine Nüsse sind, wußte er zu dem Zeitpunkt noch nicht. Es spielt auch keine Rolle, denn die Intention des Satzes ist wohl eindeutig und wäre genauso wenn ich auf Paprikas einen Hinweis drucke "Kann Paprika enthalten", damit Paprika-Allergiker nicht versehentlich Paprika kaufen.

Scrub ist einer derer, warum ich mir überhaupt die Mühe mache, den Thread nochmal auf Beleidigungen nachzulesen, weil auch er mir vorwirft nur Beleidigungen auszustoßen. Schon interessant, was da so bei rumkommt.

In Randbemerkungen mit Undertaker wird nun CStoll zynisch. Der Ton zwischen CStoll und mir wird schärfer, ich frage an, ob wir die Diskussion damit einstellen sollen. Wenige Posts später zerfällt der Thread in zwei Level, CStoll und mich und scrub, der zuvor eine wertende Meinung mir gegenüber äußerte und nun an den Grundlagen scheitert:

Xin schrieb:

scrub_ schrieb:

Ein Objekt ist eine Zustandsbeschreibung?

|:-\
Soweit zu den grundlegenden Konzepten der Informatik.

scrub_ schrieb:

Außerdem: Was sind denn nun Flags?

Kann mir kaum vorstellen, dass Frage ernstgemeint ist... aber gut... die Hoffnung stirbt zuletzt.

Auf beide Fragen erhält er Antworten.

Die Diskussion ist damit eigentlich zu Ende (~45%):

Xin schrieb:

Tellerrand schrieb:

Ich frage mich also: was spricht überhaupt für die Variante der Vererbung und gegen die Variante der Komposition?

CStoll und ich kamen vor ein paar Seiten zu dem Schluss, dass die Komposition in C++ die sinnvollste Variante zu sein scheint. Nur zum Schluss der Diskussion kamen wir offensichtlich noch nicht.

Theston kommt erstmalig ins Spiel. Nicht konstruktiv und gegen mich gerichtet. otze erklärt mir, dass heutige PC keine Turing-Maschinen sind. Ein Unregistrierter äußert, dass dies der 2. Troll-Thread von mir ist. Post 101 - was bedeutet, dass der Thread zu lang ist, als dass alles geladen wurde, was die Prozentangaben als falsch kennzeichnet. Post 101 liegt hier bei mir bei ca. 45%.

Zwischen CStoll und mir herscht zu dem Zeitpunkt eine Diskussion mit scharfen Ton, aber ohne Beleidigungen.
Reihenweise kommen Leute in den Thread, davon eine Menge Unregistrierter, Shade versucht sich mit einem Posting "ohne werten zu wollen.", was gelingt, Theston äußert sich mehr oder minder konstruktiv, scrub erklärt mir:

scrub schrieb:

niemand ist aus Prinzip gegen Dich. Das hast Du Dir ganz allein zuzuschreiben.

Ich darf erklären, dass ich nicht grundsätzlich gegen den Mainstream bin. Reihenweise Sinnlosposts von Unregistrierten. Der Ton zwischen CStoll und mir ist ziemlich scharf. Nachdem er mir vorwarf, jeden krankhaft überzeugen zu wollen, habe ich sein Posting ignoriert und als Antwort gesetzt, dass ihm das als Gegenbeweis dienen darf. Ich hatte keine Lust mehr.

Er wiederholt seine These:

Xin schrieb:

CStoll schrieb:

Doch, du versuchst krampfhaft, mir zu erklären, daß dein Ansatz besser ist.

Ich denke, Dich hier inhaltlich zu ignorieren, ist eine sehr freundliche Form, auf einen derartigen Diskussionsstil zu reagieren.

scrub wirft mir Selbstbeweihräucherung vor. Die Posts derer häufen sich, die den Thread nicht gelesen haben, aber Fragen oder Meinungen äußern. Auf einen Post mit Fragen antworte ich - und zwar freundlich.

Wir sind auf Seite 14 oder 15, was ich so rauslese und eigentlich am Ende der Diskussion für das Typsystem:

Xin schrieb:

Shade Of Mine schrieb:

Aber das lustige ist: du verteidigst immer noch nur die Nachteile - aber Vorteile nennst du immer noch keine.

Ich verteidige keine Nachteile, ich verteidige eine legitime Möglichkeit davor kaputtgeredet zu werden.
Spaßig empfinde ich das aber auch nicht mehr.

Das ist der Endpunkt, weiter sind wir in den nächsten 25 Seiten nicht mehr gekommen.

Shade argumentiert inzwischen wertfrei, während CStoll mir zweimal Ignoranz vorwirft. Auch mein Ton wird deutlicher, den Ton kann ich allerdings aufgrund der Sinnlosigkeit der Frage auch jetzt vertreten.

Xin schrieb:

CStoll schrieb:

Und wo steht in deiner Prioritätenliste die Typsicherheit? Soweit ich das überblicke, sehr weit unten.

CStoll, was soll der Müll? Der Thread wird aus x Seiten geführt, weil Typsicherheit weit oben steht, also was soll diese unsinnige Behauptung!?

Die Diskussion zwischen CStoll und mir wird fruchtlos. Wenige Postings später taucht bei CStoll witzigerweise auch gleich der Mengenvergleich auf:

CStoll schrieb:

Aber selbst dir sollte nicht entgangen sein, daß du so ziemlich alleine auf weiter Flur stehst.

Es folgen reihenweise Unregistrierte, scrub gesellt sich dazu. Auch CStoll geht mal mit den Unregs spielen.

Jetzt weiß ich auch endlich wieder, wer das einzige gute Argument gebracht hat: "Tellerrand" ist der Held des Threads.

Es folgt, was ich als erste nennenswerte Beleidigung aufgefasst habe:

Butterbrot (Unregistriert) schrieb:

Xin schrieb:

CStoll schrieb:

]Ich habe absolut kein Problem damit, daß du deine Meinung vertrittst. Aber ich hätte dir eigentlich schon so viel Intelligenz zugetraut, daß du Gegenargumente nicht mit einem "ist für mich unerheblich" vom Tisch fegst.

Nanana, wir wollen doch nicht beleidigend werden...
Laut Forumsmeinungen ist das ein Zeichen, dass einem die Argumente ausgehen und außerdem bin laut Forumsmeinung ich der einzige, der hier zu beleidigen hat. Also artig bleiben.

Das ist ja wohl ne Frechheit. Selber haust du seit 10 Seiten reihenweise irgendwelche Beleidigungen raus, und jetzt gehst du Cstoll wegen etwas an, was IMHO nicht mal eine Beleidigung ist?!?!

CStoll äußert sich mit "Na dann wünsche ich dir, daß du irgendwann den Sachverstand entwickelst..."
Im Gegenzug dazu liest sich Shade angenehm. CStoll und ich beginnen unseren Einheitenkrampf. Ich äußere das erste Mal "Liebelein...". Ein paar Unregistrierte... usw., usw. usw.

Okay... für mich ist im Prinzip alles gesagt. Ich habe den Thread grade um die 18-20 Seiten überflogen, ich habe auf den Umgangston geachtet und der wurde zwischen mir und CStoll eine Zeitlang immer schärfer. Was ich aus dem OOP Thread mitgenommen habe war, dass ich eben nicht anfange irgendjemanden zu beleidigen, damit man mir das ja nicht vorwerfen kann. Man tut's trotzdem. Sollte ich nicht irgendwo eine Beleidigung in einer Mail mit ansonsten freundlichen Ton übersehen habe, dann habe ich das Beleidigen nicht angefangen - mit niemandem.
Ein Unregistrierter stellt die Behauptung auf, der Rest übernimmt es und vergisst vollkommen, was man selbst alles so vom Stapel gelassen hat.

Auch mein Umgangston war in den Mails mit CStoll nicht immer freundlich, als es da zur Sache geht, aber das ist der Umgangston, den wir uns beide "ausgesucht" haben. Nennenswert beleidigend wurde ich jedenfalls nicht, genausowenig wie CStoll auf langen Strecken. Wir halten uns da etwa die Waage. Freundlich sind wir beide nicht mehr, aber eben auch nicht beleidigend.
"Gewürzt" wurde der Umgangston Endphase von CStoll - weswegen ich später auf den "Moderator" zu sprechen kam.

Interessant finde ich, dass diejenigen, dass grade Scrub so früh unkonstruktiv in dem Thread auftaucht. Der war mir gar nicht so sehr aufgefallen. Bei Theston tat mir meine zynische Antwort ("Grüße vom Planeten Erde") später etwas leid, schließlich dachte ich, er wäre grade in den Thread reingekommen und bekam direkt einen zynischen Kommentar für seine unüberlegte Äußerung verpaßt. Nach vielen Antworten in dem Thread war ich einfach nicht mehr freundlich genug drauf, einem Neuen mit blödem Kommentar vorbildlich zu antworten.
Schön zu sehen, dass auch er seit früher Stunde dabei und das nicht unbedingt konstruktiv, das beruhigt mein Gewissen. Wenn er es nicht wegen der unbedachten Frage verdient hat, so hatte er sich nicht unbedingt für eine freundlichere Behandlung qualifiziert.

Ich bin sicherlich nicht unschuldig und ich habe auch Dinge geschrieben, die nicht freundlich waren, aber ich habe auch immer mal wieder versucht, die Sache wieder runterzuholen. Und dafür, dass hier sehr deutlich und vor allem schon recht früh - lange bevor ich mit CStoll den Ton verschärfte - von vielen Seiten gegen mich angegangen wird, halte ich mein Schreiben eigentlich für sehr zurückhaltend. Dass ich nicht über 40 Seiten nur freundlich auf solche Sachen reagiere, steht mir genauso zu.

Mr. N

@CStoll: Warum tust du dir das an?

CStoll schrieb:

Xin schrieb:

Es sind auch schon Fälle dabei gewesen, die jahrelang gegen mich sticheln und mich für ignorant, arrogant usw. erklärten und wirklich böswillig gegen mich vorgingen, mir die Worte im Mund herumdrehten und damit auch erstmal kraftig Aufwind bekamen. Auf einer Welle mitschwimmen ist schließlich nicht schwer.
Die Welle bricht entweder mich oder die Welle bricht an mir.
Es ist noch kein Fall dabei gewesen, wo ein Derartiger sich auf Dauer nicht selbst mehr geschadet hat als mir oder ich einer Welle aus dem Weg gehen musste. Mit ein wenig Geduld hängt sich jeder irgendwann zu weit aus dem Fenster und stützt, dafür muss ich nicht eingreifen. Ich muss niemanden ans Fenster bringen, noch rausstoßen - aber ich fange auch nur die wenigsten auf.
Nur die Unregistrierten können sicher sein, dass sie nicht tief fallen.

Meinst du nicht, daß du dich mit dieser Aussage gerade selber sehr weit aus dem Fenster gelehnt hast?

Unglaublich, dass ich das überlesen habe. Das ist ja der Hammer.

Theston

Erstaunlich aber, dass du meine "ach so unkonstruktiven Einwürfe" (Einheitenlosen Größen wie einem Cosinus oder einer Brechzahl können beliebig irgendwelche Butterbrote zugewiesen werden; in einer größeren Formel kann man nicht erkennen, wo der Typ verloren ging) 5 Seiten später nach heftiger Erklärungsnot als "Geschmackssache" beziehungsweise "Compiler-Unzulänglichkeit" einstufen musstest.

Thread schließen

Shade Of Mine

Undertaker schrieb:

Shade Of Mine schrieb:

Was natürlich möglich wäre - wäre eine "static" Vererbung wie sie manchmal gefordert wird. Also eine Vererbung die keine ist-ein Beziehung repräsentiert, sondern lediglich Code-Reuse Zwecken dient. Hier gäbe es dann keine Konvertierung von Derived zu Base. Ich kenne aber keine Sprache die dieses Konzept nutzt - ich habe in C++ ein paar mal Forderungen diesbezüglich gesehen, aber ich glaube das Standardisierungs Komitee ist Meilenweit davon entfernt sowas zu integrieren.

huch? ich dachte immer sprachen wie C++ können von haus aus *nur* statische vererbung, also wer von wem erbt, ist im fest im quellcode verankert. deshalb gibt es ja auch verschiedene software-tricks (z.b. decorator-pattern) und laufzeitumgebungen (sowas wie COM), um dynamik reinzubringen.

Mir fehlen die Vokabeln für diese Art Beziehung die ich meine. In C++ kam es unter dem Namen "static Vererbung" auf, da man statt ": public Foo" einfach ": static Foo" schreiben können sollte - zum Reuse der Schlüsselwörter.

Lassen wir den Namen also einfach mal aussen vor - meines wissens gibt es keine Sprache die dieses Konzept direkt unterstützt.

Worum es dabei geht ist, eine Vererbung einzuführen die keine ist-ein Beziehung bedeutet. Wenn also Meter von Integer erbt, dann hat Meter alle Methoden von Integer aber ist eben kein Integer. Das würde sich darin Niederschlagen dass es keine Konvertierung von Meter zu Integer gibt (es sei denn man definiert sie sich explizit selber). Diese Vererbung wird also eher als ein "has-a" oder "is-implemented-in-terms-of" verstanden - auch wenn sie aussieht wie eine public Vererbung.

Der Vorteil davon ist besserer Code-Reuse. So könnte zB ein Stream static von seinem stream-buffer erben und man muss in stream nicht die ganzen streambuffer Methoden forwarden. Das wird eben dann interessant wenn man value types hat wo man keine ist-ein Beziehung haben will, aber dennoch die Vorteile der public Vererbung (keine forward methoden) haben will. Anderes Beispiel: ich will dass bei vector::operator[] eine exception fliegt. Also erbe ich static von vector und verdecke den operator[]. Das wäre mit public Vererbung sehr ungut, da man einfach einen impliziten upcast machen könnte und schon hat man den range check umgangen - vermutlich sogar ohne es gewollt zu haben. Wenn man nun static erben würde, wäre ein Upcast nicht möglich, da range_checked_vector kein vector ist. Dennoch muss aber die Methoden nicht forwarden, wie es bei Komposition nötig wäre. Das wird eben dann interessant, wenn wir mit Templates hantieren wo ich die anderen Methoden garnicht kenne. zB könnte vector ja ebenfalls static von einem Policy erben dass je nachdem wie vector nun implementiert ist, slicing operationen anbietet oder nicht. Das nur mal so als Gedankenspiel.

Xins super Sprache mag diese static-Vererbung haben und somit seine Ansätze rechtfertigen. Denn wie gesagt - sobald man von einem value typen erbt und es kein ist-ein bedeutet, hat man fast alle Probleme seines Ansatzes eliminiert.

Da C++ dies aber nicht bietet - würde ich eben eine C++ Lösung nehmen die ebenfalls keine dieser genannten Nachteile hat. Zumal der Ansatz mit Meter/Meter einfach nur genial ist.

PS:
@Xin:
weisst du auch warum die Diskussionen so verlaufen? Ich meine dass Unregistrierte dich anpöbeln und so weiter? Weil dich keiner mehr ernst nehmen kann. Nicht falsch verstehen - wir haben versucht zu diskutieren aber du lässt dich ja auch keien Diskussion ein. Ich widerkäue keine längst widerlegten Sachen sondern lediglich Sachen die du einfach ignorierst. So ziemlich jeder hier denkt ähnlich über deinen Ansatz: nämlich dass er Quark ist.

Ich kann mich deshalb nur noch einmal wiederholen: wirf uns keinen Kindergarten vor oder beleidige uns weil wir anders denken als du. Es ist nicht nur unhöflich sondern auch sehr unreif sich so zu verhalten.

Wenn du von deinem hohen Ross dass du unfehlbar bist einmal herunter kommst, könnte man versuchen weiter zu diskutieren. Aber ein kleiner Tipp: Niemand ist unfehlbar. Niemand weiß alles. Jeder macht Fehler. Es mag sein, dass wir allesamt falsch liegen und du den einzig wahren Weg gefunden hast - ich habe das bereits zweimal gesagt. Lediglich solltest du irgendwann zu einem Punkt kommen wo du Reflektieren solltest ob die Welt nicht vielleicht gegen dich ist weil du Blödsinn laberst und es garnichts persönliches ist was die Leute gegen dich haben. Es ist leicht zu sagen "die Welt ist gegen mich" und "alles sind Idioten" - aber meine Erfahrungen haben mir bis jetzt immer gezeigt, dass dies nie so ist.

Ich war schon öfters in der Situation wo ich mir gedacht habe "warum macht das denn Niemand so? Mein Konzept ist soviel besser". Irgendwann kam ich dann eben auf die Schwachstellen drauf und musste einsehen, dass die Welt doch nicht komplett verdummt ist, sondern ich einfach arrogant und blind war.

Deshalb wäre ich sehr vorsichtig mit solchen Aussagen wie du sie tätigst.

CStoll

@Mr.N: Weiß ich selber nicht so recht.

@Xin: Wenn ich auf eine Frage keine verwertbare Antwort erhalte, frage ich nach - besonders wenn die vorhandenen Antworten dem Thema nur ausweichen. Du hast zwar auf meine Fragen (anfangs) reagiert, aber dabei auch an der Frage vorbeigeredet.

Und spätestens an dem Punkt, wo du angefangen hast, alles und jeden als "Kindergarten" zu bezeichnen, ist das Niveau des Threads endgültig in den Keller gegangen. (das begann etwa auf Seite 20 - und auch ein "das soll keine Beleidigung sein" als Einleitung mindert den Effekt nur unwesentlich)
(vorher hattest du die Bezeichung "Kindergarten" schon zweimal erwähnt - gegenüber ulfbulf und als Reaktion auf "Post 101")

---

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

CStoll schrieb:

@Xin: Wenn ich auf eine Frage keine verwertbare Antwort erhalte, frage ich nach - besonders wenn die vorhandenen Antworten dem Thema nur ausweichen. Du hast zwar auf meine Fragen (anfangs) reagiert, aber dabei auch an der Frage vorbeigeredet.

Ja, das kann er gut.

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

In nem anderen Forum bitte.

Xin

Shade Of Mine schrieb:

Was natürlich möglich wäre - wäre eine "static" Vererbung wie sie manchmal gefordert wird. Also eine Vererbung die keine ist-ein Beziehung repräsentiert, sondern lediglich Code-Reuse Zwecken dient. Hier gäbe es dann keine Konvertierung von Derived zu Base. Ich kenne aber keine Sprache die dieses Konzept nutzt - ich habe in C++ ein paar mal Forderungen diesbezüglich gesehen, aber ich glaube das Standardisierungs Komitee ist Meilenweit davon entfernt sowas zu integrieren.

Mit einer static-Vererbung wäre der ganze Ansatz von Xin natürlich weit besser - da man eine Menge Nachteile ausgleichen würde da es keine impliziten Konvertierungen mehr gibt. Dann wäre es sogar möglich, dass Xins Ansatz eine ziemlich ideale Lösung ist - je nachdem wie static-Vererbung implementiert ist.

Mir fällt dazu grade nur private Vererbung ein, aber ich vermute, ich missverstehe, was Du meinst.
Ich wäre aber interessiert, das genau zu verstehen.

Shade Of Mine schrieb:

Was deine Literatur Hinweise betrifft: wir haben dir versucht zu erklären was du falsch verstanden/interpretiert hast. Aber auch dort wolltest du nicht hören.

Erklärt wurde viel, leider meist haarscharf an der Logik vorbei und häufig auch komplett in die andere Richtung.
Darauf wollte ich wirklich nicht hören.

Jester

Wo Du grad so eifrig postest und ja auch auf alles eingehst, könntest Du da noch schnell was zu CStolls Ausgabe-Beispiel mit dem Volumen sagen?

Xin

Shade Of Mine schrieb:

Worum es dabei geht ist, eine Vererbung einzuführen die keine ist-ein Beziehung bedeutet. Wenn also Meter von Integer erbt, dann hat Meter alle Methoden von Integer aber ist eben kein Integer. Das würde sich darin Niederschlagen dass es keine Konvertierung von Meter zu Integer gibt (es sei denn man definiert sie sich explizit selber). Diese Vererbung wird also eher als ein "has-a" oder "is-implemented-in-terms-of" verstanden - auch wenn sie aussieht wie eine public Vererbung.

Willkommen in Genesys.

Das ist etwa das, wovon ich die WindowFlags abgeleitet habe.

Shade Of Mine schrieb:

Da C++ dies aber nicht bietet - würde ich eben eine C++ Lösung nehmen die ebenfalls keine dieser genannten Nachteile hat. Zumal der Ansatz mit Meter/Meter einfach nur genial ist.

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand. Dazu vielleicht nochmal mein Beispiel: Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s². Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

CStoll schrieb:

Und spätestens an dem Punkt, wo du angefangen hast, alles und jeden als "Kindergarten" zu bezeichnen, ist das Niveau des Threads endgültig in den Keller gegangen. (das begann etwa auf Seite 20 - und auch ein "das soll keine Beleidigung sein" als Einleitung mindert den Effekt nur unwesentlich)

Der Thread war etwa ab Seite 15 kaputt. Und wenn ich nach 15 Seiten Beleidigungen das ganze als Kindergarten einstufe, dann ist das nicht der Punkt, wo ich derjenige bin, der mit Beleidigungen anfängt.

CStoll schrieb:

(vorher hattest du die Bezeichung "Kindergarten" schon zweimal erwähnt - gegenüber ulfbulf und als Reaktion auf "Post 101")

Das würde ich jetzt auch nicht anders einstufen.

CStoll schrieb:

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

Zwischen uns? Sicher, warum nicht.

Das Herr der Unregistrierten hat sich ja bereits dazu geäußert.

Jester schrieb:

Wo Du grad so eifrig postest und ja auch auf alles eingehst, könntest Du da noch schnell was zu CStolls Ausgabe-Beispiel mit dem Volumen sagen?

Nein, den das habe ich im Verlauf des Threads schon zwei- oder dreimal gesagt. Ich übertitelte das Protokoll nicht um sonst als Post-Mortem. Ich werde das Thema auf keinen Fall weiterführen.

Shade Of Mine

Xin schrieb:

Mir fällt dazu grade nur private Vererbung ein, aber ich vermute, ich missverstehe, was Du meinst.
Ich wäre aber interessiert, das genau zu verstehen.

Kleines Code Beispiel:

class Vector {
public:
  int get(int pos) {}
  int size() {}
};

class RangeCheckedVector : static Vector {
public:
  int get(int pos) {
    if(0 <= pos && pos < size())
      return Vector::get(pos);
    else
      throw range_exception();
  }
};

Wenn wir hier nun static durch public ersetzen, ist folgender Code fehlerhaft:

int foo(Vector const& vec) {
  return vec.get(10);
}

RangeCheckedVector v;
foo(v);

Mit static würde dieser Code einen Fehler liefern. Ohne static Vererbung müsste man den Code also so schreiben:

class RangeCheckedVector {
private:
  Vector impl;
public:
  int get(int pos) {
    if(0 <= pos && pos < size())
      return impl.get(pos);
    else
      throw range_exception();
  }

  int size() {
    return impl.size();
  }
};

Der Vorteil von static ist nun, dass wir size nicht forwarden müssen - was interessant wird, wenn wir ein Policy haben:

template<typename Policy>
class Vector : static Policy {
public:
  int get(int pos) {}
  int size() {}
};

template<typename Policy>
class RangeCheckedVector : static Vector<Policy> {
public:
  int get(int pos) {
    if(0 <= pos && pos < size())
      return Vector::get(pos);
    else
      throw range_exception();
  }
};

class Policy {
public:
  int sum_all_elements() {}
};

RangeCheckedVector<Policy> v;

v.sum_all_elements();

Dies wäre mit Komposition oder private Vererbung nicht möglich.

In wie weit dies sinnvoll ist, sei mal dahin gestellt. Denn wie gesagt es gibt AFAIK keien Sprache die das bietet - denn so nett es auch aussieht, man kommt sehr gut ohne aus. Es ist aber vorallem dann interessant, wenn man von value typen erben will - denn public von value typen erben ist böse.

Nachtrag:

Xin schrieb:

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

C++ bietet aber keine static Vererbung und somit ist es nicht möglich. Du hast in allen deinen Posts nicht ein Wort davon verloren dass du ein Konzept wie diese static Vererbung haben willst.

Du hast argumentiert dass man um die Konvertierung die eine ist-ein Beziehung bedeutet herum kommen kann und hast abstrusive Bedingungen aufgestellt wie eben nur explicit CTors und dergleichen und hast somit versucht die Symptome zu bekämpfen nicht aber die Ursache der Probleme.

Xin schrieb:

Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s².

Wieso das?

Xin schrieb:

Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

meter/Meter wird natürlich zu "einheitenlos", allerdings nur solche konstruktionen, in deinem Ansatz ist alles implizit einheitenlos.

Mr. N

Xin schrieb:

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand.

http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Units

Xin

Shade Of Mine schrieb:

Xin schrieb:

Mir fällt dazu grade nur private Vererbung ein, aber ich vermute, ich missverstehe, was Du meinst.
Ich wäre aber interessiert, das genau zu verstehen.

Kleines Code Beispiel:

Dies wäre mit Komposition oder private Vererbung nicht möglich.

Ich verstehe Deine Idee, ich finde sie gut, weil ich komme ja gewissermaßen von dieser Idee mit den WindowFlags in diesen Thread.
Aber Dein Codebeispiel hakt an einer Stelle: Der RangedCheckedVector ist kein Vector, ergo musst Du eine Basisklasse haben oder zwei foo()-Funktionen.

Die optimale Lösung hier wäre OOP zu verwenden, also die get Funktion virtuell zu machen und öffentlich abzuleiten.
Wenn das nicht möglich ist, weil das Interface von Vector Dir das nicht erlaubt, könnte die "static-Vererbung" Dir eine Basisklasse geben, die sich wie ein Vector verhält, aber nachträglich die Funktion get() virtuell macht.
Womit wir uns von OOP in Richtung AOP bewegen. (Aspektorientierte Programmierung)

Shade Of Mine schrieb:

In wie weit dies sinnvoll ist, sei mal dahin gestellt. Denn wie gesagt es gibt AFAIK keien Sprache die das bietet - denn so nett es auch aussieht, man kommt sehr gut ohne aus. Es ist aber vorallem dann interessant, wenn man von value typen erben will - denn public von value typen erben ist böse.

AOP ist ein Ansatz, der noch recht jung ist. OOP ist seit sagen wir 10 Jahren Massentauglich, C++ gibt's seit 20 Jahren und Simula noch viel länger. Bis AOP in C++ existiert und massentauglich wird, vergeht noch das eine oder andere Jahrzehnt.

Shade Of Mine schrieb:

Nachtrag:

Xin schrieb:

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

C++ bietet aber keine static Vererbung und somit ist es nicht möglich. Du hast in allen deinen Posts nicht ein Wort davon verloren dass du ein Konzept wie diese static Vererbung haben willst.

Doch, ziemlich weit vorne, als ich sagte, dass ich die WindowFlags aus einem Genesys-Konzept übernommen habe und natürlich nicht perfekt auf C++ umsetzen konnte. Dort beschrieb ich es nicht als "static Vererbung", sondern aus Mischung von privater Vererbung (keine ist-ein-Beziehung) und öffentlicher (die Elemente werden in den Namensraum der abgeleiteten Klasse übernommen).

Shade Of Mine schrieb:

Du hast argumentiert dass man um die Konvertierung die eine ist-ein Beziehung bedeutet herum kommen kann und hast abstrusive Bedingungen aufgestellt wie eben nur explicit CTors und dergleichen und hast somit versucht die Symptome zu bekämpfen nicht aber die Ursache der Probleme.

An den expliziten CTors kommt man leider immernoch nicht vorbei. ^^

@Shade

Du willst durch static Vererbung die Methoden und Attribute erben, aber die implizite Typumwandlung verbieten? Also eine zweite Vererbungsmöglichkeit ganz ohne Typen?

Da würde ich mich eher Code erzeugender Programmiermodelle bedienen, da sind wir imho im Bereich der Metaprogrammierung.
Sowas würde ich nicht gerne in einem Klassenmodell sehen, sondern davon abgekapselt.
Es geht ja nicht darum einen Typ zu definieren, eine Vererbungshirachie, sondern nur darum Code/Schreibarbeit zu sparen.
Meiner Meinung nach trennt man die beiden Bereiche "Code Redundanzen" und "OOP - Typ- / Klassensystem" leider viel zu selten.

So sehe ich das.

CStoll

Xin schrieb:

Shade Of Mine schrieb:

Worum es dabei geht ist, eine Vererbung einzuführen die keine ist-ein Beziehung bedeutet. Wenn also Meter von Integer erbt, dann hat Meter alle Methoden von Integer aber ist eben kein Integer. Das würde sich darin Niederschlagen dass es keine Konvertierung von Meter zu Integer gibt (es sei denn man definiert sie sich explizit selber). Diese Vererbung wird also eher als ein "has-a" oder "is-implemented-in-terms-of" verstanden - auch wenn sie aussieht wie eine public Vererbung.

Willkommen in Genesys.

Das ist etwa das, wovon ich die WindowFlags abgeleitet habe.

OK, das Problem hatten wir schon weiter vorne in diesem Thread - C++ ist nicht Genesys, und manche Sprachkonstrukte, die du in Genesys integriert hast, lassen sich nur ungenügend in C++ nachbilden. Du hast deine (afair) Typerweiterungen - und eine Länge als "Erweiterung" von int wäre durchaus sinnvoll - und du nimmst dir die C++ Vererbung und versuchst, das Konzept damit umzusetzen. Letzteres scheitert an der unterschiedlichen Semantik.

Xin schrieb:

Shade Of Mine schrieb:

Da C++ dies aber nicht bietet - würde ich eben eine C++ Lösung nehmen die ebenfalls keine dieser genannten Nachteile hat. Zumal der Ansatz mit Meter/Meter einfach nur genial ist.

Würde ich auch... und muss ich auch, weil C++ keine Ableitung von int erlaubt.
Edit: Was eben nicht bedeutet, dass die theoretische Möglichkeit bestünde, es auch auf dem Ansatz zu machen, dessen theoretische Existenz ich hier verteidige.

Nein, du hast hier die (theoretische) Möglichkeit thematisiert, mit C++ Mitteln von build-in's abzuleiten. Daß du dir ein neues Ableitungs-Konzept mit eigener Semantik wünschst, hast du nie erwähnt.

Xin schrieb:

Den Ansatz Meter/Meter hat mir noch keiner gezeigt. Davon wurde hier gesprochen, aber umgesetzt hat ihn noch niemand. Dazu vielleicht nochmal mein Beispiel: Zwei Kräfte zeigen in orthogonale Richtungen. Hier kürzt sich kg*m/s² mit kg*m/s². Ist das jetzt die gleiche Einheit wie Meter/Meter? Und wenn ja wieso kürzt sich kg/s² raus, aber Meter/Meter bliebt?

Meter/Meter kürzt sich genauso heraus wie alle übrigen Einheiten - wenn zwei gleichartige Größen dividiert werden, bleibt in jedem Fall ein einheitenloser Wert übrig.
(btw, was die Orthogonalität damit zu tun hat, müsstest du mir nochmal erklären)

Xin schrieb:

CStoll schrieb:

Und spätestens an dem Punkt, wo du angefangen hast, alles und jeden als "Kindergarten" zu bezeichnen, ist das Niveau des Threads endgültig in den Keller gegangen. (das begann etwa auf Seite 20 - und auch ein "das soll keine Beleidigung sein" als Einleitung mindert den Effekt nur unwesentlich)

Der Thread war etwa ab Seite 15 kaputt. Und wenn ich nach 15 Seiten Beleidigungen das ganze als Kindergarten einstufe, dann ist das nicht der Punkt, wo ich derjenige bin, der mit Beleidigungen anfängt.

Wenn du der Meinung bist, von irgendwem beleidigt worden zu sein, kannst du das dem betroffenen auch direkt sagen - zu dem Zeitpunkt wäre es vermutlich noch möglich gewesen, die Missverständnisse aufzuklären. Aber blind auf alles zu schießen, was sich bewegt, hilft niemandem.

Xin schrieb:

CStoll schrieb:

OK, mein Vorschlag: Wir vergessen den kompletten Thread und fangen noch einmal bei 0 an (am besten in einem neuen Thread). Einverstanden?

Zwischen uns? Sicher, warum nicht.

OK, das ist ein Wort.

Xin schrieb:

Jester schrieb:

Wo Du grad so eifrig postest und ja auch auf alles eingehst, könntest Du da noch schnell was zu CStolls Ausgabe-Beispiel mit dem Volumen sagen?

Nein, den das habe ich im Verlauf des Threads schon zwei- oder dreimal gesagt. Ich übertitelte das Protokoll nicht um sonst als Post-Mortem. Ich werde das Thema auf keinen Fall weiterführen.

Ja, du stufst solche Fehler als "Angelegenheit des Programmierers" ein - und erwartest demzufolge, daß er keine Tipfehler in seine Programme einbaut.

Jester

Xin schrieb:

Nein, den das habe ich im Verlauf des Threads schon zwei- oder dreimal gesagt. Ich übertitelte das Protokoll nicht um sonst als Post-Mortem. Ich werde das Thema auf keinen Fall weiterführen.

In diesem Fall geht ganz offensichtlich Typinformation verloren bzw. wird nicht verwendet, so dass ein Fehler der im einen Fall zur Compilezeit bemerkt wird, hier erst zur Laufzeit eintritt. Das ist ein handfester Vorteil des Systems ohne implizite int-Umwandlung und eben keine Geschmacksache mehr. Inwiefern Du darauf dann eingegangen bist sehe ich ehrlich gesagt nicht. Und nein: Jegliche berechtigte Kritik als Geschmacksache abzutun ist nicht darauf eingegangen.

Methoden mit bool-Parametern und &quot;Lesbarkeit&quot; im Kontext

Methoden mit bool-Parametern und "Lesbarkeit" im Kontext