Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[hinweis]

Der unterhaltungswert ist gleich null, weil ihr immer viel zu viel schreibt. das will keiner lesen

[Hinweis zum Hinweis]

Ich lese nur CStolls Posts, da er Xins zeug sinnvoll filtert.

[Xin]

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.

Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.

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

Vielleicht macht Dir diese Antwort verständlich, wie krampfhaft ich versuche Dich von etwas zu überzeugen. Denk selbst drüber nach, oder lass es - es zwingt Dich niemand.

[mathik]

@Xin
ich empfehle dir folgendes Buch:
Design Patterns | ISBN: 0201633612
Insbesondere das Kapitel über Vererbung vs. Delegation.
Wenn du es gelesen hast und immer noch von "class Window: public WindowsFlags" überzeugt bist, dann solltest du es nochmal lesen und evtl. dann nochmal.
Ist echt ganz schön stur von dir zu behaupten, es sei aus OO Sicht völlig OK, obwohl dir hier schon 100x gezeigt wurde, dass das Murks ist.

Gruß
mathik

[Xin]

mathik schrieb:

@Xin
ich empfehle dir folgendes Buch:
Design Patterns | ISBN: 0201633612
Insbesondere das Kapitel über Vererbung vs. Delegation.

Auch das Buch steht als Standardwerk natürlich auch hier und ist längst gelesen.

mathik schrieb:

Wenn du es gelesen hast und immer noch von "class Window: public WindowsFlags" überzeugt bist, dann solltest du es nochmal lesen und evtl. dann nochmal.

...und vor allem immer brav im Gleichschritt marschieren und auf keinen Fall Wege suchen, die nicht irgendwer in einem Buch für gut beschrieben hat.
Die Gang Of Four hat die Design Patterns beschrieben, die Patterns sind gut, aber das ist keine Religion und die Patterns sind keine steingemeißelten Gebote. Auch wenn manche es so auffassen.
Erfahrung ist mehr als ein Buch gelesen zu haben. Erfahrung heißt Dinge auszuprobieren und das heißt auch Dinge auf Möglichkeiten abzuklopfen, die der Masse nicht zusagen.
Neues Wissen findet sich nicht in sauberen Büchern, sondern im Dreck dazwischen.

Und da Du den Thread gelesen hast, weißt Du ja, dass das Ding, dass ich abklopfe eine Mischung aus privater und öffentlicher Vererbung ist und "class Window : public WindowFlags" eine vereinfachte Abwandlung davon ist.
Du hast sicherlich auch gelesen, dass der Fragesteller Möglichkeiten suchte und eine Möglichkeit habe ich angeboten, ob es CStoll oder Dir im Detail gefällt oder nicht. Die angebotene Möglichkeit muss nicht perfekt sein, um eine Möglichkeit zu sein. "int(Flags) & WFLG_FULLSCREEN" ist das übliche Vorgehen und das ist ebenfalls sehr weit entfernt von perfekt.
Wie Du auch bereits gelesen hast, stelle ich meinen Sourcecode lediglich als Möglichkeit, nicht als perfekte Möglichkeit dar.

Vollkommen unabhängig davon, halte ich die Möglichkeit Eigenschaften scharf zu klassifizieren und durch Vererbung weiterzureichen, für eine SEHR interessanten Ansatz, Disziplin in der Programmierung zu erzwingen - vollkommen unabhängig davon, was in DesignPatterns oder Scott Meyers Büchern steht.
Zumindest bei Scott Meyer weiß ich, dass er seine Bücher nicht als Gott gegebene Regeln ansieht, sondern als Empfehlungen. Und als Empfehlungen sind seine Bücher verdammt gut.

mathik schrieb:

Ist echt ganz schön stur von dir zu behaupten, es sei aus OO Sicht völlig OK, obwohl dir hier schon 100x gezeigt wurde, dass das Murks ist.

Mir wurde schon viel gezeigt und diese Tatsache wird nicht selten auch wieder vergessen, wenn sich die allgemeine Perspektive bewegt hat. Mir 100x das selbe zu zeigen, ein ganzes Forum gegen mich zu haben, nichtmals die Paprikaallergie von CStolls Oma beeindruckt mich diesbezüglich im Entferntesten. Ein einziges sauber und konstruktiv begründetes Argument hingegen kann Welten bewegen.

Shade hat ein Argument gebracht und CStoll hat mir die Augen geöffnet für mein Mißverständnis, so dass ich beiden zugestimmt habe, dass die Komposition in C++ wohl die bessere Wahl ist (Seite 7 afair). Derartige Details interessieren aber offenbar auch dann nicht, wenn ich es wiederhole, weil man sonst nicht weiter so schön gegen mich sein kann.

Den Punkt, den Shade angeführt hat, ist an meinem Source unschön, aber kein K.O.-Kriterium, da man es mit etwas Mehraufwand entsprechend umgehen kann und selbst ein operator bool() in einem Fenster kein Problem darstellt, dass im Alltag eine ernstzunehmende Gefahr darstellt.

Die Möglichkeit bleibt bestehen, ein Fenster als Erweiterung zu seinen Flags zu sehen, auch wenn das ungewöhnlich ist und in dem Source, den ich als Möglichkeit angeboten habe, der operator bool() nicht gefällt. Die Möglichkeit nicht optimal, aber definitiv auch nicht schlecht.

Ansonsten: Lies den Thread und lies, was ich schreibe, nicht was CStoll und/oder Du daraus interpretierst.

[Shade Of Mine]

Xin schrieb:

...und vor allem immer brav im Gleichschritt marschieren und auf keinen Fall Wege suchen, die nicht irgendwer in einem Buch für gut beschrieben hat.

