Speicherzugriffsfehler bei map

Nexus

PolynomJo schrieb:

Ich dachte eher daran, dass die Elemente in der Map nach dem beenden der Methode irgendwie nicht mehr zur Verfügung stehen. Kann das sein?

Ja, wenn du die Map lokal deklarierst, lebt sie nur bis zum Ende des Blocks. Daher musst du aufpassen, dass nachher keine Zeiger, Referenzen und Iteratoren mehr benutzt werden, die immer noch auf die Map verweisen.

PolynomJo schrieb:

Meine STL Implementierung ist, die von g++ (wenn man das so sagen kann). Wo nach muss ich da suchen?

Mit der g++-Standardbibliothek kenne ich mich nicht gut aus, aber möglicherweise sind im Debug-Modus (Makro NDEBUG nicht definiert) einige Sicherheitsmechanismen automatisch an. Ansonsten ist das Kennenlernen eines Debuggers sicher keine schlechte Idee. Je nachdem, was für eine IDE du verwendest, geht das auch grafisch. Ich bin halt von Visual Studio verwöhnt

PolynomJo

Nexus schrieb:

Ja, wenn du die Map lokal deklarierst, lebt sie nur bis zum Ende des Blocks. Daher musst du aufpassen, dass nachher keine Zeiger, Referenzen und Iteratoren mehr benutzt werden, die immer noch auf die Map verweisen.

Genau das mache ich aber. Und solange ich nur sowas mache:

sResP[p] = P;

Klappt das auch einfach und ich sehe es dann in der Map. Warum nicht bei komplizierteren, errechneten Audrücken?

Nexus

PolynomJo schrieb:

Genau das mache ich aber.

Dann solltest du damit aufhören.

PolynomJo schrieb:

Und solange ich nur sowas mache:
sResP[p] = P;
Klappt das auch einfach und ich sehe es dann in der Map.

Hier greifst du ja nicht auf ungültige Zeiger/Referenzen/Iteratoren zu, warum sollte es also nicht klappen? Das Problem entsteht erst, wenn einzelne Elemente oder die ganze Map gelöscht wird und noch Verweise darauf bestehen...

pumuckl

was ist ex? wie ist dein MultivariateDingsda definiert?
Das sieht aus als ob der Zugriff auf variables irgendwo danebenhaut.

Bist du sicher, dass der Fehler bei der Map liegt und nicht in " Q.mul(factor_p)"?

Ersetze doch mal

sResP[q] = Q.mul(factor_p);

durch

MultivariatePolynomial<monomialOrdering> xyz = Q.mul(factor_p);
sResP[q] = = xyz;

pumuckl

einen Debugger dranzuhängen sollte auch genau zeigen, wo der Zugriffsfehler passiert...

PolynomJo

Oke, danke! Der Debugger hilft, denn er weißt auf ganz merkwürdige Fehler hin:

cout << p.degree(x) << endl;
	cout << p.diff(x).degree(x) << endl;

	map<int, MultivariatePolynomial<ex_is_lesseq_deggrlex> > m =
			MultivariatePolynomialFactory::signedSubresultant(p, p.diff(x), x);

Dieses Programm habe ich ausgeführt und es gibt als Ausgabe 2 und 1, was richtig ist, denn es ist ein quadratisches Polynom in x.

Innerhalb der Methode signedSubresultant, wenn ich mit dem Debugger darein gehe, haben die Variables p und q aber beide den Wert 4

Ich benutze exakt den gleichen Funktionsaufruf .degree(...). Was ist das los?

CStoll

Könnten wir eventuell mal sehen, was sich genau hinter p und x verbirgt?

PolynomJo

CStoll schrieb:

Könnten wir eventuell mal sehen, was sich genau hinter p und x verbirgt?

Klar, sorry das ist alles so viel Code ich will euch nur nicht überfluten

GiNaC::symbol x("x");

MultivariatePolynomial<ex_is_lesseq_deggrlex> p(
			8 * x * x * y * -2 * y * y * y + 5, l);

MultivariatePolynomial<...> ist eine Klasse die von GiNaC::ex geerbt ist und überprüft, ob es sich um eine Polynom handelt. ex_is_lesseq_deggrlex definiert eine Ordnung.

http://www.ginac.de/reference/classGiNaC_1_1symbol.html <- symbol
http://www.ginac.de/reference/classGiNaC_1_1ex.html <- ex

PolynomJo

Autsch! degree() wertet nach der falschen Variable aus