Designproblem

Was du sagst stimmt einfach nicht. Du hast nicht viel Erfahrung mit C++ und OOP. Das ist nicht böse gemeint aber man hört es dir an. Das ist ja auch keine Schande. Ich sagte, die WinApi kann man aus jeder beliebigen aus nutzen. Perl und Python laufen in einem Interpreter und wenn dieser WinApi-aufrufe unterstützt geht es problemlos. Dein Beitrag hörte sich so als müsse man C benutzen.

Bevor du jetzt argumentierst, dass man sowas trozdem machen (mit Klassen unter der WinApi programmieren), möchte ich dich darauf hinweisen, das das meine persönliche Erfahrung ist

Du hast eben nicht viel Erfahrung. Warum nutzt man WinApi in einem C++ Programm: Weil man ein bisschen Oberfläche haben will und das Programm schlank haben will. Und guter Stil ist es dann Oberfläche und Programmlogik getrennt zu halten. Und warum sollte man dann die Programmlogik nicht mit Klassen gestalten? Noch besser wäre die WinApi-Funnktionalität, die man benötigt zu wrappen.

Wenn man sehr viel mit Oberflächen macht würde man so wieso auf eine gute C++ Gui-Bibliothek zurückgreifen.

finix

flammenvogel schrieb:

Bedenke dabei aber das es Sinn der Klassen ist, das man sie in anderen Programmen wiederverwenden kann. Das scheint mir bei deinen ganzen Klassen nicht der Fall.

Äh, sicher? Hast du das irgendwo gelesen oder sprichst du aus Erfahrung?
Weil das nicht zwangsläufig der Fall ist, eher im Gegenteil: zwar sollten die meisten Klassen Klassen wiederverwenden aber die wenigsten Klassen eignen sich zur Wiederverwendung...

flammenvogel schrieb:

(Warum frage ich: Wenn du mit der WinApi programmierst (wie ich), kann man sich eigentlich das Programmieren mit Klassen auf einen Minmum abgewöhnen, da die WinApi eigentlich für C programmiert ist ...)

Könntest du kurz darlegen wie du auf diese Nicht-Folgerung kommst? Dass in C++ geschriebene Programme uU leichter oder mit weniger Aufwand mittels C++ Bibliotheken als mittels C-Bibliotheken zu erstellen sein können heißt noch lange nicht dass selbige Programme besser/schneller/was-auch-immer in C geschrieben werden können...

flammenvogel schrieb:

(Ich will hier wirklich keinen Flamewar verursachen)

Newbie-Bashing ist auch nicht viel toller SCNR

richie schrieb:

Ob man "mit Klassen" programmiert, ist eine Stil- und Design-Frage. Mein Tipp: wenn C++, dann auch das Klassenkonzept nutzen und nahe am OOP-Paradigma bleiben.

Ach ja? Dir ist klar dass C++ eine Multi-Paradigmensprache ist und dass C++ "OOP-Paradigma"-technisch gesehen nicht unbedingt der Stein der Weisen ist?

@finix:

Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

flammenvogel

Dann frage ich mich allerdings was ich seit Jahren mache. Kann sein das du das so siehst. Aber die WinApi ist nun mal in C geschrieben. Das merkt man vorallem an den C typischen Funktionsaufrufen. Ich habe mehre Projekt. In mehren habe ich die Probleme anfangs versucht mit Klassen zu implementieren, ich habe es in den meisten Fällen wieder rückgängig gemacht, weil man einfach durch den Code nicht durchsteigen konnte. Ein Beispiel für Probleme mit Klassen und WinApi: Versuche mal ein WinApi Programm zu schreiben wo die Fenster in einer Klasse verwaltet werden. Das geht zwar ist aber sehr komplex, da die Klasse static sein muss..., das macht aus meiner Sicht eine Implementierung in einer Klasse sinnlos, da man das Fenster dann halt nur einmal erstellen kann. Ich habe eine Negative Erfahrung mit WinApi und Klassen gemacht, weil man einfach alles wrappen muss. Und ich im Programm dann bei den Funktionsaufrufen einen C-Style habe und einen objektorientierten. Daher neige ich zu WinApi Programmen ohne Klassen. Verstehe es oder las es bleiben, das ist meine Meinung. Wenn du ne Objektorientierte GUI Erstellung haben willst, dann nimm Qt! Au0erdem unterstützten Perl/Python die WinApi nicht (es gibt eventuell C-Module, die die WinApi wrappen). Das hat aber aus meiner Sicht nichts mehr mit der WinApi zutun. Das wäre (für mich) so, als wäre der Benutzer Teil meines Programms, weil er Aktionen mit meinem Programm ausführt. Man muss aus meiner Sicht da unterscheiden. Allerdings ist das alles nichts anderes als eine Subjektive Meinung, wenn du das anders siehst (was natürlich dein gutes Recht ist), dann ist das so. (Das ist mein letzter Beitrag zum Thema weil, der Thread sich nicht mit der objektorientiert Programmierung der WinApi beschäftigt, sondern mit einem anderem Problem und ich diesen Thread nicht weiter zuflooden will...)

Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

Würdest du das oben so machen??? Mir ist das zu kompliziert, da schreibe ich lieber für jede Aufgabe eine Funktion, und packe das alles in ein Programm. Obwohl man sicher auch einige Sachen an dem Problem gut mit Klassen lösen könnte, alles ist aus meiner Sicht übertrieben.

@flammenvogel

Du hast angefangen diesen Thread vom Thema zu entfernen. Du wolltest jemanden, der richtigerweise ein Problem in C++ mit dem Klassenkonzept lösen wollte, mangels Wissen, schlechten Programmier-Stil einreden. Das gehört sich nicht in einem C++ Unterforum.

