Debugbuild läuft->bleibt im Releasebuild hängen

hi,
ich habe eigentlich noch nie ein releasebuild gemacht, deswegen habt bitte etwas nachsicht. also, mein kleines konsolenprogramm funktioniert im debugbuild einwandfrei, bleibt im releasebuild jedoch an einer stelle hängen. und zwar folgende:

void BODParser::ReadFileNames( )
{
	 fseek( m_pFile, 0, SEEK_SET );

	 //Read and save all the mesh-filenames from the nametable
	 for( std::vector< FILE_meshinfo >::iterator itMesh( m_File.begin( ) );
		  itMesh != m_File.end( );
		  ++itMesh )
	 {
		 itMesh->NameOfFile = ReadString( itMesh->FileNameOffset );
	 }

	 std::cout<<"kdfasdskf";
}

um genau zu sein; er bleibt in der schleife hängen. ich habe mit std::cout bereits geprüft, ob vielleicht ein element zu viel geloopt wird, ist jedoch alles tip top. m_File hat eine größe von 698. zum testen habe ich "++i" in die schleife gepackt und tatsächlicherweise wird auch bis zum 698. element geloopt. das problem: ist er fertig geloopt, geht's nicht weiter. das heißt: "kdfasdskf" wird nicht ausgegeben. kommentiere ich itMesh->NameOfFile = ReadString( itMesh->FileNameOffset ); allerdings aus, wird "kdfasdskf" sehr wohl ausgegeben. wer kann mir helfen? langsam kriege ich echt einen an die kappe.

"FILE_meshinfo" ist eine struktur und sieht wie folgt aus:

struct FILE_meshinfo
{
	std::string NameOfFile;
	int LogFileSize; //Size of data in .BOD-file
	int LogFileOffset; //Offset of data in .BOB-file
	int FileNameOffset; //Offset to the nametable
};

die "ReadString" funktion sieht so aus:

const std::string BODParser::ReadString( const unsigned int Offset )
{
	fseek( m_pFile, Offset, SEEK_SET );

	char c;
	std::string Return;

	do
	{
		c = fgetc( m_pFile );

		Return.push_back( c );
	}
	while( c != 0 );

	return Return;
}

wie gesagt, ich habe keine ahnung vom releasebuild, könnte mir von daher jemand erklären was hier genau weshalb nicht funktioniert?

ich danke vielmals im voraus für ratschläge, tips und lösungen! danke!

SeppJ

Dann wird c wohl nie 0 werden.

Das ist übrigens brandgefährlich, was du da treibst, mit dieser Mischung aus C und C++. Das geht nur gut, wenn man sich ganz genau auskennt und wenn man sich so gut auskennt, dann macht man es gar nicht erst :p . Gibt's einen tieferen Grund, hier mit Dateizeigern zu frickeln, anstatt einen Stream zu nehmen? Außerdem riecht ReadString verdächtig nach einem schlecht nachgemachten getline.

SeppJ schrieb:

Dann wird c wohl nie 0 werden.

Das ist übrigens brandgefährlich, was du da treibst, mit dieser Mischung aus C und C++. Das geht nur gut, wenn man sich ganz genau auskennt und wenn man sich so gut auskennt, dann macht man es gar nicht erst :p . Gibt's einen tieferen Grund, hier mit Dateizeigern zu frickeln, anstatt einen Stream zu nehmen? Außerdem riecht ReadString verdächtig nach einem schlecht nachgemachten getline.

hey seppj,
danke erstmal für deine antwort. also ich würde schon behaupten dass ich mich gut in sachen c-I/O-fileoperations auskenne. ich nutze die alten c-dateihandler gerne, da sie mir der einfachheit und übersichtlichkeitshalber gut gefallen. dass die funktion readstring nicht toll ist, ist mir bewusst, allerdings interpretiere ich daraus keine fehler, die eine zulässige ausführung des releasebuildes nicht zulassen würde?! denkst du eine umrüstung auf fgets bzw. fscanf würde das problem beheben?

danke!

SeppJ? ich will ein kind von dir!
klappt nun super, warum auch immer. toll, danke dir!

SeppJ

fscanf wäre ganz bestimmt nicht mein Tipp, aber anscheinend bist du dir nicht ganz bewusst, was der Unterschied zwischen den Rückgabewerten von fscanf und fgetc ist. Du sagtest doch, du kennst dich gut aus, mit der C-Standardbibliothek!?

Trotzdem der Tipp: Gewöhn dir das ab. Schnell. Nichts gutes wird von dieser Mischung kommen.

Oder hast du nun einfach getline genommen? Das wäre wiederum eine gute Entscheidung .

Debugbuild läuft-&gt;bleibt im Releasebuild hängen

Debugbuild läuft->bleibt im Releasebuild hängen