problem mit erase() & iterator

stick_thai

SERVUS.

ich würde gerne wissen, warum folgender code mit den 2 unterschiedlichen varianten nicht funktioniert. jedes mal, wenn die "while"-schleife zum zweiten mal durchlaufen wird, kommt folgende fehlermeldung:

Debug Assertion Failed! ... Expression: vector iterators incompatible

das gleiche passiert bei der "for"-schleife.

#include <vector>
#include <algorithm>
#include <iostream>
#include <cmath>

using namespace std;

int main ()
{
	int i;
	vector <int> PKT;

	for (i=0;i<10;i++)
		PKT.push_back(i);

//1. VARIANTE:
	i=0;
	vector <int>::iterator it = PKT.begin();
	for (i=0;i<(int)PKT.size();i++)
	{
		if (0 == fmod((double)PKT[i]/2,1))
		{
			PKT.erase(it);
			i--;
		}
		else
		{
			it++;
		}
	}
/*
2. VARIANTE:
	i=0;
	vector <int>::iterator it = PKT.begin();
	while (it!=PKT.end())
	{
		if (0 == fmod((double)PKT[i]/2,1))
			PKT.erase(it);
		else
		{
			i++;
			it++;
		}
	}
*/
}

DANKE.
STICK.

Swordfish

Hm, also bei mir (MSVS 2003 .net) funktionierts anstandslos. Wüsste auch nicht warum es das nicht tun sollte.

Greetz, Swordfish

Wenn du den Vektor veränderst, werden alle Iteratoren, die auf ihn zeigen, ungültig. Du musst iter den Rückgabewert von erase() zuweisen.

Swordfish

Hm. Hab' jetzt mal den Warnungslevel auf 4 gesetzt und bekomm immer noch keine ASSERTION failed. Heißt das mein (dämlicher) Compiler ist in diesem Punkt schon wieder nicht Standardkonform?

Greetz, Swordfish

MFK

Swordfish schrieb:

Hm. Hab' jetzt mal den Warnungslevel auf 4 gesetzt und bekomm immer noch keine ASSERTION failed. Heißt das mein (dämlicher) Compiler ist in diesem Punkt schon wieder nicht Standardkonform?

Mal abgesehen davon, dass Warnings zur Compilezeit generiert werden, und Assertions zur Laufzeit, und damit nichts miteinander zu tun haben:

Ich glaube nicht, dass im Standard steht, wie der Compiler bei einem ungültigen Iterator reagieren muss.

Nein, AFAIK ist das Verhalten hier implementationsdefiniert, d. h. dein Compiler kann machen, was er will. Es wär zwar schön, wenn er warnen würde, doch schau die mal an, was für ein Aufwand das für die Compilerhersteller wär.

Das "Nein" ist auf Swordfish bezogen (ich sollt mal besser zitieren ).

camper

Michael E. logged out schrieb:

Nein, AFAIK ist das Verhalten hier implementationsdefiniert, d. h. dein Compiler kann machen, was er will. Es wär zwar schön, wenn er warnen würde, doch schau die mal an, was für ein Aufwand das für die Compilerhersteller wär.

implementationsdefiniert wäre ja was definiertes. das beispiel ist schlicht undefiniert - stick_thai sollte dem compiler dankbar sein, dass er nen fehler bekommt. der schrottige compiler ist in dem falle vc++7.1 (letztlich ist es nat. ein problem der standardbibliothek und nicht es compilers selbst).

Swordfish

Bäää! @MSVC 2003 .net:

Greetz, Swordfish

camper schrieb:

implementationsdefiniert wäre ja was definiertes. das beispiel ist schlicht undefiniert

Genau darüber war ich mir unsicher (man beachte das AFAIK).

stick_thai sollte dem compiler dankbar sein, dass er nen fehler bekommt.

Bekommt er nicht. Erst beim Debuggen.

camper

Michael E. logged out schrieb:

camper schrieb:

implementationsdefiniert wäre ja was definiertes. das beispiel ist schlicht undefiniert

Genau darüber war ich mir unsicher (man beachte das AFAIK).

stick_thai sollte dem compiler dankbar sein, dass er nen fehler bekommt.

Bekommt er nicht. Erst beim Debuggen.

aber es ist doch ein fehler, oder nicht? ok, es ist nicht der compiler selbst - das war nicht wörtlich zu nehmen - ich hätte entwicklungsumgebung sagen soll.

problem mit erase() &amp; iterator

problem mit erase() & iterator