spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Durch Raw Input hat man einfach viel mehr Möglichkeiten. Man kann selbst bestimmen welche Hardware verwendet werden soll, man bekommt mehr Informationen über die Hardware, die Eingabedaten kommen direkt von der Hardware, man kann alle möglichen anderen Eingabegeräte verwenden, usw.

Für z.B. Editoren wirst du mehrere Render Fenster brauchen oder halt ähnliche Anwendungen. Es ist aber nicht immer gut alles zu beschränken, nur weil man Probleme damit hat es umzusetzen. Je beständiger du bist, desto mehr lernst du auch.

Also auf jeden Fall immer, wenn du etwas dynamisch anlegen musst. Z.B. eine variable Mapgröße. Bei einfachen Variablen wie z.B. einem char macht es natürlich keinen Sinn, da kann man auch gleich eine normale Variable benutzen. Für Arrays benutze ich im Grunde immer Pointer. Es kommt halt immer drauf an. Willst du keine Arrays benutzen, sondern nur einfache Klassen Instanzen oder ähnliches, brauchst du von diesen natürlich auch keinen Pointer erstellen. Nur wenn du eine Klasse hast, die mit dem Konstruktor initialisiert werden muss, macht es Sinn von diesem einen Pointer zu erstellen, wenn sich diese Instanz in einer anderen Klassendeklaration befindet. Am Besten ist du probierst einfach aus, was wo am Besten geeignet ist, das kommt mit der Zeit von alleine, weil man recht schnell merkt, wo etwas Sinn macht und wo nicht.

Zitat von »-insane-«

Also auf jeden Fall immer, wenn du etwas dynamisch anlegen musst. Z.B. eine variable Mapgröße.

Nein, nein. Es gibt sehr wenige Fälle, in denen manuelle Speicherverwaltung tatsächlich gerechtfertigt ist. Wenn, dann sollte sie lokal gekapselt sein. Aber im Anwendercode hat sie im Allgemeinen nichts verloren.

Variable Kartengrösse ist ein schönes Beispiel für einen Fall, wo man new und delete weder verwenden muss noch sollte.

Zitat von »-insane-«

Für Arrays benutze ich im Grunde immer Pointer.

Sowas mache ich zum Beispiel nie. Und zwar einfach, weil dieses Vorgehen sehr viele Fehlerquellen und Risiken birgt, ohne dass es irgendwelche relevanten Vorteile hätte. Für Arrays kann man Containerklassen verwenden (STL und Boost). Für einzelne Objekte gibt es Smart-Pointer mit den unterschiedlichsten Besitz-Semantiken. Sehr oft ist es ohnehin sinnvoll, direkt den Wert statt einer Indirektion über Zeiger zu haben.

Zitat von »-insane-«

Am Besten ist du probierst einfach aus, was wo am Besten geeignet ist, das kommt mit der Zeit von alleine, weil man recht schnell merkt, wo etwas Sinn macht und wo nicht.

Diesen Eindruck habe ich nicht. Meistens werden einem solche Dinge erst bewusst, wenn man sich ausführlich mit der Thematik beschäftigt und Bücher wie Exceptional C++ liest. Viele C++-Programmierer setzen new und delete nach wie vor leichtsinnig ein. Deswegen gibt es z.B. immer noch etliche Leute mit der Ansicht, in C++ hätte man mit Memory Leaks zu kämpfen, was aber faktisch nicht stimmt.

C++ bietet dem Programmierer mit RAII eine sehr elegante Möglichkeit, den Schwierigkeiten der manuellen Speicherverwaltung Herr zu werden. Es braucht schon gute Gründe, um darauf zu verzichten und sich freiwillig den Problemen aus C zu stellen.

Zitat von ».:!Batzer!:.«

Also die Frage ist: Wann sollte man Speicher wärend der Runtime reservieren und wann nicht?
Also wann new/delete und wann einfach so/RAII?

Benutze manuelle Speicherverwaltung (new, new[], delete, delete[]) so wenig wie möglich. Überlege dir jedes Mal, bevor du ungeschützten Speicher anforderst, warum dieses Vorgehen gerechtfertigt (d.h. besser als die Alternativen) ist. Wenn du dir irgendwo nicht sicher bist, frage ohne zu zögern wieder nach.

Du solltest dich auf jeden Fall in moderne Speicherverwaltung einlesen. Aus dem C++-Forum gibt es beispielsweise zwei nützliche Artikel:
STL-Container
Boosts Smart-Pointer
Und etwas Literatur wie Effective C++ oder Exceptional C++ schadet grundsätzlich nie.

Zitat von »Nexus«

Zitat von »-insane-«

Also auf jeden Fall immer, wenn du etwas dynamisch anlegen musst. Z.B. eine variable Mapgröße.

