#define wird von Vs 2013 zur Laufzeit ignoriert!



  • Hallo Zusammen,

    ich habe ein echt merkwürdiges Problem:

    Mittels #define werden einige Werte festgelegt und alles kompiliert ohne Fehler! Lass ich dann das Programm laufen, so gibt es einen Absturz!

    Im Debugger werden die Token, die mittels #define zugeordnet waren als undefiniert bezeichnet! Wie geht das denn?!? Und was kann man tun?

    Ich sollte vielleicht noch erwähnen, dass ich das Projekt von VS 2005 nach VS 2013 konvertiert habe und es unter VS 2005 einwandfrei funktioniert...

    Für Eure Hilfe wäre ich sehr dankbar!

    Grüße Rainer



  • #define ist Präprozessor, ergo wundert mich nicht wenn der Debugger da nichts anzeigt.
    Aber um zu sagen wo das Problem des Crashs ist musst du schon Code zeigen.



  • #define MAX_PATH_LEN 2048
    
    // Read image -->
    fp = fopen((char *) cstrFile.GetBuffer(MAX_PATH_LEN), "rb");
    cstrFile.ReleaseBuffer();
    if (fp != 0)
    {			           
    	// Bild einlesen
    	BytesRead = fread(ImageBuffer,1,(3 * MAX_LINE_SIZE * MAX_LINE_SIZE + 100),fp);
    	fclose(fp);
    }
    // Read image <--
    
    #ifdef DEBUG_LOG
    	logFileGen.writeString("Bytes read       : ");
    	logFileGen.writeLine(BytesRead);
    	logFileGen.writeLine("");
    #endif
    

    Der crash findet bei

    logFileGen.writeLine(BytesRead)
    

    statt, da BytesRead noch nichts zugewiesen wurde. Das liegt aber daran, dass fp == 0 ist! Und das wiederum liegt an

    cstrFile.GetBuffer(MAX_PATH_LEN), "rb")
    

    ! in cstrFile ist der korrekte Pfad drin, aber da MAX_PATH_LEN undefiniert ist, kommt immer nur der erste Buchstabe von cstrFile raus und da findet er natürlich nichts...



  • Wenn "MAX_PATH_LEN" undefiniert wäre würde das Programm gar nicht erst kompilieren.
    Mach mal

    char* test = (char *) cstrFile.GetBuffer(MAX_PATH_LEN);
    

    und gib test dann aus. 😉

    Kann es sein dass "cstrFile" in Unicode vorliegt? Wäre nämlich typisch dass dann bei denem Cast auf "char*" nur ein zeichen rauskommt. 😉



  • Weiß nicht ob das der Grund ist, aber es gibt in den Tiefen des Win ein MAX_PATH von 260, möglicherweise ist deiner einfach zu lang 😃



  • C:
    char* test = (char 😉 cstrFile.GetBuffer(MAX_PATH_LEN);
    und gib test dann aus. 😉

    Es kommt tatsächlich auch hier nur der erste Buchstabe! Super Idee!

    Also vielleicht wirklich ein Unicode-Problem, dass ich so vorher (in der VS 2005 Version) nicht hatte. Gibt es eine einfache Lösung, oder muss ich eine Kovertierungsroutine schreiben und die überall einsetzen, wo das auftritt?



  • Aber selbst wenn das Problem mit den Unicode-Zeichen (16Bit zu 8Bit Konversion) gelöst wäre, bliebe noch die Frage, warum der Debugger im watch-Fenster dann etwas von undefinierten Symbolen faselt... 😕



  • Der der faselt bist du.
    Der Debugger sagt dir lediglich dass es kein Symbol namens MAX_PATH_LEN gibt.
    WEIL DAS SO IST.

    Präprozessormakros sind Textverarbeitung, den Debugger interessiert das nicht.

    Und ja, die Bugs hast du dir dadurch eingehandelt dass du das Projekt auf UNICODE umgestellt hast, und dann einfach überall nen Cast vorgeschrieben hast wo was nicht mehr compiliert hat. Wenn man nicht versteht was man tut passiert sowas halt.

    Lösung: Stell das Projekt zurück auf MBCS oder fix die ganzen Stellen die du beim "auf UNICODE Umstellen" kaputtgemacht hast.



  • Vielen Dank für die Erklärung!

    Die Umstellung hab' ich ja nur gemacht, weil VS 2013 unbedingt UNICODE habe wollte - ANSI wäre depricated...
    Für die Umstellung zurück auf Multibyte bzw. ANSI fehlen aber scheinbar 2 libraries: NAFXCW.LIB bzw. NAFXCWD.LIB für das dynamische Linken. Nur erstmal haben... Und wo müssen die beiden dann abgelegt werden, damit es funktioniert?


  • Mod

    Die brauchst Du gar nicht ablegen. Du kannst das entsprechende MBCS Paket von MS herunter laden und isntallieren!


Log in to reply