spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ob du this->width oder width nutzt, ist dir überlassen, es ist das Gleiche, außer du hast eine lokale Variable mit demselben Namen, die den Member somit überdeckt. Ich lasse das this-> aus Übersichtsgründen weg.
Globale Variablen sind nahezu immer Mist, gewöhn' dir das also gar nicht erst an. Außnahmen können z.B. globale Logger-Objekte sein. Soll allerdings ein Objekt Zugriff auf ein anderes haben können, gib ihm einfach eine Referenz oder Zeiger darauf.
Gcc (=GNU Compiler Collection) kann abhängig von der Art des angegebenen Sources, an der Dateiendung, erkennen, mit welchem Kompiler es kompiliert werden soll. G++ tut das nicht, es kompiliert einfach den Quelltext mit dem C++-Compiler. Wahrscheinlich hast du den Code mit dem C-Kompiler kompilieren lassen.
Um für verschiedene Plattformen zu kompilieren, kannst du entweder direkt auf der Zielplatform kompilieren oder auf einer anderen für diese, z.B. wenn du für Microcontroller programmierst. Das Gcc-Toolchain gibt es für verschiedene Plattform, z.B. für Windows und Linux, und können auch Crossplattform kompilieren. Es gibt natürlich auch andere Compiler, wie der von Microsoft innerhalb von VisualStudio.
Voraussetzung ist natürlich, dass der Quellcode, d.h. auch alle verwendeten Bibliotheken, eben auch Plattformunabhängig sind oder für mehrere Plattformen die gleiche Schnittstelle anbietet. SDL tut das zum Beispiel, egal wie der Betriebssystemspezifische Code aussehen muss, du kannst immer mit denselben Funktionen arbeiten.

Hier noch ein paar grundlegende Infos für C++:
- DU musst immer damit rechnen, dass aufgerufene Funktionen Ausnahmen werfen, außer sie sind als noexcept gekennzeichnet. Das bedeutet, dass Code nach dem Motto "ich hole mir nen Renderer/Fenster/dynamisches-Objekt-mit-new und gebe das dann mit einer entsprechenden Funktionen dann manuel wieder frei" sehr fehleranfällig ist. Zwischen ersterem und dem l‎etz‎erem kann ja schließlich ne Exception geworfen werden. Darum erfand man im Zusammenhang mit C++ das RAII. Das heißt nichts anderes, dass eine Klasse eine Ressource verwaltet, z.B. indem sie diese im Konstruktor acquiriert (und nicht in einer hässlichen init-Methode) und diese dann im Destruktor freigibt (und nicht in einer äußerst fehlerbehafteten close-Methode). Ressourcen sind alles mögliche, die du wieder manuell zerstören lassen musst. Der Destruktor wird immer aufgerufen, egal ob die Funktionen, in der das Objekt lokal liegt, durch eine Ausnahme oder ganz normal verlassen wird, oder ob es innerhalb eines anderen Objekts liegt. Hier wird das näher erläutert. Für SDL kannst du dir einfach solch eine Wrapperklasse bauen: Link.
Statt new und delete verwendest du ebenso Smartpointer, sodass du am Ende überhaupt kein new und delete mehr stehen hast. In diesem Zusammenhang wirst du auch denn Sinn hinter der Movesemantik von C++ verstehen müssen: Link.
(Damit hier keine Missverständnisse entstehen: Das Smartpointerobjekt, in den meisten Fällen std::unique_ptr gibt die Ressource automatisch frei, d.h. es ist dessen Besitzer. ein std::unique_ptr kann nicht kopiert werden, sonst besäßen zwei von ihnen dieselbe Ressource. Dass es der Besitzer ist heißt aber nicht, dass andere Objekte und Funktionen mittels Zeiger oder Referenzen diese Ressource referenzieren können. Es muss nur sichergestellt werden, dass diese 'Observer' nach Zerstörung des Besitzers die Ressource nicht mehr referenzieren. Es gibt also oft keinen Grund, std::shared_ptr zu benutzen.)

- Ziehe Zeigern Referenzen vor, denn Zeiger signalisieren, dass sie auch null sein können und somit z.B. üblicherweise signalisieren, dass ein Argument auch 'optional' sein kann. Im Falle, dass du einen Nullzeiger nutzen möchtest, verwende nullptr statt dem hässlichen NULL.

Gute Fragen! Ich probiere mich mal an einer Antwort. Erstmal die Fragen selbst, Allgemeines kommt nachher.

Zitat von »BlackScorp«

Dabei ist mir folgendes aufgefallen https://github.com/BlackScorp/DwarfForge…es/Rect.cpp#L37 ich habe hier die Eigenschaft "width" ich kann den Wert via this->width setzen und auch einfach with nutzen, Beides wird normal kompiliert ohne Probleme. Was ist "Best Pratice" ? Was sollte man nutzen? Was nicht?

