Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

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.

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.

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.

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.

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

Xin

scrub schrieb:

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!

Fangen wir mal an auf Seite 3: Hier kann ich schonmal klar rauslesen, dass Komposition eine Möglichkeit von vielen ist und ich lese keine Wertung, dass es eine schlechte wäre.

Xin schrieb:

CStoll schrieb:

Da ist es mir lieber, genau zu wissen, wann ich denn nun auf die Flags zugreife (Sprich: Im Endeffekt kann ich mich mit der Flag-Klasse schon anfreunden, aber die Vererbungsbeziehung halte ich immer noch für sinnlos).

Damit kann ich gut leben. Hier stellst Du klar, dass es Dir nicht gefällt [...]. Es ist eine Möglichkeit und es gibt viele Möglichkeiten in C++ Daten zu verarbeiten.

Das es mir nich um "krampfhafte Überzeugungversuche" geht, findet sich auf Seite 4.

Xin schrieb:

Jede Perspektive hat Vor- und Nachteile. Nur weil wir in der strukturierten Programmierung Flags als Teil einer Struktur begreifen mussten, muss eine Struktur als Erweiterung von Flags keine Nachteile bringen.
Die Frage ist, wo holt man die meisten Vorteile heraus.

oder Seite 5:

Xin schrieb:

Dir gefällt die Idee nicht, das ist okay.

Auf Seite 6 auch mal die Wertung zur Komposition:

Xin schrieb:

Es ist technisch gleichwertig zu w->Mode.

Und bevor sich hier CStoll mit seinen Verträgen anfängt, es bezieht sich auf die Memberbeziehung der Vererbung.

Weiter auf Seite 6 sieht man auch, dass ich mich kritisch mit meinen Sourcen auseinandersetze und nicht auf krampfhafte Überzeugungsarbeit aus bin:

Xin schrieb:

Ich habe übrigens ein Argument gegen die mehrfache Verwendung, das ihr noch nicht habt. -erklärung-

Kommen wir nun auf Seite 7:

Xin schrieb:

CStoll schrieb:
PS: Ich hab' nochmal über die Typerweiterungen nachgedacht - und in C++ sind die wohl besser mit Konvertierungsoperatoren darstellbar:
class WinFlag {...};
class Window
{
  WinFlag f;
public:
  operator WinFlag&() {return f;}
  ...
};
Dem stimme ich zu.

Falls es jemanden auffällt... Ich stimme ihm zu, dass er einen Konvertierungsoperator nimmt.

Wenn man die Bedeutung jetzt nicht sofort begreift, dann überlege man kurz, dass er auf einen Member konvertiert, weil er eine Komposition hat - bei Vererbung müsste er schließlich nicht konvertieren. Komposition in C++ besser geeignet als Vererbung. Das steht da.
Den Thread zu verfolgen hilft, denn die Bedeutung erschließt sich um so einfacher, wenn man davor gelesen hat, dass das Ganze aufgrund Mehrdeutigkeiten bei Mehrfachvererbung von Flags entstanden ist.

CStoll ging darauf nicht weiter ein - wozu auch, denn es herschte Einigkeit.
Wenn Dir das zu diffus ist, meinetwegen. Darum habe ich auf den nachfolgenden Seiten auch immer mal wieder festgestellt, dass ich nicht gegen Komposition bin. Nur für den Fall.
Aber das geht ja auch unter.

Zu dem "Also such sie gefälligst"... Denk Dir eine gefälligst eine entsprechend freundliche Antwort dazu, schließlich spielt es keine Rolle, was ich schreibe - ich begehe sowieso nur indirekte Selbstbeweihräucherung, dient Unregistrierten, um irgendwelche unqualifizierten Postings zu setzen oder wird direkt ignoriert.
In diesem Sinne...

CStoll schrieb:

Xin schrieb:

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.

Naja, "Dem stimme ich zu" ist kein Nebensatz und es wäre es für eine Argumentation natürlich durchaus sinnvoll sich anzusehen, wo ich zustimme und was das für Deine Argumentation bedeutet.

CStoll schrieb:

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.

Wo habe ich sie wieder aufgehoben!?

CStoll schrieb:

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.

An meine Flags da muss auch keiner rankommen. Man kann aber, was mich nicht sonderlich stört, da ich so Window als Erweiterung von WindowFlags beschreibe und ich diese Perspektive als legitim ansehe.
Ich habe die einzelnen Flags als konstante Instanzen von WindowFlags beschrieben, weil ich keine Lust hatte, dafür eine zweite Klasse WindowFlag zu definieren. Das hindert aber niemanden, die Trennung sauberer zu vollziehen.
Da WindowFlags und Window eine Einheit bilden, stört mich das nicht.
Die klare Trennung von WindowFlags und WindowFlag sehen wir beide für die optimale Lösung.
Kömmen wir hier auf einen gemeinsamen Nenner?

