vectoren mit selbsdef. objekten als typ



  • Ich habe mehrere vektoren die als Typ Objekte enthalten. werden diese Objekte dann auf dem Heap angelegt? Entfällt somit für mich das speicher allokieren?
    Wenn nicht wie mache ich das dann bei nem Vektor? Oh und noch so nebenbei. Kann ich vektoren einer funktion übergeben und wenn ja wie?
    Fragen über Fragen ich weiß:-)) Kann mir einer helfen?



  • beim einfügen in einen vektor wird der copyconstruktor aufgerufen. an funktion würde ihc als Zeiger oder Referenz übergeben.
    Folgendes Beispiel soll beides verdeutlichen:

    void func(vector<YourClass> *pVec)
    {
        YourClass Obj;
        Obj.bar = 4;
        pVec->push_back(Obj);
    }
    
    void foo()
    {
        vector<YourClass> Vec;
        func(&Vec);
        assert(Vec.size()==1);
    }
    

    Du siehst an dem Beispiel, wie vectoren an funktionen übergeben werden und du siehst, dass du das Objekt nicht so lange im Speicher halten musst, wie du es im Vektor brauchst, da es beim einfügen in den Vektor kopiert wird.



  • Original erstellt von dEUs:
    beim einfügen in einen vektor wird der copyconstruktor aufgerufen.

    wirklich?



  • Ich glaub ja. Ich glaube mich zu erinnern, dass ich das beim debuggen mal gesehen hab. Ist dem nciht so?



  • Original erstellt von dEUs:
    Ich glaub ja. Ich glaube mich zu erinnern, dass ich das beim debuggen mal gesehen hab. Ist dem nciht so?

    oh graus, es ist so.

    void push_back(const _Ty& _X)
        {insert(end(), _X); }
    

    hab immer gehofft, da ist ein template-parameter, der sich runterschleppt bis ins placement-new, muß wohl sorgfältiger der stl ausweichen.



  • Hm, wie würdest du es lösen? Ich denke, ich wüsste wie, wenn cih deinen Satz verstehen würde 😉



  • Original erstellt von dEUs:
    Hm, wie würdest du es lösen? Ich denke, ich wüsste wie, wenn cih deinen Satz verstehen würde 😉

    ohne zu tief drüber nachzudenken, wie viele unterstriche die members der stl-dinge haben, in etwa so:

    template<class T>
    class vector
    {
      template<class X>
      void push_back(X const& x)
      {
         grow(size+1);
         new(&data[size])T(x);
         ++size;
      }
    


  • Vielleicht tut insert das ja?



  • Original erstellt von Bashar:
    Vielleicht tut insert das ja?

    push_back ist der wichtigste weg zu insert. wenn push_back das nich tut, hab ich schon lust, mir nen neuen vector zu bauen.



  • 1. das macht keinen sinn.

    2. was ist bei dir X?

    3. wie genau soll das mit dem placement new gehen? irgendwie muss das objekt ja kopiert werden, entweder flach (nicht gut) oder mit dessen cctor.



  • 2 und 3 dachte ich mir auch, aber ich habs dann einfach auf mein Unverständnis geschoben 😉



  • Original erstellt von PeterTheMaster:
    1. das macht keinen sinn.
    2. was ist bei dir X?
    3. wie genau soll das mit dem placement new gehen? irgendwie muss das objekt ja kopiert werden, entweder flach (nicht gut) oder mit dessen cctor.

    lies den code nochmal. frag dann, was du nicht verstanden hast. aber widersprich nicht blind.
    1. doch, ist sich schneller, wenn kopien von T teuer sind.
    2. siehe template<class X>...
    3. wie es gehhen soll? so, wie ich es mag. das T-objekt im vector sollte konstruiert werden. weder flach noch mit dessen cctor.
    ich stelle mir als T die 1000-byteige klasse
    class Student
    nebst
    Student(string const& fileName)
    vor.
    will ich studenten hochreichen kopieren oder string-referenzen?



  • syntaktisch ist dein X ja richtig, aber welchen sinn macht das? Wieso soll ich in nen vektor vom typ int nen string einfügen können?



  • Original erstellt von dEUs:
    syntaktisch ist dein X ja richtig, aber welchen sinn macht das? Wieso soll ich in nen vektor vom typ int nen string einfügen können?

    wenn ein umwandlungskonstruktor von string in Student besteht, muß ich doch wahlich keinen Studenten bauen, nur um ihn dann in den vector zu kopieren, und dann den alten zu löschen, wenn ich ihn direkt im vektor bauen kann.

    wollt ihr keine schnellen progs oder sind es politische und ideologische ressentiments?



  • Ich kapier den sinn trotzdem nicht. erklär mal anschaulich, wie der unterschied liegt ...



  • Original erstellt von dEUs:
    Ich kapier den sinn trotzdem nicht. erklär mal anschaulich, wie der unterschied liegt ...

    ich tu steuerdatei mit 100 studenten-dateinamen einlesen und die steundenten in nen vector.

    zeiger der stoppuhr mit ctor con string, copy-ctor, dtor pro pushback:

    |
           |  
           | 
           *------
    

    zeiger der stoppuhr mit ohne ctor, copy-ctor, dest pro pushback, sonder nur einem ctor von string.

    |  /
           | / 
           |/
           *
    

    [ Dieser Beitrag wurde am 17.06.2003 um 21:14 Uhr von volkard editiert. ]



  • @volkard
    Dein ursprüngliches Problem verstehe ich nicht. Die Container der STL Speichern von je her *Kopien* der einzufügenden Objekte. Und *Kopien* erhält man in C++ durch Aufruf des Copy-Ctors. Das ist erstmal völlig unabhängig von placement-new. Für den Fall, dass du ein vector<T> mit ausreichender Kapazität hast und du ein Objekt vom Typ *T* einfügen willst (als Kopie), *muss* genau ein Copy-Ctor-Aufruf erfolgen. Egal ob mit placement-new oder nicht.

    Doof an push_back ist allerdings, dass, falls du ein Objekt vom Typ U der konvertiertbar nach T ist, du *zwei* Aufrufe des Copy-Ctors hast. Einmal um das Objekt an die const-Ref von push_back zu binden und einmal um den Parameter in den noch uninitialisierten Speicher zu konstruieren.

    Das lässt sich wiederum aber umgehen, in dem du statt push_back die dritte insert-Form verwendest.
    Genauer beschrieben findest du das ganze hier.

    Allen die etwas mehr Zeit habe empfehle ich die Lektüre der gesamten Diskussion



  • klingt ne größenordnung unhandlicher. als push_back. und sieht mir nach nem bugfix aus.



  • klingt ne größenordnung unhandlicher. als push_back.

    Definitiv.

    und sieht mir nach nem bugfix aus.

    Das kommt wohl darauf an, wie man das ganze betrachtet. Wenn man z.B. so wie James Kanze argumentiert (eine Argumentation die ich gut nachvollziehen kann), dann ist es kein Bugfix, da hier einfach versucht wird das Design der STL zu verbiegen. Auf der anderen Seite sehe ich nicht unbedingt was gegen die aufgebohrte Membertemplate-Lösung spricht.



  • Danke für die hilfe,
    aber nochmal damit ich es richtig verstanden hab. Also ein Vektor von einem selbsterstelltem Objekt ist dann automatisch immer dynamisch angelegt und liegt auf dem Heap
    z.B.:vector<node> baum
    wenn node von mir selbst erstellt ist. Liegt dann auch jedes node objekt auf dem Heap ohne das ihc was mit new initialisiere?


Anmelden zum Antworten