Einfach mal ohne werten zu wollen:

Krankhaft gegen den Mainstream sein ist genauso falsch wie krankhaft mit dem Mainstream sein zu wollen.

Der Mensch hat viele Idee - 99% davon ist Schrott. Es sind die 1% die den Unterschied machen. Diese 1% sind die guten Ideen.

Es ist sehr sehr einfach eine Idee zu haben die anders ist als alle gängigen. Das ist absolut kein Problem. Ich sehe mir ein Auto an und denke mir einfach eckige Räder dazu - tada - ich hab ein Auto das komplett anders ist als alle anderen.

Das Problem ist nun zu erkennen ob diese Idee eine von den 99% oder eine von den 1% ist.

Nun zu diesem konkreten Beispiel:
Deine Idee ist anders als der Mainstream. Aber ist sie besser oder gleichwertig? Ein Haufen Leute hat einen Haufen Gründe genannt warum sie schlechter ist und du kannst keinen nennen warum sie besser ist. Du kannst lediglich die Argumente warum es schlechter ist widerlegen - selbst wenn du aber alle widerlegst bleibt ein Problem bestehen:

Es ist nicht besser als die herkömmliche Lösung - wohl aber anders. Und wenn etwas nur anders aber nicht besser ist, ist es defakto schlechter da es weniger Know-How hier gibt.

Deshalb sollte man immer ganz vorsichtig sein wenn man eine Idee als "gegen den Mainstream" bezeichnet. Denn meistens ist das Ziel einer solchen Idee einfach nur anders zu sein.

[Theston]

Xin schrieb:

Shade hat ein Argument gebracht und CStoll hat mir die Augen geöffnet für mein Mißverständnis, so dass ich beiden zugestimmt habe, dass die Komposition in C++ wohl die bessere Wahl ist (Seite 7 afair). Derartige Details interessieren aber offenbar auch dann nicht, wenn ich es wiederhole, weil man sonst nicht weiter so schön gegen mich sein kann.
[...]
Die Möglichkeit bleibt bestehen, ein Fenster als Erweiterung zu seinen Flags zu sehen, auch wenn das ungewöhnlich ist und in dem Source, den ich als Möglichkeit angeboten habe, der operator bool() nicht gefällt. Die Möglichkeit nicht optimal, aber definitiv auch nicht schlecht.

Die Sache ist doch die, dass deine Probleme, die du offenbar auch siehst, genau deshalb entstanden sind, weil dein Code diesen aufgestellten Thesen widerspricht.
Das ist doch genau der Grund, warum Meyers, Sutter und wie sie alle heißen sowas in ihren Büchern schreiben. Weil sonst Probleme auftreten wie sie hier vielfach aufgedeckt wurden.
Das bool()-Problem z.B. tritt doch auf, weil deine public-Vererbung eben keine "IST-EIN"-Beziehung darstellt.

[scrub]

Xin schrieb:

Shade hat ein Argument gebracht und CStoll hat mir die Augen geöffnet für mein Mißverständnis, so dass ich beiden zugestimmt habe, dass die Komposition in C++ wohl die bessere Wahl ist (Seite 7 afair). Derartige Details interessieren aber offenbar auch dann nicht, wenn ich es wiederhole, weil man sonst nicht weiter so schön gegen mich sein kann.

Auch wenn Du Dir das anscheinend gern selbst einredest, niemand ist aus Prinzip gegen Dich. Das hast Du Dir ganz allein zuzuschreiben. Behauptung.

Begründung:
1. Genau diese Behauptung "alle sind gegen mich" (Arroganz, "ich bin so toll und wichtig, daß ich es wert bin, daß jemand gegen mich ist und dafür seitenweise schreibt")
2. Äußerungen wie "class DeppenWindow"
3. Äußerungen wie "die kids, ihre eltern, blabla"

Ich zitiere einen Mathematikversager: "Schon die Voraussetzungen sind falsch"
Falsche Voraussetzungen sind u.a.:
- "WindowFlags sind Windows"
- "Ein Auto kann eine Farbe sein" <- spätestens hier krieg ich Pipi in die Augen

Übrigens habe ich Deine Zustimmung nicht auf Seite 7 finden können. Daher wäre es sehr nett, wenn Du Dich mal nicht auf dein Gedächtnis verlassen würdest.

Nehmen wir an, sie steht irgendwo anders. Das heißt, Du sagst, daß Deine Alternative "schlechter" ist. Dann mußt Du Dich dafür rechtfertigen, daß Du sie trotzdem verwendest. Da Du natürlich die "bessere" Alternative verstehst, kann es schonmal nicht an mangelnden (Programmier-)Fähigkeiten liegen. Jetzt wirds aber schon hakelig...

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

...und vor allem immer brav im Gleichschritt marschieren und auf keinen Fall Wege suchen, die nicht irgendwer in einem Buch für gut beschrieben hat.

Einfach mal ohne werten zu wollen:

So kann man diskutieren.

Shade Of Mine schrieb:

Krankhaft gegen den Mainstream sein ist genauso falsch wie krankhaft mit dem Mainstream sein zu wollen.

Ich bin nicht krankhaft gegen den Mainstream, denn ich programmiere in den meisten Dingen ja auch nicht anders, als andere Entwickler auch. Das vielleicht mal explizit ausgesprochen - ich bin kein Crack, der möglichst schwer verständlichen Code produzieren will - absolut das Gegenteil ist der Fall.

