wundersame std::length_error-exception

corruptedmemory schrieb:

In welche Zeile wird der Fehler denn geworfen?
(Ich habe die Vermutung, dass das gar nicht im gezeigten Code der Fall ist.)

Der Fehler wird genau in der for-Schleife geworfen ( hab ich ganz banal mit nem exit davor und danach getestet ^^ )

Columbo

da bin ich mir nicht sicher, ob wxString das kann

Kann er nicht. wxString hat keinen Iteratorenpaar-Konstruktor.

Kannst du mal den echten Code zeigen? wxString ist keine Spezialisierung eines Templates, daher ist etwas wie wxStringBasic<unsigned char>::iterator nicht Teil deines Codes, oder?

Der Richtige Code ist nicht viel größer, aber gern ^^

const wxString& Auftrag::SchluesselToString() const
	{
		wxString ret; 
		for( wlz::KeyString::const_iterator it = schluessel.cbegin(); it != schluessel.cend(); it++ )
				ret += (char) *it;
		return ret;
	}

Achja und wlz::KeyString ist definiert als:

using KeyString = std::basic_string< unsigned char >; //string für den Schlüssel

Habs getestet, also schluessel ist zum Zeitpunkt des Fehlers leer und der Fehler wird genau bei der for-Schleife geworfen

Columbo

Kannst du es nicht debuggen und den Call-Trace anschaun'?

Hlymur schrieb:

const wxString& Auftrag::SchluesselToString() const
	{
		wxString ret; 
		for( wlz::KeyString::const_iterator it = schluessel.cbegin(); it != schluessel.cend(); it++ )
				ret += (char) *it;
		return ret;
	}

Da ist das Problem, du gibst eine dangling reference zurück: Eine Referenz auf ret, eine lokale Variable.

Fix:

wxString Auftrag::SchluesselToString() const

Columbo

Da ist das Problem, du gibst eine dangling reference zurück:

Nö. Die Exception fliegt (laut seiner Aussage!) bevor das return -Statement überhaupt ausgeführt wird.

Oder wird da irgendwie optimiert?

Arcoth schrieb:

Nö. Die Exception fliegt (laut seiner Aussage!) bevor das return -Statement überhaupt ausgeführt wird.

Oder wird da irgendwie optimiert?

1. UB ist UB.
2. Vermutlich geht es das erste mal gut (ohne Exception), aber der Stack wird zerschossen. Beim zweiten mal passiert dann halt irgendwas.

Columbo

1. UB ist UB.

Das ist mir klar. Das Verhalten von Programmen mit voraussehbar undefiniertem Verhalten ist auch vor der Stelle mit diesem nicht mehr definiert. Interessiert hier aber nicht, das wäre nur Theorie.

2. Vermutlich geht es das erste mal gut (ohne Exception), aber der Stack wird zerschossen.

Ich vermute er hat eher sowas stehen:

wxString str = auftrag.SchluesselToString();

~~Dann dürfte aber schon hier alles kollabieren, da der Destruktor des funktionslokalen Objektes aufgerufen wird bevor die Kopie ausgeführt wird.~~
Hmm, ne.

Kann aber auch anders sein.

camper

Arcoth schrieb:

1. UB ist UB.

Das ist mir klar. Das Verhalten von Programmen mit voraussehbar undefiniertem Verhalten ist auch vor der Stelle mit diesem nicht mehr definiert. Interessiert hier aber nicht, das wäre nur Theorie.

Dabei vergisst du, dass gerade die Grenzen definierten Verhaltens Grundlage vieler Optimierungen sind. Es ist ja klar: sobald diese Funktion betreten wird, kann undefiniertes Verhalten nur durch das Werfen einer Exception verhindert werden. Vielleicht hat sich also der Compiler entschieden nur diesen Codepfad stehen zu lassen?

Also jetzt funktioniert der Code...
Komisch finde ich halt, dass ich genau in der for-Schleife geschmissen wurde und dass der Code mit ausgelagertem Iterator funktioniert...
Aber trotzdem Danke

Columbo

camper schrieb:

Vielleicht hat sich also der Compiler entschieden nur diesen Codepfad stehen zu lassen?

Erklärt GCC irgendwo inwiefern er UB in seine Optimierung einbezieht?