CStoll schrieb:

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.

Jow, Deine Akzeptanz der WindowFlags Klasse habe ich schon mitbekommen.
Der Vorschlag die einzelnen Flags in eine Klasse WindowFlag zu packen, kam afair von mir, als Reaktion auf die Kritik, dass die Flags im Namensraum des Windows erscheinen.

CStoll schrieb:

Xin schrieb:

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

Es ist nicht alles ein int, es ist alles int-verwandt.

int a;
Meter m,n;
Meter result;

result = m + n;      // geht, ergibt Meter
a = result;          // geht, ergibt Typlose Zahl
result = a;          // geht nicht, da nicht vom Typ Meter.
result = Meter( a ); // geht, explizite Typvorgabe

Edit: Ja, ich weiß, dass das auch über operator int() geht... es geht nicht darum, ob etwas möglich ist, sondern die Dinge aus verschiedenen Perspektiven zu betrachten.

CStoll schrieb:

Xin schrieb:

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?

Es kommt das gleiche raus, als würdest Du das mit ints machen. Eine typlose Zahl.
Nur weil Du damit nichts anfangen kannst, ist Körpergröße mit dem Gewicht zu addieren eine legitime Anfrage.
Ich sehe keinen Grund, die Beantwortung der Frage zu verweigern, nur weil ich grade nicht weiß, wozu das gut sein soll.

CStoll schrieb:

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?

Jow, wenn der Compiler Newton nicht kennt, bekomme ich eine typlose 25 raus.
Anstatt mich darüber zu ärgern, dass ich das nicht kompilieren kann, habe ich wenigstens ein Ergebnis.
Wenn ich verschiedene Kuchensorten addiere, dann bekomme ich auch nur eine kuchentyplose Zahl raus und keine Personenanzahl. Ich kann aber mit der Zahl weiterarbeiten und ich kann die Zahl nicht einfach auf einen anderen Typ zuweisen.
Wenn die Formel nicht implementiert ist, kann ich
Newton n = KiloGramm( 5 ) * Meter( 20 ) / QuadratSekunde(4);
nicht zuweisen.

Ich muss wissen, was ich tue, aber wenn ich das weiß, kann ich weiterarbeiten:
Newton n = Newton( KiloGramm( 5 ) * Meter( 20 ) / QuadratSekunde(4) );

CStoll schrieb:

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 {...};

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

Netter Ansatz.

CStoll schrieb:

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.

Gar nicht, der Punkt oben Links wäre automatisch als Klasse ansprechbar und würde damit gesetzt.

PointUpperRight hingegen würde per Operator erledigt, da PointUpperLeft und PointLowerRight oder Area entsprechend überarbeitet werden müssen. Hier habe ich den gleichen Aufwand, wie Du.
Erbe ich all diese Punkte allerdings direkt von class Field, brauche ich mich um nichts mehr zu kümmern, sondern würde die ganze Funktionalität über using einbinden.

CStoll schrieb:

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.

Ich stelle die Warnungen auf anderen Lebensmittel nicht in Frage.
Ich spreche ausschließlich Warnungen vor Nüssen auf Nusspackungen. Ist das so schwer zu begreifen?
Sind Nüsse in Nusspackungen wirklich so überraschend, dass man davor warnen muss?

CStoll schrieb:

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,

... Ich spreche die ganze Zeit von "Möglichkeit", von "Alternative", nicht vom "Muss" oder "Zwang".
Bitte höre auf, in meine Aussagen irgendwas reinzubasteln, was ich nicht sage.

CStoll schrieb:

konntest du bisher nicht vermitteln. (oder hast du diese Vererbungsbeziehung auch nur eingebaut, weil sie deinen Typerweiterungen am ähnlichsten sah?)

... lohnt es sich überhaupt, darauf nochmals zu antworten?

Immerhin habe ich schon geschrieben, dass ich das aus Genesys übernommen habe und mir den einfachsten Weg ausgesucht habe, um das in C++ zu nutzen. Und fang jetzt bitte nicht an, mir etwas zu erzählen, dass man nicht einfach von einer Sprache auf die andere übertragen kann, ich habe diesen Thread gelesen und ich habe keinen Bock auf noch eine Wiederholung.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

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?

Es kommt das gleiche raus, als würdest Du das mit ints machen. Eine typlose Zahl.
Nur weil Du damit nichts anfangen kannst, ist Körpergröße mit dem Gewicht zu addieren eine legitime Anfrage.
Ich sehe keinen Grund, die Beantwortung der Frage zu verweigern, nur weil ich grade nicht weiß, wozu das gut sein soll.

Durch Beantwortung der Frage würde man den Mathematikern ins Gesicht schlagen
Anderst wird es noch deutlicher (und lustiger) ... 3 Bäume - 8 Häuser = ?
Es macht definitiv keinen Sinn solch eine Frage zu stellen!

