da mir hier im Forum schon viel und kompetent geholfen wurde, ich aber immer noch blutiger C++ Anfänger bin habe ich zu diesem Thema noch eine Frage.

Ich habe mir meine bisherigen Threads dazu schon durchgelesen, sowie auch einige andere Threads.

Allerdings werde ich dadurch nur immer verwirrter anstatt Klarheit zu bekommen!

Es wurde z.B. von versch. Postern gesagt, dass sie in C++ (fast) ganz ohne Zeiger auskommen!

Nun habe ich aber ein paar Klassen, die quasi als Factories agieren, in denen also Objekte eines bestimmten Typs (pro Klasse ein Typ, oder wäre hier ein Template-Ansatz besser?) erzeugt und verwaltet werden.
Diese Klassen sorgen für das Anlegen und Löschen der Objekte im Speicher und verwalten die Objekte je nachdem, wie sie wieder aufgefunden werden müssen mit (unterschiedlichen) STL-Containern.

Da die Objekte von anderen Klassen zur Laufzeit verwendet und dementsprechend in der Factory-Klasse wiedergefunden werden müssen, müssen die Objekte also den Aufruf der create-Methode überstehen, in der sie erzeugt und in den entsprechenden STL-Container abgelegt werden.

Als Bsp.: In meiner "Factory" sollen grafische Objekte erzeugt und verwaltet werden, jedes nur einmal, ich muss aber jedes über eine Methode wiederfinden und nen Zeiger bzw. Referenz darauf bekommen können, da ich sie an unterschiedlichen Stellen im Programm einsetzen will.

Das geht doch nur und ausschließlich mit Zeigern und der Anlage der Objekte mittels new!? Oder nicht?

Falls noch Code benötigt wird, kann ich diesen gern nachreichen (steht z.T. schon in nem anderen Thread)!

Vielen Dank schon einmal!
Ciao

Wie du aber selber schon richtig geschrieben hast, kommt man "(fast) ganz ohne Zeiger" aus. Wenn hier dieser "Spruch" gezogen wird, soll eigentlich nur das eine Extrem deutlich gemacht werden.

new benutzt man dann, wenn man dynamisch(e) Objekte anlegen will. Dazu zählt, wenn man zur Laufzeit nicht weiß, welcher genaue Typ erzeugt werden soll.

Ein Container vector<A> kann ausschliesslich A-Objekte aufnehmen. Will ich A-Objekte und davon abgeleitete aufnehmen, geht das nicht und ich muß einen vector<A*> Container definieren. Oder ich baue mir einen Handler, in dem A-Objekte drin liegen:

// Ganz spartanisch (Pseudocode):
struct A_Handler
{
    A* a_ptr;
};
vector<A_Handler> a;

Aber dann kann man auch gleich SmartPointer benutzen.

Du willst also deine Factory-Objekte in einem Container zwischenlagern? Ist das jetzt wegen der "new"-Thematik oder ist das dein erdachtes Design? Wenn es nur um die Vermeidung des new geht, solltest du über Smart-Pointer nachdenken. Gib einfach ein mit new erzeugtes Objekt in einem Smart-Pointer raus.

In einer Factory werden aber für gewöhnlich Objekte mit new erzeugt. Man könnte sie auch ohne new erzeugen, in einem Container speichern und dann eine Referenz raus geben. Aber dann kannst du eigentlich nur immer einen Objekt-Typ erzeugen. Nicht so der Sinn einer Factory.

Die Verwaltung der Objekte zur Laufzeit in Container brauche ich aus folgenden Gründen:

1. Es steht vor der Laufzeit nicht unbedingt fest, wie viele solcher Objekte benötigt werden (müssen also dynamisch erzeugt werden).
2. Die jeweiligen Objekte sollen selbst nur einmal vorkommen, aber an unterschiedlichen Stellen im Programm und zu unterschiedlichen Programmzeitpunkten verwendet werden können (sie müssen also wieder auffindbar sein).

Dazu hab ich mir dann die "Factoryklassen" überlegt, die eigentlich mehr Verwalter sind. Sie erzeugen die Objekte bei Bedarf, legen sie (z.B. zu einem Schlüssel) in einen Container und wenn eines benötigt wird, wird es anhand des übergebenen Schlüssels im Container gefunden und ein Zeiger/eine Referenz darauf zurückgegeben.

So die Idee!

Oder macht man sowas ganz ganz anders?

Ciao

1. Es steht vor der Laufzeit nicht unbedingt fest, wie viele solcher Objekte benötigt werden (müssen also dynamisch erzeugt werden).

