Öffentliches RPG Projekt
-
Dragon4411 schrieb:
Behersche im gewissenmasse OOE
Nach dem bisherigen aber mit starken Schwächen. Kenntnisse magst du haben, aber dir fehlt eindeutig Erfahrung für komplexeres Design. Das Projekt mag dennoch lehrreich sein, wobei ich zwei Einschränkungen mache:
1. Ich befürchte mangelndes Durchhaltevermögen (die Tendenz ist bereits vorhanden, da du dich noch nicht einmal durch ein Grundlagenbuch wirklich durchgekämpft hast) - dies mag sich aber mit der Zeit bessern, aus meiner Erfahrung ist dies aber in mindestens 90% der Scheiterungsgrund für Anfangsprojekte (und die Abbruchquote von solchen Projekten ist verdammt hoch).
2. Ihr solltet zumindest einen, nennen wir es mal "Mentor" haben (jemand mit Erfahrung, der sich immer mal etwas Zeit für euch nimmt, und regelmäßig eine "Code Review" durchführt), gerade weil das Projekt nicht so simpel ist, wie du vielleicht im ersten Moment meinst.
-
Dragon4411 schrieb:
Hallo Zusammen ich mach mal schnell ein Update, was ich alles gemacht habe udn wieso:
Fragen:
- Du beachtest viele Anmerkungen nicht, die du bereits bekommen hat (u.a. Mischung Groß-/Kleinschreibung...).
- Ist ein Charakter wirklich ein Monster?
- Wenn eine Klasse bereits Monster heißt, warum die Member nochmals mit "Monster" beginnen.
- Grundsätzlich sollte man sehr vorsichtig sein, Member öffentlich zu machen.
- Implementierung gehört in die Sourcedateien.
- Ich würde niemals mehr als eine Variable je Zeile schreiben, alleine schon um ggf. den Datentyp zu ändern ohne die Reihenfolge zwangsweise zu ändern etc.
- Ich würde in der Regel eine Header-/Sourcedatei pro Klasse machen, und nicht mehrere Klassen zusammen in eine Datei einfügen.
- Basisklassen sollten entweder ein nicht-öffentlichen oder virtuellen Destruktor haben.
- "int QuestIDStatus" ist eindeutig ein Kandidat für ein enum
-
Naja, header-only dateien kann er schon machen, wenn er das will.
So schlimm ist das auch nicht.
-
naja aber das hat dann wenig mit OOP zu tun...
-
#error schrieb:
naja aber das hat dann wenig mit OOP zu tun...
Was haben header-only klassen mit OOP zu tun?
-
Scorcher24 schrieb:
#error schrieb:
naja aber das hat dann wenig mit OOP zu tun...
Was haben header-only klassen mit OOP zu tun?
Warum glaubst du das die Frage jetzt in diesem Zusammenhang war. Da kein Zitat eingefügt wurden ist, ist der Zusammenhang unklar.
-
Ich habe mal irgendwo gelesen, dass der Compiler besser optimieren kann wenn er den Quellcode in einem Stück bekommt, also so wie hier beschrieben keine Trennung von Prototypen und Implementierung stattfindet. Was haltet ihr davon?
-
Grasshopper schrieb:
Ich habe mal irgendwo gelesen, dass der Compiler besser optimieren kann wenn er den Quellcode in einem Stück bekommt, also so wie hier beschrieben keine Trennung von Prototypen und Implementierung stattfindet. Was haltet ihr davon?
Ich halte gar nichts davon, da man sich auch mehr Abhängigkeiten macht wenn die Implementierung im Header schreibt. Das mag in einigen Fällen unproblematisch sein, ich schreibe meinen Code aber nicht so, das ich nachdenken muss wann ich die Implementierung zu verschieben habe. Mir ist ein konsequenter Stil wesentlich lieber, da mir dabei auch wesentlich seltener Fehler unterlaufen.
Zudem gehöre ich zu den Anhängern der Ansicht, das Implementierungsdetails (sofern sie durch C++ nicht zwingend in den Header müssen) immer in den Source gehören. Vermeidet auch die Gefahr das man doch irgendwo gegen eine Implementierung statt gegen die Schnittstelle programmiert. Und ich lese von fremden Code in der Regel ausschließlich den Header, dieser stellt die Schnittstelle dar gegen die ich Programmieren muss.
-
Grasshopper schrieb:
Ich habe mal irgendwo gelesen, dass der Compiler besser optimieren kann wenn er den Quellcode in einem Stück bekommt, also so wie hier beschrieben keine Trennung von Prototypen und Implementierung stattfindet. Was haltet ihr davon?
Das kann gut sein. Es ist wohl auch so, dass man ein bisschen schneller fahren kann, wenn man sich ne illegale Nitro-Einspritzung in den Motor bauen lässt. Würdest du deshalb für viel Geld dein Auto umbauen und Bußgelder riskieren, damit du morgens ne halbe Minute schneller im Geschäft bist, während dein Hauptproblem eigentlich der Stau jeden Morgen ist?
Der Compiler kann ggf. schnelleren Code generieren, ja. Wenn das Design und die Algorithmen Grüßtze sind, bringt das trotzdem nicht viel. Oft kann man an anderer Stelle viel mehr Performance rausholen. Und vor allem wird es schnell zum Wartungshorror, wenn man den Code enbloc schreibt. Damit macht man es den Kollegen nur schwieriger, die wirklichen Performancebrecher zu beheben.
-
Fragen:
- Du beachtest viele Anmerkungen nicht, die du bereits bekommen hat (u.a. Mischung Groß-/Kleinschreibung...).
- Ist ein Charakter wirklich ein Monster?
- Wenn eine Klasse bereits Monster heißt, warum die Member nochmals mit "Monster" beginnen.Damti wenn ich später noch weitere Klassen machen die Variablen unterscheiden kann.
- Grundsätzlich sollte man sehr vorsichtig sein, Member öffentlich zu machen.
Dies ist mir bekannt jedoch wäre es mühsam hier alles abzutrennen, nicht?
- Implementierung gehört in die Sourcedateien.
Wird gemacht
- Ich würde niemals mehr als eine Variable je Zeile schreiben, alleine schon um ggf. den Datentyp zu ändern ohne die Reihenfolge zwangsweise zu ändern etc.
Wird ebenfals geändert.
- Ich würde in der Regel eine Header-/Sourcedatei pro Klasse machen, und nicht mehrere Klassen zusammen in eine Datei einfügen.
Sprich auch die anderen "Unterklassen"?
- Basisklassen sollten entweder ein nicht-öffentlichen oder virtuellen Destruktor haben.
Werde ich mri duchlesen, was die Vorteile sind und es heir auflisten damit es die anderen auch sehen.
- "int QuestIDStatus" ist eindeutig ein Kandidat für ein enum
Da Stimme ich zu (nach dem ich nun enum durchgelesen habe).
Gruss & Danke,
Dragon4411
-
Anonymous schrieb:
Ich habe mal irgendwo gelesen, dass der Compiler besser optimieren kann wenn er den Quellcode in einem Stück bekommt, also so wie hier beschrieben keine Trennung von Prototypen und Implementierung stattfindet. Was haltet ihr davon?
Ich halte davon nicht sonderlich viel, weil man dann nicht vernünftig debuggen kann.
-
Ich möchte kurz auf Konstruktoren und Destruktoren zu sprechen kommen.
Ich hoffe ich hab das jetzt richtig verstanden:
Konstruktoren und Destruktoren sind zuständig für erzeugen und die auflösung von Objekten.
Ein Konstruktor kann Werte definieren(Werte können in der Klasse selbst nochmals redefiniert werden).
Ein Destruktor löst das Objekt auf.
Diest ist dem Scope einer Variable sehr ähndlich.
Sobald ein Codeblock verlassen wird, ist die Variable aufgelöst.Hab ich das richtig verstanden?
Gruss,
Dragon4411
-
Ja, nur dass mit den Werten die definiert werden klingt komisch. Ein Wert wird nicht definiert. Im Konstruktor kannst du Variablen initialisieren (über die Initialisierungsliste). Variablen einen Wert zuweisen kannst du im Konstruktor, und in jeder anderen Methode. (Die nicht statisch oder const ist, falls die Membervariable nicht mutable ist.)
-
Dragon4411 schrieb:
Ich hoffe ich hab das jetzt richtig verstanden:
Konstruktoren und Destruktoren sind zuständig für erzeugen und die auflösung von Objekten.
Ich würde es etwas anders formulieren: Der Konstruktor dient dazu ein Objekt mit einem konsistenten Zustand zu initialisieren, der Destruktor dient der Freigabe von Ressourcen (Neben Konstruktor und Destruktor kennt C++ noch mindestens zwei weitere Methoden: Zuweisungsoperator und Kopierkonstruktor, du solltest hier mal nach Regel der Drei bzw. Dreierregel schauen).
Dragon4411 schrieb:
Ein Konstruktor kann Werte definieren(Werte können in der Klasse selbst nochmals redefiniert werden).
Wie von cooky451 schon geschrieben ist definieren hier ein sehr unpassendes Wort (Initialisieren / Zuweisen bzw. Überschreiben).
Dragon4411 schrieb:
Ein Destruktor löst das Objekt auf.
Eher umgekehrt: Ein Destruktor wird aufgerufen wenn ein Objekt zerstört wird.
Dragon4411 schrieb:
Diest ist dem Scope einer Variable sehr ähndlich.
Eine Variable umfasst auch Objekte. Wenn ich eine Klasse A habe ist "A a;" eine Variablendefinition, auch wenn hier ein Objekt einer Klasse gemeint ist. Der unterschied zu den Datentypen wie int ist nur das eine Klasse ein Konstruktor und Destruktor etc. besitzt. Für die Lebenszeit gibt es keine Unterschiede.
-
cooky451 schrieb:
Ja, nur dass mit den Werten die definiert werden klingt komisch. Ein Wert wird nicht definiert. Im Konstruktor kannst du Variablen initialisieren (über die Initialisierungsliste). Variablen einen Wert zuweisen kannst du im Konstruktor, und in jeder anderen Methode. (Die nicht statisch oder const ist, falls die Membervariable nicht mutable ist.)
Danke schön
Und was ist wenn ich den jetzt virtual mache?
Gruss,
Dragon4411
-
asc schrieb:
Eine Variable umfasst auch Objekte. Wenn ich eine Klasse A habe ist "A a;" eine Variablendefinition, auch wenn hier ein Objekt einer Klasse gemeint ist.
In C++ versteht man unter Objekt alles, was irgendwie Speicher belegt. Darum macht es Sinn, bei Objekten einer Klasse von Instanzen zu sprechen, dann weiß jeder gleich, dass ein Objekt einer Klasse gemeint ist.
-
Dragon4411 schrieb:
Und was ist wenn ich den jetzt virtual mache?
Konstruktoren können nicht virtual sein. (Würde ja auch wenig Sinn machen.)
-
asc schrieb:
Dragon4411 schrieb:
Ich hoffe ich hab das jetzt richtig verstanden:
Konstruktoren und Destruktoren sind zuständig für erzeugen und die auflösung von Objekten.
Ich würde es etwas anders formulieren: Der Konstruktor dient dazu ein Objekt mit einem konsistenten Zustand zu initialisieren, der Destruktor dient der Freigabe von Ressourcen (Neben Konstruktor und Destruktor kennt C++ noch mindestens zwei weitere Methoden: Zuweisungsoperator und Kopierkonstruktor, du solltest hier mal nach Regel der Drei bzw. Dreierregel schauen).
Dragon4411 schrieb:
Ein Konstruktor kann Werte definieren(Werte können in der Klasse selbst nochmals redefiniert werden).
Wie von cooky451 schon geschrieben ist definieren hier ein sehr unpassendes Wort (Initialisieren / Zuweisen bzw. Überschreiben).
Dragon4411 schrieb:
Ein Destruktor löst das Objekt auf.
Eher umgekehrt: Ein Destruktor wird aufgerufen wenn ein Objekt zerstört wird.
Dragon4411 schrieb:
Diest ist dem Scope einer Variable sehr ähndlich.
Eine Variable umfasst auch Objekte. Wenn ich eine Klasse A habe ist "A a;" eine Variablendefinition, auch wenn hier ein Objekt einer Klasse gemeint ist. Der unterschied zu den Datentypen wie int ist nur das eine Klasse ein Konstruktor und Destruktor etc. besitzt. Für die Lebenszeit gibt es keine Unterschiede.
Danke für deinen Post.
Das mit der Variable und dem Objekt wusste ich nicht, die 3er Regel werde ich mri sogleich anschauen.
-
cooky451 schrieb:
Dragon4411 schrieb:
Und was ist wenn ich den jetzt virtual mache?
Konstruktoren können nicht virtual sein. (Würde ja auch wenig Sinn machen.)
Hmmm, das verwirrt mich jetzt, destruktoren kann man aber virtual machen oder?
-
Dragon4411 schrieb:
Hmmm, das verwirrt mich jetzt, destruktoren kann man aber virtual machen oder?
Sicher, das macht ja auch Sinn.
Warum macht ein virtueller Konstruktor keinen Sinn? Ganz einfach, wenn du eine Instanz einer Klasse erstellst, sollte dir der genaue Typ ja bekannt sein. Aber wenn du sie wieder aufräumst, ist eventuell nur der statische Typ bekannt. (Nicht der dynamische.)