Wo ich allerdings einen Unterschied ziehe ist, dass ich mich mit meinem Werkzeug - der Programmiersprache - sehr detailiert auseinandersetze und mich auch mit den Dingen beschäftige.
Das schließt auch Techniken ein, die andere als schlecht beschreiben und ich mache mir auch Gedanken, zu Dingen, die mit C++ nicht oder nicht einfach beschreibbar sind.
Vieles ist zurecht als schlecht verrufen und Bücher wie Design Patterns oder die Scott Meyer Bücher sind wertvolle Hilfen, um gut zu programmieren. Sie wurden dafür geschrieben eine Hilfe für gute Programmierung zu sein, aber nicht um als die einzige Wahrheit für gute Programmierung zu gelten.

Was in einem Buch steht, muss weder richtig sein, noch muss ein gutes Buch ein Dogma darstellen. Der Irrglaube, dass Bücher, besonders bei hervorragenden Büchern, kritiklos hinzunehmen sind, ist weit verbreitet. Auch "hervorragend" bedeutet noch nicht "uneingeschränkt gültig".

Alleine die Tatsache jedes Fachbuch sofort und grundsätzlich in Frage zu stellen unterscheidet mich von vielen anderen. Ich sehe Quellen wie Bücher oder dieses Forum als Inspiration, nicht als einzige Wahrheit.

Shade Of Mine schrieb:

Nun zu diesem konkreten Beispiel:
Deine Idee ist anders als der Mainstream. Du kannst lediglich die Argumente warum es schlechter ist widerlegen - selbst wenn du aber alle widerlegst bleibt ein Problem bestehen: wenn etwas nur anders aber nicht besser ist, ist es defakto schlechter da es weniger Know-How hier gibt.

Hier laufen zwei Dinge zusammen. Das eine ist die Klasse Flags und das andere die Vererbung. Die Klasse halte ich nachwie vor für richtig. Was die Vererbung in C++ angeht, so halte ich die Komposition aufgrund Deines Arguments bei meinem Beispiel-Code inzwischen für besser.
Trennt man die die Flags als Variable von den einzelnen Flags als Werten und somit die öffentlichen und privaten Teile, so sehe ich hier die Möglichkeit, dass das ganze besser ist.
Es ist nicht schwer besser als 'Flags & DEFINE_FULLSCREEN' zu sein.

Shade Of Mine schrieb:

Deshalb sollte man immer ganz vorsichtig sein wenn man eine Idee als "gegen den Mainstream" bezeichnet. Denn meistens ist das Ziel einer solchen Idee einfach nur anders zu sein.

Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.
Fakt ist, dass dieses Vorgehen nicht den Mainstream darstellt und damit "anders" ist. Mir geht es nicht, darum anders zu sein. Ich gebe mein Wissen weiter und oder eben hier eine Alternative zur Diskussion. Und ich stelle fest, dass daran nur eine Minderheit interessiert ist. Das ist enttäuschend, aber auch nicht unbedingt wichtig.
Hier geht es mir darum, universell benutzte Datentypen wie int zu vermeiden, darum die Klasse Flags. Das kann man akzeptieren oder lassen oder sich immer wieder auf die Vererbung der Flags stürzen, obwohl in dem Thema längst Einigkeit herrscht.

Das Thema Vererbung als Memberkonzept ist unabhängig davon, eine interessante Möglichkeit anders zu programmieren, der ich durchaus gute Chancen für ein besseres Programmieren zuspreche. Aufwändiger, aber besser. Und besser rechtfertigt für mich bei vielbenutzten Klassen nahezu jeden Aufwand.

[Badestrand]

Xin schrieb:

Mir geht es nicht, darum anders zu sein. Ich gebe mein Wissen weiter und oder eben hier eine Alternative zur Diskussion. Und ich stelle fest, dass daran nur eine Minderheit interessiert ist. Das ist enttäuschend, aber auch nicht unbedingt wichtig.
Hier geht es mir darum, universell benutzte Datentypen wie int zu vermeiden, darum die Klasse Flags. Das kann man akzeptieren oder lassen oder sich immer wieder auf die Vererbung der Flags stürzen, obwohl in dem Thema längst Einigkeit herrscht.

Auch wenn es unwichtig ist: Mich hast du zum nachdenken gebracht, auch wenn ich sicherlich nicht mir nix dir nix auf deine Methode umsteigen werde. Und interessant ist dein Konzept alle mal, jedenfalls wenn ich es richtig verstanden hab

[Xin]

Badestrand schrieb:

Xin schrieb:

Mir geht es nicht, darum anders zu sein. Ich gebe mein Wissen weiter und oder eben hier eine Alternative zur Diskussion. Und ich stelle fest, dass daran nur eine Minderheit interessiert ist. Das ist enttäuschend, aber auch nicht unbedingt wichtig.

Auch wenn es unwichtig ist: Mich hast du zum nachdenken gebracht, auch wenn ich sicherlich nicht mir nix dir nix auf deine Methode umsteigen werde. Und interessant ist dein Konzept alle mal, jedenfalls wenn ich es richtig verstanden hab

Wenn man Menschen nicht dazu veranlassen kann nachzudenken, so ist das nicht wichtig. Es ist nur ein Angebot.
Wenn das Angebot inspirieren konnte, so ist mir das Feedback schon wichtig, denn sonst bräuchte ich es nicht zu probieren.

Dafür musst Du nicht Deine Programmierung nicht ändern. Sich bewußt zu machen, was man tut und was dadurch dass man es tut auf der anderen Seite unterlässt, das ist eingentlich der wichtigste Punkt.
Man kann sich nur dann dazu entscheiden, auch eigene Alternativen zu bauen, wenn frei genug im Denken ist, um überhaupt auf den Gedanken zu kommen, dass Alternativen möglich sind.

[unregistrierter]

Xin schrieb:

Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.