OK, ob hier Container deshalb unabdingbar sind, sei dahin gestellt...

2. Die jeweiligen Objekte sollen selbst nur einmal vorkommen, aber an unterschiedlichen Stellen im Programm und zu unterschiedlichen Programmzeitpunkten verwendet werden können (sie müssen also wieder auffindbar sein).

Hem, verstehe ich nicht wirklich, was du damit sagen willst. Ein Objekt kann nur immer einmalig vorkommen.
Das sie wieder auffindbar sein müssen, z.B. über einen Schlüssel oder ID, macht dann tatsächlich Sinn, sie in einen Container zu legen. Wobei Pointer bzw. die Adresse auf die er zeigt, auch ein Schlüssel oder ID ist. Ist alles eine Auslegungssache des Designers (also in dem Fall du selbst).

Dazu hab ich mir dann die "Factoryklassen" überlegt, die eigentlich mehr Verwalter sind. Sie erzeugen die Objekte bei Bedarf, legen sie (z.B. zu einem Schlüssel) in einen Container und wenn eines benötigt wird, wird es anhand des übergebenen Schlüssels im Container gefunden und ein Zeiger/eine Referenz darauf zurückgegeben.

Also ist es mehr eine Managerklasse. Die Objekterzeugung ist eher eine Nebensache. Gut, und wenn die Objekte z.B. über einen String oder eine laufende ID wiedergefunden werden sollen, macht natürlich ein Container (z.B. eine std::map) Sinn. Wenn es sich dabei immer um den gleichen Objekttyp handelt, komme ich zu dem Fazit, das du dann kein new benötigst (zumindest in erster Instanz nicht).

Artchi schrieb:

1. Es steht vor der Laufzeit nicht unbedingt fest, wie viele solcher Objekte benötigt werden (müssen also dynamisch erzeugt werden).

OK, ob hier Container deshalb unabdingbar sind, sei dahin gestellt...

Was wären denn Alternativen?

Artchi schrieb:

2. Die jeweiligen Objekte sollen selbst nur einmal vorkommen, aber an unterschiedlichen Stellen im Programm und zu unterschiedlichen Programmzeitpunkten verwendet werden können (sie müssen also wieder auffindbar sein).

Hem, verstehe ich nicht wirklich, was du damit sagen willst. Ein Objekt kann nur immer einmalig vorkommen.
Das sie wieder auffindbar sein müssen, z.B. über einen Schlüssel oder ID, macht dann tatsächlich Sinn, sie in einen Container zu legen. Wobei Pointer bzw. die Adresse auf die er zeigt, auch ein Schlüssel oder ID ist. Ist alles eine Auslegungssache des Designers (also in dem Fall du selbst).

Ok, hier hab ich wohl zuviel weggelassen!
Einige der Objekte kapseln z.B. Grafikdaten und für jede Grafik soll nur ein solches Objekt angelegt und dieses überall wo nötig verwendet werden. Theoretisch könnte ich mir ja zu jeder Verwendungsmöglichkeit einer solchen Grafik schnell so ein Objekt anlegen. Dann hätte ich die Grafik mehrfach im Speicher. Das will ich vermeiden. Ähnliches gilt für die anderen Objekttypen.

Artchi schrieb:

Dazu hab ich mir dann die "Factoryklassen" überlegt, die eigentlich mehr Verwalter sind. Sie erzeugen die Objekte bei Bedarf, legen sie (z.B. zu einem Schlüssel) in einen Container und wenn eines benötigt wird, wird es anhand des übergebenen Schlüssels im Container gefunden und ein Zeiger/eine Referenz darauf zurückgegeben.

Also ist es mehr eine Managerklasse. Die Objekterzeugung ist eher eine Nebensache. Gut, und wenn die Objekte z.B. über einen String oder eine laufende ID wiedergefunden werden sollen, macht natürlich ein Container (z.B. eine std::map) Sinn. Wenn es sich dabei immer um den gleichen Objekttyp handelt, komme ich zu dem Fazit, das du dann kein new benötigst (zumindest in erster Instanz nicht).

Wie würde es denn dann funktionieren, wenn ich die Objekte zur Laufzeit erzeugen und erst beim Beenden des Programmes freigeben will?

Ciao

Was wären denn Alternativen?

Gar keine Container, einfach erzeugen und fertig.

Ok, hier hab ich wohl zuviel weggelassen!
Einige der Objekte kapseln z.B. Grafikdaten und für jede Grafik soll nur ein solches Objekt angelegt und dieses überall wo nötig verwendet werden. Theoretisch könnte ich mir ja zu jeder Verwendungsmöglichkeit einer solchen Grafik schnell so ein Objekt anlegen. Dann hätte ich die Grafik mehrfach im Speicher. Das will ich vermeiden. Ähnliches gilt für die anderen Objekttypen.

