ich bin auf einen (Programmier-)Fehler gestoßen, den ich mir nicht erklären kann, vllt wisst ihr Rat:

std::string ret; 
for( std::basic_string<unsigned char >::const_iterator it = myString.cbegin(); it != myString.cend(); it++ )
    ret += (char) *it;

Obiger Code wirft eine std::length_error-exception...ABER

std::string ret; 
std::basic_string<unsigned char >::const_iterator it = myString.cbegin();
for( ; it != myString.cend(); it++ )
    ret += (char) *it;

funktioniert...

Warum?!?

Danke und mfG
Hlymur

myString.empty() == true

ist

std::string ret( myString.begin(), myString.end() );

?

Warum?!?

Kann nur ein Bug in der Implementierung sein.

Oder das ist nicht der echte Code. Ist er das? Oder nur eine vereinfachte Version?

Ein Bug würde mich wundern, Visual Studio 13 hat mich eigentlich noch nie enttäuscht

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 ^^ )

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?

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

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

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?

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.

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.

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?

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

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