dtor macht zu viel kaputt, shared_ptr?

Eisflamme

Hi,

Das Topic ist nicht sehr gut, tut mir Leid.

Ich habe eine Texturklasse. Im ctor lädt die über eine Datei das Bild. Im dtor wird das Bild wieder zerstört. Dabei nutze ich OpenGL und OpenGL verwaltet die Daten auch, sodass die Texturklasse eigentlich nur eine ID auf die Textur hält sowie ein paar Methoden, welche die Texturfunktionen von OpenGL kapseln, also eine Art Wrapper.

Problem:
Wenn ich diese Texturklasse in einem Container nutze, werden natürlich Kopien erstellt und zerstört (dtor!). Der Copy-ctor überträgt natürlich nur die ID etc. und lädt nicht jedes Mal anhand des Dateinamens neu, also ist das Bild dann weg.

Lösung:
Meine Idee, die auch funktioniert, ist, halt einen Container mit shared_ptr zu nehmen. Eigentlich ist das damit ziemlich einfach gelöst.

Findet ihr das gut oder denkt ihr, ich habe hier einen Designfehler bzw. habt ihr bessere Vorschläge?

Sorry, ich frage gerade jeden Furz nach, aber bin Anfänger und will viel lernen.

Vielen Dank schon Mal!

theta

Das Problem mit dem shared_ptr zu lösen ist gut.

krümelkacker

theta schrieb:

Das Problem mit dem shared_ptr zu lösen ist gut.

Zusätzlich sollte er Copy-Ctor und Zuweisungsoperator "deaktivieren", dass so ein Objekt nicht versehentlich kopiert werden kann. Er hat im Prinzip die Dreierregel verletzt.

class NichtKopierbar : boost::noncopyable
{
public:
  explicit NichtKopierbar(blah);
  ~NichtKopierbar(blah);
  ...
};

oder

class NichtKopierbar
{
private:
  // werden absichtlich privat deklariert und NICHT definiert:
  NichtKopierbar(NichtKopierbar const&);
  NichtKopierbar& operator=(NichtKopierbar const&);
public:
  explicit NichtKopierbar(blah);
  ~NichtKopierbar(blah);
  ...
};

kk

Du musst die Affinity der Tokens beachten.

hustbaer

Eisflamme schrieb:

Lösung:
Meine Idee, die auch funktioniert, ist, halt einen Container mit shared_ptr zu nehmen. Eigentlich ist das damit ziemlich einfach gelöst.

Findet ihr das gut oder denkt ihr, ich habe hier einen Designfehler bzw. habt ihr bessere Vorschläge?

Ich finde das gut - siehe meine Antwort im anderen Thread. Texturen haben eine Identität, und sollten daher nicht kopierbar sein. Da man in Game-Engines vermutlich öfters mal Shared-Ownership hat, ist shared_ptr<T> auch die richtige Wahl.

Evtl. könnte noch eine std::map<MyIdType, shared_ptr<T>> besser geeignet sein als ein Vektor. Und zwar wenn du oft eine Textur anhand ihrer ID (Name/Nummer/...) raussuchen musst. z.B. wenn in einem Datenfile auf Texturen referenziert wird.

Eisflamme

Hi,

Jep, ich nutze die auch ueber eine Map. Dummerweise gerade noch ueber Schluessel string, das werde ich wohl Mal in eine unordered_map schieben, sollte ja schneller gehen.

kruemelkracker:
Mit der Dreierregel hast Du ebenfalls Recht, werde ich umsetzen, danke!

hustbaer

Mit der Dreierregel hab' nicht ich recht sondern krümelkacker

Eisflamme

Genau, hab's korrigiert/verstaendlicher gemacht.

Nexus

Betrifft zwar nicht genau dein Problem, aber vielleicht hilft dir die Diskussion über eine Ressourcen-Verwaltungklasse, die ich kürzlich geführt habe.

Roger Wilco

Nexus schrieb:

Betrifft zwar nicht genau dein Problem, aber vielleicht hilft dir die Diskussion über eine Ressourcen-Verwaltungklasse, die ich kürzlich geführt habe.

Auf diesen Thread habe ich Ihn hier auch schon hingewiesen.

Nexus

Habs nachher auch noch gesehen, danke