OK, ist mehr als logisch. Also tatsächlich eine Managerklasse. Oder auch GrafikCache-Klasse. Na, da weiß ich aber nicht wo wirklich das Problem ist? Sagen wir mal, du hast eine Grafik-Klasse, und jede Grafik liegt als Datei vor. Dann würde sowas Sinn machen:

class Grafik;

class GrafikManager // oder auch GrafikFaktory....
{
    std::map<std::string, Grafik> grafiken;

public:
    Grafik& getGrafik(const std::string &filename)
    {
           std::map<std::string, Grafik>::iterator iter = grafiken.find(filename);

           if(iter == grafiken.end() )
           {
                  Grafik gfx(filename);
                  return (grafiken[filename] = gfx);
           }
           else
              return iter->second;
    }
};

Eigentlich ganz easy... mußt nur bedenken, dass das Grafik-Objekt beim einfügen in den Container kopiert wird. Aber da du sicherlich die Bitmaps in einem Pointer drin hast, ist das nicht schlimm, da nur der Pointer kopiert wird und nicht die ganze Bitmap. Also, innerhalb der Factory-Klasse braucht man weiterhin kein new. Kann sein das du irgendwann vielleicht doch auf new umsteigen mußt, aber das würde ich nur machen, wenn es nötig wird.

Wie würde es denn dann funktionieren, wenn ich die Objekte zur Laufzeit erzeugen und erst beim Beenden des Programmes freigeben will?

Wenn Du kein new benutzt, brauchst du dich ja nicht drum kümmern. Wenn du doch new benutzt, dann bau in deiner Factory in den Destruktor etwas ein, was den Inhalt des Containers durchläuft und die Objekte löscht. Fertig.

...
return (grafiken[filename] = gfx);
...
};

Das macht eine Zuweisung und gibt die Referenz auf das eingefügte Grafikobjekt zurück?

Artchi schrieb:

Eigentlich ganz easy... mußt nur bedenken, dass das Grafik-Objekt beim einfügen in den Container kopiert wird. Aber da du sicherlich die Bitmaps in einem Pointer drin hast, ist das nicht schlimm, da nur der Pointer kopiert wird und nicht die ganze Bitmap. Also, innerhalb der Factory-Klasse braucht man weiterhin kein new. Kann sein das du irgendwann vielleicht doch auf new umsteigen mußt, aber das würde ich nur machen, wenn es nötig wird.

Und die Kopie lebt so lange wie die map?

Artchi schrieb:

Wie würde es denn dann funktionieren, wenn ich die Objekte zur Laufzeit erzeugen und erst beim Beenden des Programmes freigeben will?

Wenn Du kein new benutzt, brauchst du dich ja nicht drum kümmern. Wenn du doch new benutzt, dann bau in deiner Factory in den Destruktor etwas ein, was den Inhalt des Containers durchläuft und die Objekte löscht. Fertig.

So ist es bisher: Im Destruktor wird der STL-Container durchlaufen und alle enthaltenen Objekte werden mit einem delete bedacht.

Ciao

Das macht eine Zuweisung und gibt die Referenz auf das eingefügte Grafikobjekt zurück?

Korrekt. Da es ja kopiert wird, wäre es fatal das erste gfx zu returnen. Ganz davon abgesehen, das gfx eh nur temporär ist, und temporäre Objekte als Ref returnen ist schlecht, weil es in der Zwischenzeit wieder gestorben ist. Also das returnen, was in der Map tatsächlich eingefügt wurde.

Und die Kopie lebt so lange wie die map?

Korrekt!

So ist es bisher: Im Destruktor wird der STL-Container durchlaufen und alle enthaltenen Objekte werden mit einem delete bedacht.

Ist ja auch nicht falsch. Je nach Anforderung, die du gerade hast. Das Kopieren entfällt hier natürlich. Kann je nach Objektgröße schneller sein.

Ab C++2009 wird sich das wohl ändern, da werden die Objekte beim Einfügen in die Container wohl nicht mehr kopiert, sondern verschoben. Dann gehts auch schnell ohne Pointer.

Mache es so, wie es für deine Anforderungen am besten ist.

So ist es bisher: Im Destruktor wird der STL-Container durchlaufen und alle enthaltenen Objekte werden mit einem delete bedacht.

Ist ja auch nicht falsch. Je nach Anforderung, die du gerade hast. Das Kopieren entfällt hier natürlich. Kann je nach Objektgröße schneller sein.