versteh ich nicht, in diesem thread hat doch kein unreg was zum thema beigetragen.
vielleicht solltest du mal von deinem ego trip runterkommen und einsehen dass dein schlechter ruf vielleicht davon verursacht wird, dass du hier so viel müll redest, das versuchst mit fadenscheinigen argumenten aufrechtzuerhalten und wenn das nicht klappt anfängst andere zu beleidigen?

nur zur info: in diesem forum lesen auch viele professionelle entwickler mit, würde mich nicht wundern wenn du dir mit den letzten beiden threads jede menge jobchancen verbaut hast, auch wenn du es vermutlich niemals bestätigt bekommen wirst

[Xin]

unregistrierter schrieb:

Xin schrieb:

Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.

versteh ich nicht, in diesem thread hat doch kein unreg was zum thema beigetragen.

Gratuliere, Du hast die Kritik verstanden und gleichzeitig bestätigt.

[jaja...]

Xin schrieb:

Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.

Leute werden nicht aufgrund ihres namens verarscht, sondern aufgrund ihres verhaltens.

[unregistrierter]

Xin schrieb:

unregistrierter schrieb:

Xin schrieb:

Meinen Ruf habe ich in diesem Forum ja bereits weg, ein kleines Rudel "Unregistrierter" sorgt bei nahezu jedem Posting dafür, dass das auch ja nicht vergessen wird.

versteh ich nicht, in diesem thread hat doch kein unreg was zum thema beigetragen.

Gratuliere, Du hast die Kritik verstanden und gleichzeitig bestätigt.

du verstehst auch jeden post so, damit du ihn dir so zurechtrücken kannst wie du willst oder?

[CStoll]

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.

Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.

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

Vielleicht macht Dir diese Antwort verständlich, wie krampfhaft ich versuche Dich von etwas zu überzeugen. Denk selbst drüber nach, oder lass es - es zwingt Dich niemand.

Schön, daß du jetzt anfängst, meine Beiträge inhaltlich zu ignorieren.

OK, fassen wir nochmal die bisherigen Beispiele zusammen, die laufen alle auf einen ähnlichen Denkfehler hinaus: Du kannst mit Ableitung die Fähigkeiten einer Klasse erweitern, aber nicht einschränken.

• WindowFlags vs. Window:
  Die Klasse WindowFlags hat einen operator bool() (und auch wenn du das "s" noch so sehr betonst, ein einzelnes Flag ist auch von diesem Typ), die Klasse Window als bool zu betrachten ist sinnlos (und wenn nicht, dann mit einer völlig anderen Semantik als für WindowFlags). Da ist es egal, ob du eine technische (op bool ist privat und der Compiler beschwert sich, wenn man es nutzen will) oder konzeptionelle (irgendwo in der Doku steht "benutze nie 'if(win)...'") Einschränkung hast - du hast eine Einschränkung.
  (und im Ernstfall sind mir technische Einschränkungen lieber)

• Ableitungen von int:
  Du hast alle Maßangaben (Längen, Gewichte etc) von int abgeleitet, um Schreibarbeit zu sparen. Aber damit hast du gleichzeitig massenweise Mehraufwand, um sie vernünftig nutzen zu können:

• Alle Operatoren liefern int-Werte, also brauchst du entweder Typumwandlungen von int in deine Typen (aber dann geht die Typsicherheit verloren, wenn du beliebig Gewichte und Längen miteinander verwursten kannst) oder eigene überladene Operatoren (aber dann brauchst du die Verwandtschaft mit int nicht mehr)

• btw, op+ und op- zu überladen mag ja noch recht einfach sein, aber bei op* und op/ wird's dann haarig (die schlucken zwei beliebige Maßangaben und geben eine völlig andere Angabe wieder heraus) - davon, was bei op& und Co. rauskommen sollte, will ich gar nicht anfangen.
  (erzähl mir jetzt bitte nichts von Templates - ich kenne eine Template-Lösung dafür, aber die braucht keine Vererbung von int)

• Wertekombination durch Vererbung:
  In den wenigstens Fällen sind die Attribute eines Objekts unabhängig voneinander (die Maximalgeschwindigkeit eines Autos hängt von der Motorleistung ab, die linke obere Ecke eines Fensters von der rechten oberen Ecke etc). Die einzelnen Basisklassen sind aber konzeptionell unabhängig voneinander - also mußt du in der abgeleiteten Klasse dafür sorgen, daß sie sich konsistent zueinander ändern.

PS: Die Allergie hatte ich übrigens erwähnt, weil du mit den Allergiewarnungen angefangen hast - es gibt halt auch Menschen, die unter mehr leiden als einem (eher harmlosen) Heuschnupfen (btw, ich kenne auch jemanden mit einer Nussallergie). Und die sind dankbar, wenn sie rechtzeitig über (potentiell) gefährliche Nahrungsmittel informiert werden.

PPS: Mich hast du übrigens auch zum Nachdenken gebracht - mit dem Ergebnis, daß ich deine Lösung nach längerem Nachdenken als unsinnig eingestuft habe.

[Xin]

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.

Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.

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

Vielleicht macht Dir diese Antwort verständlich, wie krampfhaft ich versuche Dich von etwas zu überzeugen. Denk selbst drüber nach, oder lass es - es zwingt Dich niemand.

Schön, daß du jetzt anfängst, meine Beiträge inhaltlich zu ignorieren.

Sorry, aber inhaltlich kam nicht mehr viel und Du spielst hier ein unsinniges Spiel mit mir: Antworten, um dagegen zu sein. Dass ich seit x Seiten Dir zustimme, dass die Komposition in C++ besser als die Ableitung ist, ignorierst Du und behauptest auch noch, dass ich krampfhaft versuche zu erklären, dass Vererbung besser wäre.
Wo soll ich denn einen Grund sehen, Dich da inhaltlich überhaupt zu beachten.

