Zugriffsverletzung bei meineliste.erase(i)



  • Bashar schrieb:

    23.1.1§7 sagt:

    The iterator returned from a.erase(q) points to the element immedi-
    ately following q prior to the element being erased. If no such ele-
    ment exists, a.end() is returned.

    Wenn mich nicht alles täuscht, dann gilt das aber nicht für Container wie map oder set. Deshalb würde ich für assoziative Container grundsätzlich folgende Form vorschlagen:

    for (AssocContainer::iterator it = cont.begin(); it != cont.end();)
    {
        if (bedingung)
            cont.erase(it++);
        else
            ++it; 
    }
    


  • HumeSikkins schrieb:

    Wenn mich nicht alles täuscht, dann gilt das aber nicht für Container wie map oder set.

    Richtig, 23.1.1 beschreibt die Anforderungen an sequentielle Container. Hätte ich dazusagen müssen.



  • HumeSikkins schrieb:

    for (AssocContainer::iterator it = cont.begin(); it != cont.end();)
    {
        if (bedingung)
            cont.erase(it++);
        else
            ++it; 
    }
    

    das ist natürlich schöner, besten dank auch.

    das c-plusplus.net forum ist wirklich eines der schnellsten und besten foren! 👍



  • Hume hat auch geschrieben, dass er das bei assoziativen Containern anwendet. Das klappt nämlich nur bei solchen Containern, die bei erase nicht noch andere Iteratoren als den auf das gerade gelöschte Element ungültig werden lassen. Versuch den Trick doch mal bei vector 😉



  • OK, Weltbild wieder hergestellt ... waer ja erscheutternd, wen M$ ... 😃

    Das ist aber nur rein formal Schmutz. Wenn das nicht mehr geht, müssen sie wohl demnächst ihre Implementation wieder umbauen, da das nach offizieller Lesart ein Versehen im Standard ist. vector soll eigentlich als Array repräsentiert sein. Den Defect Report gibts, im Technical Corrigendum isses auch drin AFAIK, ich weiß nur nicht ob das schon gültig ist.

    Ich hab in der Literatur halt drueber gelesen, das man sich halt nicht drauf verlassen darf ...
    Ok, ich mag standards auch ned gern selber lesen, ich les auch nicht gern im BGB. Ich beziehe die standards lieber ueber Drittanbieter, korrigiert und zensiert ! 😃
    Asche auf mein haupt.

    Und das mit dem Vector != Array ist echt nen greul, weil wie oft muss man WINAPI funktionen feuern, die nen Array of irgendwas wollen. Und trotz vector muss man sich dann trotzdem noch nen eigenen wrapper fuer schreiben ... 😡 Oder man vergewaltigt basic_string<> 😃

    Ciao ...



  • Bashar schrieb:

    RHBaum schrieb:

    Was ist ueberhaupt der Standard ???

    23.1.1§7 sagt:

    The iterator returned from a.erase(q) points to the element immedi-
    ately following q prior to the element being erased. If no such ele-
    ment exists, a.end() is returned.

    Wenn SGI und STLPort das nicht können, sind sie nicht konform.

    deswegen können sie es ja auch ^^
    unter STLport klappt es zumindest perfekt (für die, bei denen es klappen soll ;)).



  • Wobei ich den logischen Hintergrund noch ned auf die schliche gekommen bin ?
    Kann da wer helfen ?

    warum darf ich beim loeschen aus nem nicht assoziativen Container ned das Naechste element gleich zurueckbekommen?
    Ok die elemente sind ned miteinander verkettet, trotzdem gibts ne ordnung ! und die bleibt ja beim loeschen bestehen! Wenn ich nen element loesche, muss der container ja nicht neu sortiert werden !

    Ists wirklich nur wegen performance ? das lookup aufs naechste element ist ja ein bisserl komplizierter, als bei ner Kette. will man damit nur die Benutzung und den Stil verhindern ?

    Ciao ...



  • Bei einem Vektor würden beim erase alle Elemente nach vorne verschoben. Wenn du den Iterator gleichzeitig erhöhst, zeigt er am Ende auf das übernächste Element. Laut Standard ist er allerdings ungültig.



  • der iterator hat nen bezug auf auf den index ?

    Ich mein an welcher stelle das element ist, ist dem iterator doch egal ... der container muss den doch eh neu erzeugen ... oder befuellen .. etc, das ding wird doch kopiert bei der uebergabe ... und die richtige stelle zu merken ist das wenigste problem, das der container beim loeschen in den moment hat ...

    Ciao ...



  • RHBaum schrieb:

    der iterator hat nen bezug auf auf den index ?

    Der Standard sagt, der Iterator wird ungültig. So wie die Regeln aussehen, ist für vector beispielsweise ein simples typedef auf einen Pointer ausreichend als Iterator-Typ.


Anmelden zum Antworten