Linkage C, C++ et try - Page 1

J'ai un petit problème. La source 1:

#include <iostream>

using namespace std;

class my_error {
  int e;
public:
  my_error (int le) {
    e = le;
  }

  void print ()
  { cout << "ERROR : " << e << endl; }

};

extern "C" void error_throw (int e);

extern "C" void cplusplus_error_handler (int e)
{
  throw my_error (e);
}

int main ()
{
  cout << "TRY1\n";
  try {
    throw my_error (2);
  } catch (my_error error) {
    error.print ();
  }

  cout << "TRY2\n";
  try {
    cplusplus_error_handler (2);
  } catch (my_error error) {
    error.print ();
  }

  cout << "TRY3\n";
  try {
    error_throw (2);
  } catch (my_error error) {
    error.print ();
  }
  return 0;
}

Compilé avec : g++ t1.cc -Wall -W -pedantic -ansi -c
sans warning.

La source 2:

extern void  cplusplus_error_handler (int e);

void error_throw (int e)
{
  cplusplus_error_handler (e);
}

Compilé avec : gcc t2.c -Wall -W -pedantic -ansi -c
sans warning.

Mon troisième lié avec : g++ t1.o t2.o

Et mon tout est un a.out qui exécuté donne :
TRY1
ERROR : 2
TRY2
ERROR : 2
TRY3
terminate called after throwing an instance of 'my_error'
Aborted

Question: pourquoi le TRY3 échoue ? Je ne comprends pas !
(GCC et G++ 4.0.2)

tu crois qu'on a le droit de lancer des exceptions à partir de code C ou ASM ? c'est pas sûr que ça soit possible, surtout qu'il doit être un peu perdu sans son stack frame...

Tu dois compiler ton code C avec -fexceptions pour que ça fonctionne. (C'est pour ça qu'il y a -fexceptions dans les $RPM_OPT_FLAGS utilisés pour compiler (presque) tous les paquetages Fedora, d'ailleurs.)

./2: Je lance les exceptions à partir du C++. Mais via une fonction C++ appelée depuis une fonctions C.
./3: C'est çà ca marche. Merci.

Je me demande si ce genre de code ne marcherait pas directement sous MinGW :
MinGW est sûrement obligé d'implémenter le Structured Exception Handling de Windows, et comme les exceptions C++ reposent dessus...

Non, MinGW n'implémente pas (directement) le SEH, ils utilisent au choix setjmp et longjmp (SJLJ) ou DWARF 2. Le DWARF 2 est plus rapide, mais il ne croise pas les DLLs qui n'ont pas d'informations pour défaire la pile (unwinding) au format DWARF 2. SJLJ peut croiser les DLLs parce que l'implémentation de setjmp de MSVCRT.DLL utilise le SEH en interne.