CStoll schrieb:

OK, fassen wir nochmal die bisherigen Beispiele zusammen,

Wir? Wer ist "wir"?

Ich fasse es mal so auf, dass Du zusammenfasst und ich ergänze.

CStoll schrieb:

WindowFlags vs. Window:
Die Klasse WindowFlags hat einen operator bool() (und auch wenn du das "s" noch so sehr betonst, ein einzelnes Flag ist auch von diesem Typ),

Hier ignorierst Du erstens mehrfach genannte Möglichkeit das durch Trennung in zwei Klassen zu ändern... und die oben genannte Tatsache, dass ich die Komposition seit Seite iirc 7 als die bessere Möglichkeit ansehe...

CStoll schrieb:

die Klasse Window als bool zu betrachten ist sinnlos (und wenn nicht, dann mit einer völlig anderen Semantik als für WindowFlags). Da ist es egal, ob du eine technische (op bool ist privat und der Compiler beschwert sich, wenn man es nutzen will) oder konzeptionelle (irgendwo in der Doku steht "benutze nie 'if(win)...'") Einschränkung hast - du hast eine Einschränkung.
(und im Ernstfall sind mir technische Einschränkungen lieber)

Welche technische Einschränkung bietet Dir denn ein "int Flags", die "übliche" und bewerte "Technik".
Selbst, wenn ich ableite (Komposition in C++ besser, S. 7. blahblah), bin ich besser eingeschränkt, als mit einem popligen int, dass mangels Typ eigentlich alles darstellen kann.
Halt stop, nicht alles, es stellt zum Beispiel definitiv keine Zahl dar. Müsstest Du hier nicht operator + und operator -, und operator * und operator / erstmal abschalten, bevor Du hier was von technischen Einschränkungen schreibst?

Schließe Dein Scheunentor und dann reden wir weiter. Und um Dein Scheunentor zu schließen, wirst Du vermutlich wieder bei class WindowFlags landen.

Noch ein "Detail", das in Deiner "Zusammenfassung" fehlt.

CStoll schrieb:

Ableitungen von int:
Du hast alle Maßangaben (Längen, Gewichte etc) von int abgeleitet, um Schreibarbeit zu sparen. Aber damit hast du gleichzeitig massenweise Mehraufwand, um sie vernünftig nutzen zu können:

Uii... Mehraufwand, um Typsicher zu arbeiten?!
Hier liegen die Prioritäten definitiv anders. Aber wer überhaupt Klassen nutzt, sollte sich nicht über Mehraufwand beschweren, denn früher wurde sowas alles auch problemlos mit Arrays gelöst. Für die Typsicherheit hat man sich dann doch für den Mehraufwand der Klassen entscheiden und sicherlich möchtest Du heute auch nicht mehr zu Byte-Arrays zurückkehren.

CStoll schrieb:

Alle Operatoren liefern int-Werte, also brauchst du entweder Typumwandlungen von int in deine Typen (aber dann geht die Typsicherheit verloren, wenn du beliebig Gewichte und Längen miteinander verwursten kannst) oder eigene überladene Operatoren (aber dann brauchst du die Verwandtschaft mit int nicht mehr)

Ich sehe in der Verwandschaft mit "Zahl" nichts schlechtes.

int p = Quarktaschen( 3 ) + Zitronenkuchen( 2 ) + Kaesekuchen( 5 );
cout "Genug Futter für " << p << "Personen da." << endl;

CStoll schrieb:

btw, op+ und op- zu überladen mag ja noch recht einfach sein, aber bei op* und op/ wird's dann haarig (die schlucken zwei beliebige Maßangaben und geben eine völlig andere Angabe wieder heraus) - davon, was bei op& und Co. rauskommen sollte, will ich gar nicht anfangen.

Damit solltest Du aber anfangen, weil es die Qualität Deiner Software erhöht.
5 Kilogramm * 20 Meter / 4Sekunde^2 ergibt nunmal nicht 25.

CStoll schrieb:

(erzähl mir jetzt bitte nichts von Templates - ich kenne eine Template-Lösung dafür, aber die braucht keine Vererbung von int)

Ich erzähle hier nichts von Templates - ich habe keine, aber ich bin gespannt, Deine Templatelösung zu sehen, die mir die Verbindung von Newton zu den Grundeinheiten erstellt.

CStoll schrieb:

[*]Wertekombination durch Vererbung:
In den wenigstens Fällen sind die Attribute eines Objekts unabhängig voneinander (die Maximalgeschwindigkeit eines Autos hängt von der Motorleistung ab, die linke obere Ecke eines Fensters von der rechten oberen Ecke etc). Die einzelnen Basisklassen sind aber konzeptionell unabhängig voneinander - also mußt du in der abgeleiteten Klasse dafür sorgen, daß sie sich konsistent zueinander ändern.

Stimmt. Und wo liegt das Problem?
Mal abgesehen davon, dass die Relation zwischen zwei Eigenschaften bei Vererbung und Komposition beschrieben werden muss - woher soll der Computer sie schließlich wissen.
Das ist hier ungefähr so wichtig, wie die Paprikaallergie Deiner Oma.

CStoll schrieb:

PS: Die Allergie hatte ich übrigens erwähnt, weil du mit den Allergiewarnungen angefangen hast - es gibt halt auch Menschen, die unter mehr leiden als einem (eher harmlosen) Heuschnupfen (btw, ich kenne auch jemanden mit einer Nussallergie). Und die sind dankbar, wenn sie rechtzeitig über (potentiell) gefährliche Nahrungsmittel informiert werden.

