Intel Compiler Exceptionhandling Problem
-
Hallo zusammen, ich habe zur Zeit ein Problem, das für mich grade unmöglich zu finden ist:
a) In der Eingangsfunktion eines unserer Submodule steht aktuell etwa folgender Code:
#include "message.h" void entryFunction() { try { /* logik... */ } catch (myException& me) { /* ... */ } catch (std::exception const& se) { /* ... */ } catch (...) { /* (X) */ } }b) die message.h enthält grob folgendes:
struct myException : std::exception { /* ... */} void createErrorMessage(/* ... */) { /* ... */ throw myException(); }Irgendwo in der Logik des try-Blocks (ein paar Funktionsaufrufe tiefer) wird createErrorMessage aufgerufen. Auf diversen Plattformen funktioniert das alles bestens (d.h. der catch-Block für myException wird betreten), außer mit dem intel Compiler (icpc version 12.1.2 (gcc version 4.3.0 compatibility)) unter Linux im Release-Modus (Flags: -m32 -mfpmath=sse -msse2 -pthread -g -03 -fPIC), dort scheint die Runtime zu "vergessen", welchen Typ die Exception hat und landet im catch-all.
Kommt das jemandem bekannt vor, weiß jemand woran das liegen könnte? Google hat mir bisher nicht wirklich weiter geholfen...
-
Hallo pumuckl,
könnte es sein, daß es an der funktionslokalen Struktur liegt? Kannst ja mal testweise das #include vor die Funktion packen.
-
Ich wusste gar nicht, das man Funktionen innerhalb von Funktionen definieren kann?
-
Stimmt, hatte ich gar nicht gesehen.
pumuckl, irgendetwas stimmt an deinem gezeigten Code nicht

-
Sorry, habs korrigiert, der #include kommt natürlich vorher...
-
Vlt liegt es daran, das myException() ein temporäres Objekt erzeugt, und temporäre Objekte können nur an const Referenzen gebunden werden? Du kannst ja mal testen, was passiert wenn du myException& me in myException const& me umänderst.
-
pyhax schrieb:
Vlt liegt es daran, das myException() ein temporäres Objekt erzeugt, und temporäre Objekte können nur an const Referenzen gebunden werden? Du kannst ja mal testen, was passiert wenn du myException& me in myException const& me umänderst.
Leider nein, keine Änderung dadurch.