Darum geht es doch auch bei der Typsicherheit, man beschränkt Methoden/Operationen auf Typen mit denen sie auch Sinn ergeben kann.
Bzw. funktioniert die Methode/Operation auch nur mit Objekten des Typs, mit dem es Sinn ergibt. (Je nach Art der Typisierung)

Xin

Tellerrand schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

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?

Es kommt das gleiche raus, als würdest Du das mit ints machen. Eine typlose Zahl.
Nur weil Du damit nichts anfangen kannst, ist Körpergröße mit dem Gewicht zu addieren eine legitime Anfrage.
Ich sehe keinen Grund, die Beantwortung der Frage zu verweigern, nur weil ich grade nicht weiß, wozu das gut sein soll.

Durch Beantwortung der Frage würde man den Mathematikern ins Gesicht schlagen
Anderst wird es noch deutlicher (und lustiger) ... 3 Bäume - 8 Häuser = ?
Es macht definitiv keinen Sinn solch eine Frage zu stellen!

Darum geht es doch auch bei der Typsicherheit, man beschränkt Methoden/Operationen auf Typen mit denen sie auch Sinn ergeben kann.
Bzw. funktioniert die Methode/Operation auch nur mit Objekten des Typs, mit dem es Sinn ergibt. (Je nach Art der Typisierung)

Nur eine paar Zeilen weiter steht, warum es doch Sinn ergibt, wenn der Compiler grade die passende Formelsammlung nicht parat hat.

Abgesehen davon, werden sich die Mathematiker nicht geschlagen fühlen, immerhin müssen sie zur Zeit damit leben, dass alles nur typlose Integer (bzw. Floats) sind.

2am

Wenn ich Code schreibe, möchte ich doch Details der Implementierung möglichst zentral halten und vor dem Aufrufer verbergen:

if (window & WindowFlags::UseFullscreen)  // schlecht

if (window.isFullscreen()) // besser

Damit ist es für den Aufrufer egal, ob die Flags zu einer Basisklasse oder zur Fensterklasse gehören. Er weiss gar nicht, dass es Flags gibt, er sieht nur das Fenster. Ausserdem hat man einen zentralen Einstiegspunkt für Änderungen und Erweiterungen.
Möglicherweise möchte man später die Information "Fullscreen ja/nein" direkt vom Window-Manager abfragen; es kann sein, dass die Abfrage Multithreading-fähig sein muss usw.

Es ist sicher alles auf vielerlei Arten möglich, aber es sollte doch so selbsterklärend, einfach und pragmatisch wie möglich bleiben. Das erspart auch Arbeit bei der Dokumentation.

Mein Lösungsansatz in Sachen Fenster sieht übrigens so aus:
Ich habe seit Jahren zwei Dateien; in der einen ist der Code zum Öffnen eines Win32-Fensters, in der anderen das ganze für X11. Es ist sperrig, es ist hässlich. Ich habe keine Sekunde daran verschwendet, dies in eine OOP-Struktur zu integrieren. Aber der Code ist ausgiebig getestet und x-mal von mir wiederverwendet worden, jedesmal per copy&paste binnen Sekunden. Wenn ihr mit einer Fensterklasse diese Wiederverwendungsrate erreichen wollt, müsst ihr noch verdammt oft vererben und komposi... äh... ihr wisst schon.

Ich sage ausdrücklich nicht, dass das gut oder nachahmenswert sei, aber es bildet doch ein gewisses Argument in der Debatte um Wiederverwendbarkeit und Strukturierung von Code.

Shade Of Mine

Xin schrieb:

Anstatt mich darüber zu ärgern, dass ich das nicht kompilieren kann, habe ich wenigstens ein Ergebnis.

Das ist also die viel gelobte Qualität deiner Software?

Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben

Xin schrieb:

Nur eine paar Zeilen weiter steht, warum es doch Sinn ergibt, wenn der Compiler grade die passende Formelsammlung nicht parat hat.

Man gestattet also unsinnige Operationen weil?

Xin schrieb:

Abgesehen davon, werden sich die Mathematiker nicht geschlagen fühlen, immerhin müssen sie zur Zeit damit leben, dass alles nur typlose Integer (bzw. Floats) sind.

Der Mathematiker wundert sich über Integer / Float nicht, denn die verschiedenen Zahlensysteme sind bis auf einige Ausnahmen, wie die rationalen, komplexen, ..., gut umgesetzt. (Lisp wäre gründlicher aber es reicht auch so)
Nur wenn man schon eine Maßeinheit einführt, dann sollte man diese auch in Berechnungen beachten.
Der Mathematiker wird sich wundern, wenn aus Meter plus Gramm eine natürliche Zahl entsteht.
(Hmmm, eigentlich sind es eher die Physiker)

Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?

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

Methoden mit bool-Parametern und "Lesbarkeit" im Kontext