spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Nein, es gibt keinen portablen Weg um auf diese Information zuzugreifen.

Naja, es gibt schon einen. Man braucht nur die new[] und delete[] Operatoren ueberladen und dann entsprechend implementieren.

Zitat von »buggypixels«

Und dann immer wieder das Anpreisen von smart_prt und diesen Dingen. Ehrlich. Ich bin noch nicht so alt, als das ich mir nicht merken kann wo ich denn ein new mache und dann noch
eine delete machen muß. All dieser shared_ unique_ smart_ptr Kram ist doch albern aus meiner Sicht.

Dann benutzt du wohl keine Exceptions.
Warum etwas ablehnen, das dir eigentlich nur Vorteile bringt?
Es scheint, als hättest du dich mit der Thematik nur sehr oberflächlich befasst.

Er benutzt vermutlich wirklich keine Exceptions, sondern return-Codes Fraglich wie er das dann bei Konstruktoren genau macht. Vielleicht mit Init-Methoden.

Zitat von »TGGC«

Zitat von »dot«

Nein, es gibt keinen portablen Weg um auf diese Information zuzugreifen.

Naja, es gibt schon einen. Man braucht nur die new[] und delete[] Operatoren ueberladen und dann entsprechend implementieren.

Stimmt, das wäre in der Tat eine Möglichkeit...

Also ich habe mich schon ausführlich mit dem Thema beschäftigt. Auch ich habe die Bücher von Scott Meyers und Alexandrescu gelesen.
Aber ich halte es halt für überflüssig.
Die Antworten von BlueCobold überspringe ich immer direkt. Da macht man mal eine Ausnahme und schon bereut man es.

Witzig das Blue immer als das Böse angesehen wird, obwohl er meistens sachlich bleibt und auch noch Recht hat.
Das ablehnen von smart_ptr und containern geht in die Richtung: "ich habe zwar keine Ahnung warum ich sie nicht nutzen will, aber irgendwer muss ja schlauer sein als der ganze Rest".

Also der unique_ptr hat einen Overhead von praktisch oder sogar gleich null? Also gegen den spricht nun wirklich nichts (ausser geteilte Besitzverhältnisse).

Ja, std::unique_ptr isst bei ein zeitgemäßen Compiler absolut ohne Overhead. Die Klasse enthält im Prinzip einfach bloß den Zeiger und löscht ihn im Destruktor. Das selbe was man auch selbst machen würde. Also kein Overhead.

Geteilte Besitzverhältnisse sind sehr selten und auch kein Grund dagegen. In dem Fall muss man zwar std::shared_ptr verwenden, aber Raw Pointer sind doch noch weiter vom Nutzungsmuster entfernt. Für Raw Pointer die ein Objekt besitzen gibt es eigentlich keinen Grund.

Zitat von »birdfreeyahoo«

Also ich habe so mitbekommen, dass vector die beliebteste Datenstruktur der STL für 1-dimensionale Container ist. Hat das einen Grund warum z.B. nicht list oder deque bevorzugt wird?

BlueCobold hat schon die theoretischen Aspekte beleuchtet. In der Praxis sieht es auch so aus, dass es nie oder extrem selten vorkommt, dass man die Eigenschaften benötigt, bei denen die std::list oder std::deque glänzt. Selbst bei der Worst Case Verwendung der std::list überholt sie den std::vector erst bei einigen tausenden durchschnittlichen Elementen. Das kommt von dem hohen Overhead durch die vielen einzelnen Allokationen. Zudem kann man in der Praxis den Zugriff meistens einfach so umformen, dass man auch bei dem std::vector ohne die potentiell teuren Operationen auskommt.(Zum Beispiel ein zu löschendes Element nicht löschen sondern mit den letzten tauschen) Außerdem ist die std::list durch Caching Effekte wesentlich langsamer beim Iterieren. Klar, die Elemente sind wild im Speicher verteilt und hinter n Pointern versteckt, während sie beim std::vector direkt hintereinander liegen. Meine Empehlung ist: Immer std::vector nehmen.

Nebenbei möchte ich noch die Möglichkeit von Arrays in Smart Pointern hinweisen: std::unique_ptr<T[]>