SJLJ y SEH son dos sistemas de manejo de excepciones diferentes.

Para las diferencias específicas, los recursos que ya has visto cubren todo.

Sin embargo, en cuanto a cuál es mejor instalar, vaya con SJLJ a menos que sepa que necesita SEH.

Actualización de 2019: en los sistemas modernos, no hay razón para usar SJLJ, por lo que probablemente debería invertirse el consejo anterior. SEH es más común ahora. Sin embargo, en última instancia, realmente no importa, ya que es fácil cambiar entre los dos.

SJLJ

SJLJ es más compatible con todas las arquitecturas y es más sólido. Además, las excepciones SJLJ se pueden lanzar a través de bibliotecas que usan otros sistemas de manejo de excepciones, incluidas las bibliotecas C. Sin embargo, tiene una penalización de rendimiento.

SEH

SEH es mucho más eficiente (sin penalización de rendimiento), pero desafortunadamente no cuenta con un buen soporte. Las excepciones de SEH harán que sucedan cosas malas cuando se lanzan a través de bibliotecas que no usan SEH.

En lo que respecta a su código, no hay diferencias reales. Siempre puede cambiar de compilador más adelante si lo necesita.

Descubrí una diferencia entre el manejo de excepciones SJLJ y SEH en MinGW-w64: los controladores de señales C establecidos por la función signal() no funcionan en la versión SJLJ tan pronto como se ejecuta al menos un bloque try{} en el tiempo de ejecución. Dado que este problema no parece estar descrito en ninguna parte, lo pongo aquí para que conste.

El siguiente ejemplo (test_signals.cpp) demuestra esto.

 // This sample demonstrates how try {} block disables handler set by signal() // on MinGW-w64 with GCC SJLJ build #include <signal.h> #include <iostream> int izero = 0; static void SIGWntHandler (int signum)//sub_code) { std::cout << "In signal handler, signum = " << signum << std::endl; std::cout << "Now exiting..." << std::endl; std::exit(1); } int main (void) { std::cout << "Entered main(), arming signal handler..." << std::endl; if (signal (SIGSEGV, (void(*)(int))SIGWntHandler) == SIG_ERR) std::cout << "signal(OSD::SetSignal) error\n"; if (signal (SIGFPE, (void(*)(int))SIGWntHandler) == SIG_ERR) std::cout << "signal(OSD::SetSignal) error\n"; if (signal (SIGILL, (void(*)(int))SIGWntHandler) == SIG_ERR) std::cout << "signal(OSD::SetSignal) error\n"; // this try block disables signal handler... try { std::cout << "In try block" << std::endl; } catch(char*) {} std::cout << "Doing bad things to cause signal..." << std::endl; izero = 1 / izero; // cause integer division by zero char* ptrnull = 0; ptrnull[0] = '\0'; // cause access violation std::cout << "We are too lucky..." << std::endl; return 0; }

Construye con:

 g++ test_signals.cpp -o test_signals.exe

La salida esperada es:

 Entered main(), arming signal handler... In try block Doing bad things to cause signal... In signal handler, signum = 8 Now exiting...

El resultado real cuando construyo con la variante MigGW-w64 SJLJ es:

 Entered main(), arming signal handler... In try block Doing bad things to cause signal...

La aplicación se termina silenciosamente después de un retraso. Es decir, no se llama al manejador de señales. Si el bloque try{} está comentado, el controlador de señal se llama correctamente.

Cuando se usa la variante MinGW-w64 SEH, se comporta como se esperaba (se llama al controlador de señal).

No tengo una idea clara de por qué ocurre este problema, por lo que agradecería si alguien puede dar una explicación.