width ist wie alle anderen Member der Klasse private deklariert. Das bedeutet, Du kannst nur aus Methoden der Klasse selbst darauf zugreifen, sonst haut Dir der Compiler auf die Finger. Du kannst also ganz banal direkt width im Code benutzen, weil für alle Programmierer und den Compiler klar ist, was gemeint ist. Das ist idiomatischer C++-Code, keine Sorge.

Manche Leute haben die Konvention, alle Membervars nur mit this-> zu benutzen, um klarzumachen, dass es Membervars sind. Ich finde das häßlich, aber es ist Geschmacksfrage. In den meisten Firmen, die ich bisher von Innen gesehen habe, und bei mir privat, ist es stattdessen üblich, CamelCase zu benutzen und ein 'm' vorzustellen. Also mWidth oder manchmal auch (überflüssigerweise) m_Width. Andere bevorzugen die amerikanische Konvention des m_multiple_lower_case_words, weil es Englische Muttersprachler nunmal nicht so sehr haben mit der Groß-/Kleinschreibung wie die Deutschen. Die C++-Standardlib ist so geschrieben. Ist egal, was Du nimmst. Suche Dir eine Konvention aus, und bleibt konsistent. Und wenn Du irgendwann in ner Firma arbeitest, bist Du zumeist eh verpflichtet, den vorgeschriebenen Codestyle zu benutzen.

Nur, um's nochmal klarzustellen: syntaktisch ist das alles gleich. Es geht hier nur um die Menschen, die den Code lesen, verstehen und ändern sollen. Dem Compiler ist das alles egal.

Zitat

Außerdem habe ich in den C++ Tutorials was merkwürdiges gesehen, ständig wurden im Globalen Raum instanzen erstellt mit Pointern und irgendwo im Code wurde dann dieser Pointer angefasst. In PHP ist es zwar möglich, jedoch sollte man es vermeiden Globale Instanzen/Variablen etc zu nutzen, weil man nie direkt weiß welcher Teil des Codes die Variable verändert, debugging ist dann nicht mehr so schön. Sind die Tutorials einfach nur zu alt? Oder wurde es einfach nur aus Bequemlichkeit gemacht?

Globale Variablen sind allgemein nicht so schön. Es ist globaler State, der unsichtbar von Seiteneffekten beliebiger Funktionen verändert werden kann. Man kann ihn auch nicht durch einen Mock ersetzen, wenn man einen Unittest für die Klasse schreiben will. Man kriegt bei paralleler Programmierung beliebige Synchronisationskonflikte. Der nahezu einzige Grund, warum man globale Variablen einsetzt, ist Bequemlichkeit. Und da verstehe ich, dass Tutorialschreiber manchmal welche benutzen, weil sie etwas ganz Anderes behandeln wollen und der Rest des Codes nur mit minimalem Aufwand zum Punkt kommen soll. Leider gibt es auch ne Menge Tutorialschreiber, die es einfach nicht besser wissen.

Das gilt übrigens auch alles für die "Ich arbeite doch Objektorientiert!"-Variante der globalen Variable, der sogenannte Singleton.

Zitat

Mein Spiel möchte ich später für mehrere Plattformen testweise kompilieren, ich nutze aktuell g++, ich hab mal versucht es mit gcc zu kompilieren, bekam aber eine menge an Fehlern und hab da auch nicht weiter recherschiert. Ist g++ eine Schlechte wahl um für andere Systeme das Programm zu kompilieren? Oder habe ich einfach zu viel komisches benutzt womit gcc nicht klar kommt? std::string zum Beispiel?

std::string ist so dermaßen Standard, das gibt's überall. Bookmarke Dir http://www.cplusplus.com oder http://en.cppreference.com/ oder gewöhne Dir an, jeden beliebigen Mist zu googeln. Das mag am Anfang etwas überwältigend aussehen, aber man lernt, Doku zu lesen und profitiert auf Dauer enorm davon.

Erklärungsversuch: gcc ist C, nicht C++. C ist so ne Art portierbarer Assembler, der aus nur wenigen Bruchstücken von C++ besteht. Bzw. andersrum: C war 20 Jahre lang da, bevor jemand C++ darauf aufgebaut hat. Manche Systeme linken gcc auf g++ und der Compiler entscheidet dann anhand der Dateiendung der Quelltextdatei, welche Sprache er kompiliert, aber manchmal hat man noch die strikte Trennung, dass der gcc nur C kompiliert und der g++ nur C++.