Du beweisst, dass du C++ und OOP nicht beherrschst. Deswegen meidest du es. Selbstverständlich ist die WinAPI eine in C geschriebene API. Sonst wäre es nicht so einfach möglich sie aus anderen Sprachen zu nutzen (beispielsweise Delphi, Pascal, Assembler ...). Ich sage nicht, dass Perl und Python WinAPI unterstützen. Ich sage nur, dass es problemlos möglich wäre.

Und was meinst du was QT macht? Das was du nicht hinkriegst. Die Windows-API mit C++ wrappen.

Ebenfalls sagte ich dass es guter Stil ist, Programmlogik und Oberfläche zu trennen. Wenn man es schon nicht hinkriegst die WinAPI zu wrappen, dann kann man oder sollte man die Programmlogik in einem C++ entsprechenden Stil lösen, wenn man C++ nutzen will.

finix

@Sir Niko, damit das ganze nicht völlig OT dreht:
Du scheinst dir schon einige Gedanken dazu gemacht zu haben... hast du ein Klassendiagramm? Noch viel wichtiger, eine Art Design-Rationale?

Programmierst du eine Lib für das Spiel die du wiederverwenden möchtest (bis zu einem gewissen Grade eine gute Idee) oder betreibst du komplexe Generalisierung "für den Fall dass, irgendwann, irgendwie, vielleicht" könnte ich das alles ja mal brauchen?

In Sachen Komplexität sind die paar Klassen denke ich nicht allzu schwerwiegend, was mich persönlich allerdings 'stört':

Wenn du (s.o.) kein Lib baust und deine MapLayer keine Abhängigkeiten untereinander haben, brauchst du wirklich eine LayeredMap? Reicht ein 'layered maps' nicht aus?
Wozu brauchst du überhaupt verschiedene Arten von Maps - geht es nur um das "könnte, eventuell"?
Vielleicht wäre es insgesamt nicht schlecht wenn du diesen Gedanken von 'essentiell verschiedenen' ein wenig erläutern könntest!? Welche Arten von Maps neben LayeredMap schweben dir vor, warum können es nicht schlicht verschiedene Tiles(?)/Objekte auf der Map sein?

Was mir allerdings als erstes aufgefallen ist ist dein MapObject, welches du in den Vordergrund rücken zu scheinst.
Ist es nicht eher so dass das Map-Object das Hauptsächliche ist? Dass eine Map, wie du selbst sagst, verschiedene MapObjects haben kann aber nicht umgekehrt? Dass das MapObject eher MapPresentation o.ä.(tm) heißen sollte ("FooObject" ist allerhöchstens für Variablen nicht nichtssagend..)?

Was deine Konsistenzprobleme angeht: wenn es bei der Zusammenstellung um mehr geht als von einem Level/Map-File zu laden solltest du dich evtl. etwas ausführlicher zu deinem Vorhaben äußern...

@finix:
Könntest du bitte dennoch meine Frage beantworten? Es würde mich sehr interessieren:

richie schrieb:

@finix:
Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

Danke!

finix

richie schrieb:

@finix:

Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

Hehe.. sorry.. wollte damit nicht ausdrücken dass du auf OOP verzichten sollst
Nur dass, wie gesagt, C++ nicht das Musterbeispiel bezüglich OOP darstellt und nicht zwangsläufig auf OOP beschränkt ist...
Lies den Post nochmal.

edit: nochmal, ich programmiere selbst Objektorientiert, widerspreche flammenvogel absolut, aber C++ ist eine Multiparadigmensprache.
Aber dogmatisch OOP muss auch nicht sein.

@finix:
Das weiss ich. C++ wollte schon immer abwärtskompatibel zu C bleiben, und schleppt es daher als Untermenge mit sich. Die Standard-Bibliothek ist auch ein gutes Beispiel, dass OOP eher in einem geringen Maße genutzt wird (Kaum Vereerbung). Aber dennoch ist sie bis zu einem gewissen Grad OO. Meine Aussage, die du zitierst hast, ist demgegenüber kein Widerspruch.
Ausserdem betrachte ich OOP nicht unbedingt als ein Sprachenfeature. Hin und wieder muss auch mal plain C benutzen und auch da versuche ich das Problem OO zu lösen.

finix

richie schrieb:

Die Standard-Bibliothek ist auch ein gutes Beispiel, dass OOP eher in einem geringen Maße genutzt wird (Kaum Vereerbung).

Obwohl ich Generics manchmal doch schon sehr vermisse finde ich "die STL" (die du wahrscheinlich meinst) nicht schlecht. Nicht alles muss ein AlgorithmObject o.ä. sein. Nicht alles muss ein Objekt sein. Freie Funktionen sind toll. Und auch Objekte müssen nicht zwangsläufig in einer gigantischen Vererbungshierarchie stecken...

richie schrieb:

Aber dennoch ist sie bis zu einem gewissen Grad OO. Meine Aussage, die du zitierst hast, ist demgegenüber kein Widerspruch.

Wollte ich damit auch nicht ausdrücken. Hatte sich aber angehört wie C++ -> OOP, zwangsläufig

richie schrieb:

Ausserdem betrachte ich OOP nicht unbedingt als ein Sprachenfeature. Hin und wieder muss auch mal plain C benutzen und auch da versuche ich das Problem OO zu lösen.

Wollte ich damit ebenfalls nicht ausdrücken. OOP wird eben mehr oder weniger von einer Sprache unterstützt oder nicht - aber du musst zugeben dass "selbst C++" nicht wirklich der Gral der OOP ist, oder!?

Warum vermüllt ihr hier eigentlich den Thread?! Das hat doch gar nichts mit der Fragestellung zu tun. Wenn das ein Moderator hier ließt sollte er den Thread auf jeden Fall splitten oder die Offtopic-Beiträge löschen.