Nein, nein. Es gibt sehr wenige Fälle, in denen manuelle Speicherverwaltung tatsächlich gerechtfertigt ist. Wenn, dann sollte sie lokal gekapselt sein. Aber im Anwendercode hat sie im Allgemeinen nichts verloren.

Variable Kartengrösse ist ein schönes Beispiel für einen Fall, wo man new und delete weder verwenden muss noch sollte.

Und wie sollte man es dann machen? Batzer hat hier nicht explizit nach manueller Speicherverwaltung gefragt.

Zitat von »Nexus«

Zitat von »-insane-«

Für Arrays benutze ich im Grunde immer Pointer.

Sowas mache ich zum Beispiel nie. Und zwar einfach, weil dieses Vorgehen sehr viele Fehlerquellen und Risiken birgt, ohne dass es irgendwelche relevanten Vorteile hätte. Für Arrays kann man Containerklassen verwenden (STL und Boost). Für einzelne Objekte gibt es Smart-Pointer mit den unterschiedlichsten Besitz-Semantiken. Sehr oft ist es ohnehin sinnvoll, direkt den Wert statt einer Indirektion über Zeiger zu haben.

Das "im Grunde" sollte betont sein, denn ich verwende auch die Boost Library. Aber innerhalb der z.B. shared_ptr oder der shared_array Klasse sind Pointer gespeichert, die genauso verwendet werden, als wenn man es selber mit new und delete machen würde. Es bietet halt nur die Sicherheit, dass man nicht vergessen kann delete aufzurufen (+einige weitere kleine Features, versteht sich).

Zitat von »Nexus«

Zitat von »-insane-«

Am Besten ist du probierst einfach aus, was wo am Besten geeignet ist, das kommt mit der Zeit von alleine, weil man recht schnell merkt, wo etwas Sinn macht und wo nicht.

Diesen Eindruck habe ich nicht. Meistens werden einem solche Dinge erst bewusst, wenn man sich ausführlich mit der Thematik beschäftigt und Bücher wie Exceptional C++ liest. Viele C++-Programmierer setzen new und delete nach wie vor leichtsinnig ein. Deswegen gibt es z.B. immer noch etliche Leute mit der Ansicht, in C++ hätte man mit Memory Leaks zu kämpfen, was aber faktisch nicht stimmt.

Also bei mir kam es von alleine, da ich versucht habe es möglichst zu vermeiden, als ich noch nicht wusste, wann man z.B. delete und wann delete[] aufrufen muss. Dadurch habe ich mir immer die Frage gestellt, ob eine Speicherreservierung Sinn macht oder nicht. Nach ein wenig probieren, habe ich dann schnell gemerkt, was geht und was nicht und was Sinn macht oder auch nicht.

Zitat von »-insane-«

Und wie sollte man es dann machen? Batzer hat hier nicht explizit nach manueller Speicherverwaltung gefragt.

Container verwenden. Zum Beispiel verschachtelte STL-Container oder Boost.MultiArray.

Zitat von »-insane-«

Das "im Grunde" sollte betont sein, denn ich verwende auch die Boost Library. Aber innerhalb der z.B. shared_ptr oder der shared_array Klasse sind Pointer gespeichert, die genauso verwendet werden, als wenn man es selber mit new und delete machen würde. Es bietet halt nur die Sicherheit, dass man nicht vergessen kann delete aufzurufen (+einige weitere kleine Features, versteht sich).

Ja natürlich, aber genau diese Abstraktion ist der grosse Fortschritt. Du musst dich nicht mehr um Handlangerjobs wie Speicherfreigabe kümmern, sondern kannst dich wichtigen Aufgaben widmen. Was spricht denn dagegen, auf einer höheren Abstraktionsebene zu programmieren und von den daraus entstehenden Vorteilen zu profitieren?

Zitat von »-insane-«

Also bei mir kam es von alleine, da ich versucht habe es möglichst zu vermeiden, als ich noch nicht wusste, wann man z.B. delete und wann delete[] aufrufen muss. Dadurch habe ich mir immer die Frage gestellt, ob eine Speicherreservierung Sinn macht oder nicht. Nach ein wenig probieren, habe ich dann schnell gemerkt, was geht und was nicht und was Sinn macht oder auch nicht.

Bitte nicht falsch verstehen, aber mir scheint, du hättest da auch noch ein wenig Nachholbedarf. Vielleicht hat manuelle Speicherverwaltung bei dir bisher immer irgendwie funktioniert, oder du hast das Potential der Alternativen noch nie voll ausschöpfen können.

Tatsache ist, dass manuelle Speicherverwaltung in vielen Fällen ausschliesslich Nachteile mit sich bringt, für welche C++ eigentlich eine schlagfertige Antwort bereit hätte. Es ist im Übrigen nicht so, dass ich nie manuell Speicher verwalte. Aber wenn ich es tue, kapsle ich es so gut wie möglich und sorge dafür, dass der Anwendercode möglichst frei davon bleibt.