...

Wer als Nussallergiker Nüsse kauft, braucht den Hinweis nicht. Sollte er ihn doch brauchen, ist er vorrangig Intelligenzallergiker. Wann begreifst Du, dass die Aussage sich nicht auf die Allergie bezieht, sondern auf die Intelligenzleistung, die erforderlich ist, dass man als Nussallergiker nunmal keine Nüsse kauft, selbst wenn da keine Warnung auf der Packung steht...
Deine Oma kauft ja auch keine Paprika, wenn sie dagegen allergisch ist und Du wirst vermutlich niemals das Gras eines Fussballstadions pflegen, obwohl weder auf Paprika, noch auf dem Rasen Warnhinweise für Allergiker angebracht sind...

CStoll schrieb:

PPS: Mich hast du übrigens auch zum Nachdenken gebracht - mit dem Ergebnis, daß ich deine Lösung nach längerem Nachdenken als unsinnig eingestuft habe.

Das 'längere Nachdenken' glaube ich Dir ehrlich gesagt nicht. Wer nachdenkt stellt Fragen und keine Behauptungen auf. Wer nachdenkt nimmt Informationen auf. Du konzentrierst Dich seit mehreren Seiten darauf, gegen etwas zu sein, dass nicht mehr zur Debatte steht, weil wir uns darüber schon einig waren. Es war Dir offenbar trotz längerem Nachdenken nicht möglich die unterschiedliche Themen zwischen Vererbung für Flags, WindowFlags und Typsicherung entsprechend voneinander gelöst zu besprechen.
Das Thema Vererbung für Flags ist seit x Seiten geklärt, erledigt, vorbei.
Du drängst mich mit jedem Posting in eine Position, die ich gar nicht mehr vertrete (Seite 7... Komposition besser in C++... jaddajadda...)
Und dass einige Dinge hier hypothetischer Natur sind, sollte Dir spätestens daran auffallen, wenn ich "class Meter : public int" schreibe, weil in C++ es nicht möglich ist von Primitiven abzuleiten.

Deine "Zusammenfassung" ist eine Zusammenfassung Deiner Sichtweise. Da ist alles drin, was Du brauchst, um dagegen zu sein, aber nichts, was darauf hinweist, dass Du meine Texte gelesen hättest.
Das hat nichts mit denken zu tun, sondern dass ist einfach nur weiter texten, hübsch kombiniert mit

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.

Vielleicht kommt es in der x. Wiederholung bei Dir an: Ich zwinge Dich nicht, etwas zu nutzen. Ich zwinge Dir auch nicht ein Verständnis für Typsicherheit auf. Du kannst meinetwegen programmieren was und wie Du willst.
Alles, was ich hier angeboten habe, war eine Möglichkeit, typsicherer zu arbeiten. Diese Möglichkeit dient als Inspirationshilfe, die weiterhin verbesserungsfähig ist, was auch schon x mal geschrieben wurde.
Und ich habe keinen Bock auch nur eine weitere Seite in diesem Thread, Dich darauf aufmerksam zu machen.
Und darum habe ich auch kein Problem damit, dass Du Dich von mir inhaltlich ignoriert fühlst.

[scrub]

Vielleicht kommt es bei der xten Wiederholung bei Dir an:

1. Auf Seite 7 kann ich Deine Zustimmung, Komposition sei in dem Fall besser als Vererbung, nicht finden. Also such sie gefälligst bitteschön und schreib endlich die richtige Seitenzahl hin! Ebenfalls ist es möglich, daß Du Dich wie üblich diffus ausgedrückt hast- dann zitier einfach Deine Zustimmung mal!
2. Deine indirekte Selbstbeweihräucherung ist dumm. Diesmal keine Begründung mehr für meine Behauptung.

[Code Tag du Quarktasche]

Xin schrieb:

int p = Quarktaschen( 3 ) + Zitronenkuchen( 2 ) + Kaesekuchen( 5 );
cout "Genug Futter für " << p << "Personen da." << endl;

int p = Quarktaschen( 3 ) + Zitronenkuchen( 2 ) + Kaesekuchen( 5 );
cout << "Genug Futter für " << p << "Personen da." << endl;

[CStoll]

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Schön, wenn du eine Sprache hast, die zwischen Zuständen und Teilobjekten unterscheiden kann. C++ kann das leider nicht, also brauchst du gar nicht versuchen, es dazu zu bringen.

Super Einstellung. "Ich" kann das nicht, also brauchst "Du" es nicht zu versuchen.
Ich versuche es trotzdem. Sich derart dagegen zu wehren bringt aber nix, ich zwinge schließlich niemanden hier, es zu nutzen.

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

Vielleicht macht Dir diese Antwort verständlich, wie krampfhaft ich versuche Dich von etwas zu überzeugen. Denk selbst drüber nach, oder lass es - es zwingt Dich niemand.

Schön, daß du jetzt anfängst, meine Beiträge inhaltlich zu ignorieren.

Sorry, aber inhaltlich kam nicht mehr viel und Du spielst hier ein unsinniges Spiel mit mir: Antworten, um dagegen zu sein. Dass ich seit x Seiten Dir zustimme, dass die Komposition in C++ besser als die Ableitung ist, ignorierst Du und behauptest auch noch, dass ich krampfhaft versuche zu erklären, dass Vererbung besser wäre.
Wo soll ich denn einen Grund sehen, Dich da inhaltlich überhaupt zu beachten.

Wenn du mir irgendwo zugestimmt hast, dann vermutlich in einem kleinen Nebensatz, der in den ganzen "Ableitung ist besser/schöner/leichter verständlich"-Beiträgen untergegangen ist.

