Erzeugen STLContainer Kopien oder nicht?



  • Jetzt muss ich aber zum Thema Container noch mal nachhaken:

    Wie man ja merkt, ist das Thema STL für mich noch relativ neu. Ich hab bisher immer eigene Containerklassen verwendet. Meine LinkedList z.B. übernahm generell einen Pointer auf ein dynamisch erzeugtes ContentObjekt als zu archivierendes Element.
    Die Container der STL übernehmen ja i.d.R. Referenzen auf ContentObjekte.
    Wird dann intern eine dynamische Kopie erstellt und per Pointer im Container archiviert oder wie? Und werden alle archivierten Objekte auch beim Löschen des Containers automatisch entfernt?

    Wenn tatsächlich intern eine Kopie erstellt wird, hab ich ja niemals die Möglichkeit ausserhalb des Containers ein ContentObjekt dynamisch zu erzeugen und erst dann in den Container einzufügen?

    Wäre schön, wenn ihr mir dabei auch noch weiterhelfen könntet!

    Danke!

    Grüße
    TS++



  • ich glaube in der stl documentation steht was passendes
    ([url] http://www.sgi.com/tech/stl/Container.html [/url])

    A Container "owns" its elements: the lifetime of an element stored in a container cannot exceed that of the Container itself.

    aber man kann ja Pointer in einen Container einhaengen ...



  • klar hast du die moeglichkeit, du kannst einen vector aus pointern machen. mit autopointern brauchst du sie dann nichtmal selber loeschen.



  • Seit wann gehen auto_ptr in Container?



  • Original erstellt von Bashar:
    Seit wann gehen auto_ptr in Container?

    Sind sie noch nie.



  • Also müsste ich dann eine eigene Containerschicht über den Vector aus Pointer drüberlegen, die beim Löschen des Containers dafür sorgt, dass alle per Pointer referenzierten ContentObjekte mit delete gelöscht werden. Denn ein Vector aus Pointern enthält ja nunmal nur die Pointer und nicht die ContentObjekte selbst.

    Demzufolge kann ich dann ja eine LinkedList der STL nur verwenden, wenn ich eine Referenz auf das ContentObjekt übergebe. Hab ich das Objekt dynamisch angelegt, muss ich meinen eigenen Container verwenden, der mit Pointern zurechtkommt.
    ==> dann kann ich ja aber niemals dynamisch und lokal erzeugte Objekte zusammen im gleichen Container unterbringen.

    Dafür muss es doch eine Lösung geben!

    Grüße,
    TS++



  • ich hab nicht von auto_ptr geredet. vielleicht haette ich besser smartpointer sagen sollen.
    z.b. was referenz zaehlendes, damit gehts auf jeden fall.

    und wie soll denn ein container funktionieren, in den du sowohl heap als auch stack objekte reintust, ohne zu kopieren? da musst du auf jeden fall das aufraeumen gesondert behandeln. ich find es aber eine ziemlich doofe idee, stackobjekte per pointer in einen container zu tun. da muss man immer aufpassen, wie lange die leben. also ist kopieren schon ok. oder alternativ alle per new. mit einem entsprechenden smartpointer braucht man die auch nicht von hand loeschen und man hat den gleichen komfort wie mit stackobjekten.



  • OK, es wär vielleicht wirklich etwas zu umständlich einen derartigen "Misch"-Container zu realisieren. Mit zwei unterschiedlich archivierenden Containern, also einem für Referenzen und einem für Pointer, zu arbeiten, ist mit Sicherheit auch keine optimale Lösung, wenn es darum geht eine übersichtliche und allgemeingültige Containerbibliothek aufzubauen.
    Ich werd jetzt die gängigsten Container vom STLPort, wie vector, map, list und hash_map mit eigenen Containerklassen kapseln und ein paar zusätzliche Methoden implementieren und Operatoren überladen.
    Jetzt muss ich mich nur noch daran gewöhnen, bei der Arbeit mit Containern auch immer Referenzen zu übergeben. Beim Zugriff auf einzelne ContentObjekte bin ich ja wieder frei. Egal ob ich ne Kopie zurückgeben lasse, eine Referenz oder einen Pointer auffange, das müsste ich ja eigentlich mit einer internen Accessorklasse und dem Überladeoperator hinkriegen. Mal schaun! 😉

    Und dann noch ne Kleinigkeit:
    Zu dem Thema hab ich mich zwar schon geäußert, aber ich probiers an dieser Stelle einfach noch mal.

    Ist vielleicht unter euch jemand, der sich schon etwas intensiver mit der 'hash_map'-Klasse von SGI befasst hat?
    Es geht nähmlich um folgendes Problem:

    In der offiziellen Dokumentation steht folgende Info:

    Member:
    -------
    data_type& operator[](const key_type& k)

    Description:
    ------------
    Returns a reference to the object that is associated with a particular key. If the hash_map does not already contain such an object, operator[] inserts the default object data_type().

    Wenn ich das richtig verstehe, wird also beí erfolgloser Suche in der HashMap ein DefaultObjekt vom Typ data_type erzeugt, in die Map eingefügt und eine Referenz auf dieses neue Objekt zurückgegeben.

    Nur wie erkenne ich denn jetzt anhand dieser Referenz, dass es sich dabei nicht um das ´ContentObjekt' handelt, das ich eigentlich erwartet habe?

    Bitte helft mir auf die Sprünge!
    Ich kann hier doch nicht der Einzige sein, der sich schon mit den SGI-Erweiterungen befasst hat!

    Danke!

    Grüße,
    TS++

    [ Dieser Beitrag wurde am 16.06.2003 um 14:01 Uhr von TS++ editiert. ]


Anmelden zum Antworten