none
Unicode wide-char Stringkonvertierung innerhalb von catch-Blöcken RRS feed

  • Frage

  • Guten Tag zusammen!

    Folgendes Problem bei einer Anpassung tritt auf, nachdem wir eine API nun in einer wide-string Variante verwenden und endlich das gesamte Projekt auf 16bit-unicode umstellen:

    Bei Verwendung der ATL-Stringkonvertierungsmakros innerhalb einer Methode die einen try-catch-Abschnitt enthält erzeugt die Konvertierung einer Zeichenkette im catch-Block mit T2Aden Compilerfehler C3204: '_alloca' kann nicht innerhalb eines catch-Blocks aufgerufen werden, der Code basiert auf der Microsoft-Spezifischen Variante von std::exception mit einem "const char *"-Konstruktor

    Beispiel zur Veranschaulichung

    void class1::method1()
    
    {
    
    	USES_CONVERSION;
    
    	try
    
    	{
    
    		Aufruf();
    
    	}
    
    	catch (API_EXCEPTION_MIT_WSTRING_INHALT & e)
    
    	{
    
    		if (e.xy = 1)
    
    		{
    
    			throw std::exception(T2A(e.WSTRING.c_str())); // Hier gibt es ein Problem
    
    		}
    
    		else
    
    			throw std::exception("Fehler");
    
    	}
    
    }

     

    Welche Möglichkeiten gibt es:

    • mit den ATL-Makros
    • mit anderen Bordmitteln der CPP-Runtime
    • durch korrektere Verwendung (?!?)

    diese Konvertierung auszuführen.

    Es wird normales C++ mit VC9 verwendet.

    Vielen Dank

    Christian Freund

    Dienstag, 12. Januar 2010 15:19

Antworten

  • _alloca und die die entsprechenden ATL Makros durften noch nie in Exception Handlern verwendet werden. Das steht auch klar in der Doku:

    There are restrictions to explicitly calling _alloca in an exception handler (EH). EH routines that run on x86-class processors operate in their own memory frame: They perform their tasks in memory space that is not based on the current location of the stack pointer of the enclosing function. The most common implementations include Windows NT structured exception handling (SEH) and C++ catch clause expressions. Therefore, explicitly calling _alloca in any of the following scenarios results in program failure during the return to the calling EH routine:

    • Windows NT SEH exception filter expression:   __except (_alloca () )
    • Windows NT SEH final exception handler:   __finally {_alloca () }
    • C++ EH catch clause expression

    Du kannst einfach die neuen ATL Konvertierungsmakros verwendetn, die verwenden den Heap.

    throw std::exception(CT2A(e.WSTRING.c_str())); 



    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Dienstag, 12. Januar 2010 15:30
    Moderator

Alle Antworten

  • _alloca und die die entsprechenden ATL Makros durften noch nie in Exception Handlern verwendet werden. Das steht auch klar in der Doku:

    There are restrictions to explicitly calling _alloca in an exception handler (EH). EH routines that run on x86-class processors operate in their own memory frame: They perform their tasks in memory space that is not based on the current location of the stack pointer of the enclosing function. The most common implementations include Windows NT structured exception handling (SEH) and C++ catch clause expressions. Therefore, explicitly calling _alloca in any of the following scenarios results in program failure during the return to the calling EH routine:

    • Windows NT SEH exception filter expression:   __except (_alloca () )
    • Windows NT SEH final exception handler:   __finally {_alloca () }
    • C++ EH catch clause expression

    Du kannst einfach die neuen ATL Konvertierungsmakros verwendetn, die verwenden den Heap.

    throw std::exception(CT2A(e.WSTRING.c_str())); 



    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Dienstag, 12. Januar 2010 15:30
    Moderator
  • Super, vielen Dank, genau so etwas meinte ich.
    Das kompiliert. Ob es funktioniert sehe ich dann nach ca. 1500 anderen Anpassungen.
    Schönen Gruß aus Wesel
    Christian Freund
    Dienstag, 12. Januar 2010 16:26
  • Falls es jemand interessiert, damit ist auch

    USES_CONVERSION;
    obselet.
    Dienstag, 12. Januar 2010 16:29
  • Funktioniert wie beschrieben.
    Donnerstag, 21. Januar 2010 12:43