Xin schrieb:

CStoll schrieb:

OK, fassen wir nochmal die bisherigen Beispiele zusammen,

Wir? Wer ist "wir"?

Ich fasse es mal so auf, dass Du zusammenfasst und ich ergänze.

Ja, so kannst du es auffassen.

Xin schrieb:

CStoll schrieb:

WindowFlags vs. Window:
Die Klasse WindowFlags hat einen operator bool() (und auch wenn du das "s" noch so sehr betonst, ein einzelnes Flag ist auch von diesem Typ),

Hier ignorierst Du erstens mehrfach genannte Möglichkeit das durch Trennung in zwei Klassen zu ändern... und die oben genannte Tatsache, dass ich die Komposition seit Seite iirc 7 als die bessere Möglichkeit ansehe...

Ja, diese Trennung hast du zwar erwähnt, aber im selben Satz wieder aufgehoben, indem du WindowFlags von WindowFlag ableiten wolltest. Und gegen eine saubere Trennung von "Flag" und "Flags" (bzw. Flaggable) habe ich auch nichts einzuwenden.

Xin schrieb:

CStoll schrieb:

die Klasse Window als bool zu betrachten ist sinnlos (und wenn nicht, dann mit einer völlig anderen Semantik als für WindowFlags). Da ist es egal, ob du eine technische (op bool ist privat und der Compiler beschwert sich, wenn man es nutzen will) oder konzeptionelle (irgendwo in der Doku steht "benutze nie 'if(win)...'") Einschränkung hast - du hast eine Einschränkung.
(und im Ernstfall sind mir technische Einschränkungen lieber)

Welche technische Einschränkung bietet Dir denn ein "int Flags", die "übliche" und bewerte "Technik".
Selbst, wenn ich ableite (Komposition in C++ besser, S. 7. blahblah), bin ich besser eingeschränkt, als mit einem popligen int, dass mangels Typ eigentlich alles darstellen kann.

Nein, ich verwende keinen "int Flags" - und wenn doch, kommt der Nutzer da nicht ohne weiteres dran. Ich biete dem Nutzer eine typsichere (und alleine existierende) Flag-Klasse und Methoden zum Setzen, Rücksetzen und abfragen von Flags in meinen Klassen.

Xin schrieb:

Schließe Dein Scheunentor und dann reden wir weiter. Und um Dein Scheunentor zu schließen, wirst Du vermutlich wieder bei class WindowFlags landen.

Die Klasse WindowFlags hatte ich schon recht weit vorne akzeptiert, nur nicht die Tatsache, daß du Flags und Flag in ein und die selbe Klasse gepackt hast.

Xin schrieb:

CStoll schrieb:

Ableitungen von int:
Du hast alle Maßangaben (Längen, Gewichte etc) von int abgeleitet, um Schreibarbeit zu sparen. Aber damit hast du gleichzeitig massenweise Mehraufwand, um sie vernünftig nutzen zu können:

Uii... Mehraufwand, um Typsicher zu arbeiten?!
Hier liegen die Prioritäten definitiv anders. Aber wer überhaupt Klassen nutzt, sollte sich nicht über Mehraufwand beschweren, denn früher wurde sowas alles auch problemlos mit Arrays gelöst. Für die Typsicherheit hat man sich dann doch für den Mehraufwand der Klassen entscheiden und sicherlich möchtest Du heute auch nicht mehr zu Byte-Arrays zurückkehren.

Du arbeitest aber nicht besonders typsicher, wenn alles ein int ist - und irgendwo ganz hinten dann festgestellt wird, daß das doch nicht der Fall ist. Und der Aufwand bleibt sich gleich, ob du nun von int ableitest oder int als Member verwendest - allerdings bei ersterem bleibt es viel länger unentdeckt, wenn du etwas übersiehst.

Xin schrieb:

CStoll schrieb:

Alle Operatoren liefern int-Werte, also brauchst du entweder Typumwandlungen von int in deine Typen (aber dann geht die Typsicherheit verloren, wenn du beliebig Gewichte und Längen miteinander verwursten kannst) oder eigene überladene Operatoren (aber dann brauchst du die Verwandtschaft mit int nicht mehr)

Ich sehe in der Verwandschaft mit "Zahl" nichts schlechtes.

int p = Quarktaschen( 3 ) + Zitronenkuchen( 2 ) + Kaesekuchen( 5 );
cout "Genug Futter für " << p << "Personen da." << endl;

Verschiedene Kuchensorten sind sich vielleicht noch ähnlich genug, um so behandelt zu werden, aber was soll physikalisch herauskommen, wenn ich meine Körpergröße mit meinem Gewicht addiere?

Xin schrieb:

CStoll schrieb:

btw, op+ und op- zu überladen mag ja noch recht einfach sein, aber bei op* und op/ wird's dann haarig (die schlucken zwei beliebige Maßangaben und geben eine völlig andere Angabe wieder heraus) - davon, was bei op& und Co. rauskommen sollte, will ich gar nicht anfangen.

Damit solltest Du aber anfangen, weil es die Qualität Deiner Software erhöht.
5 Kilogramm * 20 Meter / 4Sekunde^2 ergibt nunmal nicht 25.

Mit deinem Ansatz schon - und genau darauf wollte ich auch hinaus: Woher soll der Compiler wissen, was für ein Typ herauskommen soll, wenn du zwei wahllos herausgegriffene int-Derivate multiplizierst?

Xin schrieb:

CStoll schrieb:

(erzähl mir jetzt bitte nichts von Templates - ich kenne eine Template-Lösung dafür, aber die braucht keine Vererbung von int)

