PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Exceptions in C++?



SegFault II.
02-03-2002, 11:48
Hallo!
Hat hier jemand Erfahrung mit Exceptions in C++?
Ich habe nämlich folgendes Problem:

In einer (selbstgeschriebenen) Bibliothek habe ich
eine Struktur oSDL_Error:

struct oSDL_Error{
oSDL_ErrorType type; // enum oSDL_ErrorType {...}
std::string error;
void* details;
oSDL_Error(oSDL_ErrorType t, std::string e, void* d){
type = t;
error = e;
details = d;
}
};

In der Bibliothek verwende ich diese Struktur zum Erkennen
und Umschiffen von Fehlern.
Zum Beispiel wird bei einem Druck auf Esc dies aufgerufen:
// anderer Code
throw(oSDL_Error(OSDL_QUIT, "oSDL_Keyboard::pressed(SDLKey): Key 'Esc' pressed", 0));

An anderer Stelle hab ich dann
try{
// irgendwas
}
catch(oSDL_Error error){
// mach was
}
stehen.

Wenn ich jetzt ein Programm, das ich in der Entwicklungsumgebung(KDevelop)
zusammen mit der Bibliothek schreibe aufrufe, gibt es keinerlei Probleme damit.
Aber wenn ich irgendein Programm (auch das, aus der Entwicklungsumgebung) außerhalb
des oSDL-Projekts compiliere und gegen die Bibliothek linke, gibt es immer einen
Speicherzugriffsfehler, wenn der Fehler "geworfen" wird.
Beim debuggen stellte ich bereits fest, das dies nach dem Zuweisen der Daten zu der
Struktur geschieht.
Also wird die oSDL_Error(oSDL_ErrorType, std::string, void*)-Funktion fehlerfrei
durchlaufen.
Aber in dem daruffolgenden Schritt, die neu geschaffene Struktur zu "werfen" gibt es
den Speicherzugriffsfehler und das Programm, das gegen die Bibliothek gelinkt ist,
stürzt ab.

Der Fehler tritt leider nicht nur bei der Überprüfung auf Esc auf, sondern an jeder
beliebigen Stelle, bei jedem bisher getesteten Parametern.
Ich habe dies unter Linux (Gcc 2.95.3) und Windows (Borland C++-Builder 4) getestet.
Bei beiden Compilern/Systemen tritt der selbe Fehler auf.

Kann mir jemand verraten, wo das Problem liegt?
Mach ich was falsch beim "Werfen"?

anda_skoa
02-03-2002, 16:12
Hmm sieht IMHO völlig richtig aus.

Ist vielleicht die selbe Ursache, die das Problem mit den überladeden Methoden verursacht, dass du in deinem anderen Posting beschreibst.

Vielleicht liegt es an der Art wie du die Bibliothek erzeugst.

Ich hab mal in einem KDE Projekt nachgesehen, dass ein Plugin enthält.
Die Sourcen des Plugins werden mit -fPIC -DPIC kompiliert.

Ciao,
_

SegFault II.
02-03-2002, 20:04
Danke für den Tipp.
Jedoch wirft er noch mehr fragen auf ;-)

Wenn ich jetzt das Programm, das ich im selben Projekt wie die Bibliothek geschrieben habe außerhalb des Projekts compiliere, klappt es alles tadellos.
Aber wenn ich ein anderen Programm erneut gegen die Bibliothek (diesmal mit -fPIC -DPIC compiliert) linke, tritt noch immer der selbe Fehler auf.
Außerdem kann ich seit die beiden Parameter hinzugekommen sind zwar Methoden in Kindklassen überladen (ohne dass der linker sich beschwert), aber leider sind die aufgerufenen Funktionen noch immer die selben wie in der Ursprungsklasse.

anda_skoa
03-03-2002, 12:10
Hmm, ich kenn micht da auch nicht so gut aus, ich arbeite immer mit Makefiles, die von autoconf und automake erzeugt wurden und außerdem libtool verwenden.

Ich kann dir mal den Output einer Kompiliation und eines Linkvorgangs posten:
c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib -I/usr/include/kde -I/usr/include/qt -I/usr/X11R6/include -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wbad-function-cast -Wcast-align -Wundef -Wconversion -fno-builtin -Wnon-virtual-dtor -Wno-long-long -g -O2 -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -fno-exceptions -fno-check-new -Wp,-MD,.deps/cmapzone.pp -c cmapzone.cpp
-fPIC -DPIC -o .libs/cmapzone.o

c++ -shared -nostdlib /usr/lib/crti.o /usr/lib/gcc-lib/i386-linux/2.95.4/crtbeginS.o .libs/cmapstandardfactory.o .libs/cmappluginstandard.o .libs/cmappluginstandard.moc.o .libs/libkmudmapper_standard_la_meta_unload.o -Wl,--whole-archive ./tools/.libs/libstandard_tools.a ./views/.libs/libstandard_views.a ./propertyPanes/.libs/libstandard_propertypanes.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/usr/lib -Wl,--rpath -Wl,/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/lib /usr/lib/libkfile.so -L/usr/lib/gcc-lib/i386-linux/2.95.4 /usr/lib/libkparts.so ../../.libs/libkmudmapper.so -L/home/kevin/kmuddevel/kmud2/lib/.libs ./tools/.libs/libstandard_tools.a ./views/.libs/libstandard_views.a ./propertyPanes/.libs/libstandard_propertypanes.a -lstdc++ -lm -lc -lgcc /usr/lib/gcc-lib/i386-linux/2.95.4/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libkmudmapper_standard.so -o .libs/libkmudmapper_standard.so

Allerdings werden dann noch die .la versionen der libs irgendwie erzeugt, was im make output nur mit einem
creating libkmudmapper_standard.la
angegeben wird.

Vielleicht kommst du damit weiter.
Muß ja auch irgendwo ein HOWTO für Bibliotheken geben.

Ciao,
_