spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

• Größere Objekte sollten als Pointer/Referenz übergeben werden, falls nicht aus irgendeinem Grund tatsächlich eine Kopie gebraucht wird.
  Z.B. hast du ganz oft in deinem Code
  

  	C-/C++-Quelltext
  1	const string filename

  anstatt

  	C-/C++-Quelltext
  1	const string& filename

  
  Sowas hast du u.A. in Button, CMenu, CSoundwork, CSprite und CTournament (kann auch sein, dass ich welche übersehen habe):
  
  In Fight::Init übergibst du Player und Enemy ebenfalls nicht als Pointer/Referenz.
  

  	C-/C++-Quelltext
  1	void Init(CMonster Player, CMonster Enemy, CSprite *pBackground, int FoodReward);

  
  Habe es jetzt nicht weiter verfolgt, ob du da absichtlich eine Kopie brauchst, aber auf den ersten Blick sieht es falsch aus.
  
  Gleiches gilt auch für Return Werte. In der Button Klasse hast du z.B.
  

  	C-/C++-Quelltext
  1	SDL_Rect GetRect()

  anstatt

  	C-/C++-Quelltext
  1	const SDL_Rect& GetRect() const

  .
  
  
• Objekte sollten, soweit möglich, auf dem Stack leben.
  

  	C-/C++-Quelltext
  1 2 3 4 5	CButton::CButton() { m_pSpriteButtonActive = new CSprite; m_pSpriteButtonPassive = new CSprite; }

  
  Sowas macht man in Java, C#, ..., aber nicht in C/C++.
  Noch schlimmer ist es, dass die mit new angelegten Objekte oft auch nicht wieder freigegeben werden.
  
  Gefunden habe ich sowas u.A. in Button, Fight, Game, MonsterInventory und CSettings
  
  
• Implementierungen gehören in den Source file, nicht in den Header.
  Das kam z.B. in Button.hpp und MainFunctions.hpp vor.
  
  
• Methoden, die das Objekt nicht verändern sollten const sein, z.B. in Button:
  

  	C-/C++-Quelltext
  1	SDL_Rect GetRect()

  sollte

  	C-/C++-Quelltext
  1	SDL_Rect GetRect() const

  sein.
  
  
• In Main.cpp:
  

  	C-/C++-Quelltext
  1 2 3 4 5 6	if (g_pFramework->Init(800, 600, 16, false) == false) return (0); // Soundwork initialisieren if (g_pSoundwork->Init(44100, AUDIO_S16SYS, 2, 4096) == false) return (0);

  
  Es wäre hier sinnvoll 1 oder zumindest etwas anderes als 0 als Error code zurückzugeben.
  
  
• Initialisierungslisten verwenden z.B. (Code gekürzt):
  

  	C-/C++-Quelltext
  1 2 3 4 5	CSprite::CSprite() { m_pImage = NULL; m_pTexture = NULL; }

  sollte

  	C-/C++-Quelltext
  1 2	CSprite::CSprite() : m_pImage(NULL), m_pTexture(NULL) {}

  sein.
  Grund dafür ist, dass der Compiler für alle Variablen, die nicht in der Initialisierungsliste vorkommen, den Standard Konstruktor aufruft. Indem man gleich die richtige Werte angibt, kann man verhindern, dass die Variablen erst mit unsinnigend Standardwerten gefüllt werden.
  Für builtin types, wie int, short, ... dürfte es allerdings keinen großen Unterschied machen, da sie afaik keinen Standardwert bekommen, sondern dann einfach einen undefinierten Wert haben.
  

Zitat von »TalvinEx«

Sry, dass ich so blöd frage, aber was bringt es eine Funktion const zu machen? Also wo du hinter die Funktionsdeklaration einfach const geschrieben hast? Hab das nämlich noch nie gesehen

	C-/C++-Quelltext
1 2 3 4 5 6 7 8 9 10	class A { public: int returnTruth() { return 42; } }; bool checkTruth(const A& a) { return a.returnTruth() == 42; // Fehler, da a const ist, aber returnTruth nicht. }

Zitat von »TalvinEx«

Und String gilt tatsächlich als größeres Objekt? Also sollte man quasi alles außer den Standard-Datentypen per Referenz oder Zeiger übergeben?

Zitat von »TalvinEx«

Objekte sollten soweit möglich auf dem Stack leben bedeutet, dass ich die Sprites nicht als Zeiger erzeuge [...] ist das richtig?

Zitat von »TalvinEx«

Also was genau ist daran jetzt verkehrt, weil ich gerade versucht bin das einfach so zu lassen, denn es funktioniert ja scheinbar nicht so wie ich es oben beschrieben habe

Zitat von »TalvinEx«

Zitat von »Techel«

Wurde schon erwähnt, Konstruktoren diesen Init-Methoden und nullptr NULL vorzuziehen?

Nein, danke
Warum ist das so (vor allem nullptr, wegen init muss ich nochmal gucken)?