Ich erzähle hier nichts von Templates - ich habe keine, aber ich bin gespannt, Deine Templatelösung zu sehen, die mir die Verbindung von Newton zu den Grundeinheiten erstellt.

Nur grob skizziert und auch noch nicht vollständig:

template<int Meter,int Sekunde,int Kilogramm,...>
class Measure
{
  double val;
public:
  Measure operator+(const Measure&r)
  { return Measure(val+r.val); }

  template<int M2,int S2,int K2,...>
  Measure<Meter+M2,Sekunde+S2,Kilogramm+K2,...> operator*(const Measure<M2,S2,K2,...>& r)
  { return Measure<Meter+M2,Sekunde+S2,Kilogramm+K2,...>(val*r.val); }
  ...
};

typedef Measure<1,0,0,...> Laenge;
typedef Measure<0,1,0,...> Zeit;
typedef Measure<0,0,1,...> Masse;
...
typedef Measure<1,-2,1,...> Kraft;// 1 N == 1 m * s^-2 * kg

Xin schrieb:

CStoll schrieb:

[*]Wertekombination durch Vererbung:
In den wenigstens Fällen sind die Attribute eines Objekts unabhängig voneinander (die Maximalgeschwindigkeit eines Autos hängt von der Motorleistung ab, die linke obere Ecke eines Fensters von der rechten oberen Ecke etc). Die einzelnen Basisklassen sind aber konzeptionell unabhängig voneinander - also mußt du in der abgeleiteten Klasse dafür sorgen, daß sie sich konsistent zueinander ändern.

Stimmt. Und wo liegt das Problem?
Mal abgesehen davon, dass die Relation zwischen zwei Eigenschaften bei Vererbung und Komposition beschrieben werden muss - woher soll der Computer sie schließlich wissen.
Das ist hier ungefähr so wichtig, wie die Paprikaallergie Deiner Oma.

Bei Komposition speicher ich nur die Grundeigenschaften des Objekts (z.B. reichen zwei Ecken aus, um die Lage des Fensters zu beschreiben) und berechne den Rest auf Verlangen - bei Vererbung hast du vier Punkte und mußt die dazugehörigen Zuweisungsoperatoren manuell anpassen. Zeig mir doch mal, wie du die Zuweisung "wnd = PointUpperLeft(47,11);" implementieren würdest.

Xin schrieb:

CStoll schrieb:

PS: Die Allergie hatte ich übrigens erwähnt, weil du mit den Allergiewarnungen angefangen hast - es gibt halt auch Menschen, die unter mehr leiden als einem (eher harmlosen) Heuschnupfen (btw, ich kenne auch jemanden mit einer Nussallergie). Und die sind dankbar, wenn sie rechtzeitig über (potentiell) gefährliche Nahrungsmittel informiert werden.

...

Wer als Nussallergiker Nüsse kauft, braucht den Hinweis nicht. Sollte er ihn doch brauchen, ist er vorrangig Intelligenzallergiker. Wann begreifst Du, dass die Aussage sich nicht auf die Allergie bezieht, sondern auf die Intelligenzleistung, die erforderlich ist, dass man als Nussallergiker nunmal keine Nüsse kauft, selbst wenn da keine Warnung auf der Packung steht...
Deine Oma kauft ja auch keine Paprika, wenn sie dagegen allergisch ist und Du wirst vermutlich niemals das Gras eines Fussballstadions pflegen, obwohl weder auf Paprika, noch auf dem Rasen Warnhinweise für Allergiker angebracht sind...

Nein, du begreifst immer noch nicht, wozu diese Warnungen da sind - und daß sie nicht nur auf Produkten stehen, die "offensichtlich" Nüsse enthalten.

Ein Beispiel: In Weizenmüsli sind normalerweise keine Nüsse enthalten, also ist es für den Allergiker unbedenklich. Aber der selbe Hersteller produziert auch Müsliflocken mit Nuss - und wer sagt dem Allergiker jetzt, daß er nicht die selbe Abfüllanlage wahlweise für Nuss-Müsli und Weizenmüsli verwendet? (und selbst bei perfekter Hygiene ist nicht 100% auszuschließen, daß doch einige Nuss-Reste in die Weizenflocken geraten)

Xin schrieb:

Vielleicht kommt es in der x. Wiederholung bei Dir an: Ich zwinge Dich nicht, etwas zu nutzen. Ich zwinge Dir auch nicht ein Verständnis für Typsicherheit auf. Du kannst meinetwegen programmieren was und wie Du willst.
Alles, was ich hier angeboten habe, war eine Möglichkeit, typsicherer zu arbeiten. Diese Möglichkeit dient als Inspirationshilfe, die weiterhin verbesserungsfähig ist, was auch schon x mal geschrieben wurde.
Und ich habe keinen Bock auch nur eine weitere Seite in diesem Thread, Dich darauf aufmerksam zu machen.
Und darum habe ich auch kein Problem damit, dass Du Dich von mir inhaltlich ignoriert fühlst.

Ja, du setzt Vererbung ein - und anschließend brauchst du Hilfskonstruktionen, um die damit verbundenen Schwachpunkte wieder auszugleichen. Und diese sehen schlimmer aus als alles, was ich ohne Vererbung entwickelt hätte. Der Grundansatz, Flags zur Sicherung der Typsicherheit in eine eigene Klasse zu packen, ist gut - aber warum du von dieser Klasse unbedingt erben mußt, konntest du bisher nicht vermitteln. (oder hast du diese Vererbungsbeziehung auch nur eingebaut, weil sie deinen Typerweiterungen am ähnlichsten sah?)