Ansonsten gilt: heutzutage sind die meisten C++-Compiler ziemlich verlässlich, komisches Verhalten begegnet Dir nur in absurden Grenzfällen oder wenn Du aus Versehen eine Helferfunktion der Entwicklungsumgebung benutzt. Also zum Beispiel die MFC auf Windows, oder die POSIX-Funktionen auf Linux. Wenn's in den oben verlinkten Seiten nicht auftaucht, ist es kein C++. Dann brauchst Du eine Bibliothek oder programmierst es selbst, auf jedem Betriebssystem mit den jeweils vorhandenen Bordmitteln.

Und jetzt ein paar allgemeine Anmerkungen, ohne Anspruch auf Vollständigkeit:

- Gewöhne Dir ein paar Konventionen an. Java-Style ist ok, also Klassen und Typen im CamelCase, Klammern auf der selben Zeile, Whitespace und sowas. Fang nicht mit ungarischer Notation an, auch wenn Dir speziell auf den Microsoft-Helferseiten gelegentlich noch sowas begegnet - Hungarian Notation ist sowas von 2002.
- Der Compiler macht eine Menge für Dich. Z.B. den Destruktor erzeugen, oder den Kopierkonstruktor, usw. Wenn Du wie in Rect.cpp den Destruktor nur leer implementierst, kannst Du ihn auch weglassen und damit den compilergenerierten benutzen. Wenn Du einen Kopierkonstruktor oder -operator implementierst, indem Du jedes Element per '=' zuweist, kannst Du den compilergenerierten nehmen. Der beste Code ist nicht geschriebener Code, weil er keinen Pflegeaufwand braucht.
- Ableitungen mögen gerade das Mittel Deiner Wahl sein, aber haben auch ihre Schattenseiten. Man kann in modernem C++ erstaunlich viel erschlagen, indem man ganz schlichte Nur-Daten-Strukturen baut. Ableitungen benutzt Du nur, wenn Du viele verschiedene Dinge hast, die alle an ein- und demselben Griff zappeln sollen.
- Wenn Du irgendwo im Code new oder gar new[] stehen hast, denk nochmal drüber nach. Normales new / delete ist mit unique_ptr und manchmal shared_ptr größtenteils ein Relikt der Vergangenheit. Und new[] ist einfach nur ein Bug. Es gibt quasi keinen Grund mehr, stattdessen nicht einfach einen vorallokierten std::vector zu nehmen und alle Vorteile davon (Leck-Sicherheit, Ausnahmensicherheit) geschenkt zu bekommen.
- Du kannst sehr viel Zeug lokal anlegen, anstatt es auf dem Heap anzulegen und einen Zeiger zu speichern. Ein Beispiel wäre z.B. der EntityManager in der MainScene. Anstatt eines Zeigers einfach direkt das Objekt als Member der Klasse MainScene anlegen. Jede new kostet Rechenzeit - Du kriegst immernoch mehrere Millionen davon pro Sekunde durch, aber es kostet doch deutlich mehr als Du vielleicht aus Garbage Collected-Sprachen gewohnt bist. Und es ist in modernem C++ erstaunlich oft überflüssig.
- Eine std::map<> allokiert für jeden einzelnen Eintrag. Also ein new / delete pro Eintrag. Aus dem Grund würde ich alle Entities erstmal nur in einen std::vector packen. Und erst, wenn Du das erste Mal tatsächlich eine Entity per StringId finden willst, legst Du eine std::map<> daneben, die die benamten Entities anhand ihrer ID speichert.

Viel Spaß!

NULL ist hässlich, weil es was Eigendefiniertes ist. C++ kennt 'nullptr' stattdessen. Dem "ziehe Pointer vor" muss ich widersprechen. Es gibt dafür eine einfache Daumenregel: Wenn das übergebene Objekt immer einen gültigen Wert haben muss, verlange eine Referenz. Wenn es aber optional ist und damit auch nullptr sein darf, muss es ein Pointer sein.

Zitat von »BlueCobold«

NULL ist hässlich, weil es was Eigendefiniertes ist. C++ kennt 'nullptr' stattdessen. Dem "ziehe Pointer vor" muss ich widersprechen. Es gibt dafür eine einfache Daumenregel: Wenn das übergebene Objekt immer einen gültigen Wert haben muss, verlange eine Referenz. Wenn es aber optional ist und damit auch nullptr sein darf, muss es ein Pointer sein.

Beziehst du dich auf mich? Genau das meinte ich nämlich.

Kam leider nicht so klar verständlich an, klang mehr wie: "Pointer is besser, weil's auch nullptr sein darf", was ja aber manchmal ein grober Nachteil wäre. Nun ist es ja geklärt.

Ein weiterer Unterschied zwischen Referenzen und Zeigern, den man noch nennen sollte, ist, dass man sie nur einmal setzen kann bzw. muss und man sie danach nicht mehr auf ein anderes Objekt "zeigen" lassen kann.