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!

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

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.

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!

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.