Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
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.Also auf jeden Fall immer, wenn du etwas dynamisch anlegen musst. Z.B. eine variable Mapgröße.
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.Für Arrays benutze ich im Grunde immer Pointer.
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.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.
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.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?
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.Also auf jeden Fall immer, wenn du etwas dynamisch anlegen musst. Z.B. eine variable Mapgröße.
Variable Kartengrösse ist ein schönes Beispiel für einen Fall, wo man new und delete weder verwenden muss noch sollte.
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.Für Arrays benutze ich im Grunde immer Pointer.
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.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.
Container verwenden. Zum Beispiel verschachtelte STL-Container oder Boost.MultiArray.Und wie sollte man es dann machen? Batzer hat hier nicht explizit nach manueller Speicherverwaltung gefragt.
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?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).
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.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.
C-/C++-Quelltext |
|
1 2 3 4 5 6 |
struct LoadedTexture { unsigned int refCounter; IDirect3DTexture9* texture, std::string filename; }; |
C-/C++-Quelltext |
|
1 |
std::list<LoadedTexture> textureList; |
C-/C++-Quelltext |
|
1 |
std::list<LoadedTexture*> textureList; |
Werbeanzeige