vectoren mit selbsdef. objekten als typ



  • 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