Ab C++2009 wird sich das wohl ändern, da werden die Objekte beim Einfügen in die Container wohl nicht mehr kopiert, sondern verschoben. Dann gehts auch schnell ohne Pointer.

Mache es so, wie es für deine Anforderungen am besten ist.

Tja, und woher weiss ich was besser meinen Anforderungen entspricht (so als Noob meine ich)? Gibts da Kriterien, anhand derer ich das Abwägen/Entscheiden kann?

Der einzige Unterschied ist doch, dass ich in der Map einmal nur Zeiger drin habe, beim anderen Ansatz aber ganze Objekte (oder nur Referenzen darauf), oder?
Da ist in meinen Augen eine Map mit Zeigern doch performanter als eine mit ganzen Objekten, oder?

Was ich dann zurückgebe, ob eine Referenz auf ein enthaltenes Objekt, oder einen Zeiger darauf ist ja in beiden Fällen unerheblich!

Ciao

Die Std-Container und die Std-Algorithmen sind eigentlich dafür ausgelegt, Objekte aufzunehmen bzw. zu verarbeiten. Deshalb sollte man erstmal von Objekten ausgehen, z.B. std::vector<string> oder std::vector<int> oder... So sollte man erstmal denken.

Nun die Ausnahmen:
1. Wenn man polymorphe Objekte (also verschiedene Typen eines bekannten Basistyps) speichern will, muß man Pointer speichern. Oder komfortablerweise vielleicht einen Handler oder Smartpointer benutzen.

2. Wenn beim hinzufügen und löschen von großen Objekten zu viel Zeit verschwendet wird, und dieses für den eigenen Anwendungsfall nicht tragbar ist, ist die Lösung aus Ausnahme 1 anzuwenden. Wobei Handler/Smartpointer auch wieder ein gewisser Overhead sein können. Wenns hart auf hart kommt, rohe Pointer.

Andere Gründe und eine andere Taktik fällt mir nicht ein.

Der einzige Unterschied ist doch, dass ich in der Map einmal nur Zeiger drin habe, beim anderen Ansatz aber ganze Objekte (oder nur Referenzen darauf), oder?

Referenzen wären schön, dann bräuchte man niemals Pointer. Es ist tatsächlich so: entweder Pointer oder ganze Objekte. Wobei ganze Objekte ja nicht nachteilig sind, wenn du z.B. in einem Container suchst oder iterierst. Es sind nur die zwei Ausnahmen von oben. Wobei Ausnahme 2 ab C++2009 wohl (hoffentlich) entfallen wird.

Hab mir das halt nur einfach vorgestellt, dass der Prozessor (oder wer auch immer das handhabt, die Laufzeitumgebung oder wer auch immer) es einfacher hat, wenn man nur mit Zeigern die ganzen STL-Operationen machen muss, statt mit Objekten!

Gibts denn noch nen weiteren handfesten Vorteil für die Benutzung von Objekte in Containern zu dem, dass diese (Container) extra für Objekte (statt Zeiger) ausgelegt sind?

Jetzt hätt ich mal noch ne weitere Frage zu dem Thema Objekte vs. Zeiger (oder muss ich dazu nen neuen Thread aufmachen?):

Wie ist denn da in C++ der Ansatz der Wahl:
Ich hab eine Hauptklasse meines Programmes, diese benötigt ein Bildschirmobjekt, darauf ein Fensterobjekt, zu diesem wiederum ein Menüobjekt mit entsprechenden Menüobjekteinträgen (auch alles Objekte) etc. etc.
Diese ganzen Objekte müssen während der gesamten Laufzeit zur Verfügung stehen (der Screnn wird z.B. erst ganz am Schluss zugemacht)!

Mein bisheriger Ansatz war so, diese Objekte in main() anzulegen, danach die Hauptprogrammklasse zu erzeugen (wo es ging als Stackobjekte), so dass nach Beenden des Hauptprogrammes alles wieder automatisch aufgeräumt wird.

Nun brauch ich Teile davon in einer anderen Konstallation.
Am liebsten würde ich alles in der init-Methode der Hauptklasse erzeugen, dann müsste ich aber für alle der o.a. Objekte Klassenmember bereithalten, oder wild Zeiger rumreichen und am Schluß darauf achten diese auch wieder mit einem delete zu versehen!

Alle diese Ansätze sagen mir nicht sehr zu (inkl. dem dezeitigen)!

Wie mach ich sowas denn "richtig" (dürfte ja ein "Problem" sein mit dem jeder früher oder später mal zu kämpfen hat)?

Ciao