Exceptions in DLL's

[ChaosAngel]

hmm, das Argument mit den verschiedenen Sprachen die keine Exceptions unterstützen ist gut ... aber diese Exceptions sind halt so verdammt praktisch !!!

Wie machen das denn Spiele wie Unreal etc... die geben im Falle eines Absturzes (Exception) sogar den gesamten Stack aus ...

Gab mal nen Topic darüber hier im Board, interessiert mich net wie sie den Stack ausgegeben haben, aber meines wissens arbeiten die doch auch mit DLL's ...

[jo]

Vielleicht sind es ja garkeine echten Exceptions (nicht mit throw geworfen), aber auch wenn es welche sind, ist das bei spielen ja garkein problem, da die DLLs ja sowieso nur für das Spiel geeignet sind und für andere Programmierer nutzlos sind. Solange DLL und DLL-Benutzer mit dem selben Compiler compiliert wurden, gibt's ja keine Probleme.

[ChaosAngel]

Nunja, das ist bei mir die Engine zu einem Spiel ...
Allerdings soll die Engine danach auch noch weiter verwendet werden können

Was benutzt man denn dann anstatt Exceptions ? If -Abfragen ? Ihhh

[;)]

If-Schleifen :p

[ChaosAngel]

Gut, dann muss ich diesen Uralten Thread nochmal ausgraben ...
Schmeisst DirectX nicht auch Exceptions ??? Ich kenn mich damit nicht so gut aus, aber meiner Meinung nach basiert das doch auch auf DLL's. Und das DXSDK gibt nicht für verschiedene Compiler ...

[Christoph]

Nein. IMO schmeißt DirectX keine C++-Exceptions.

Aber dabei gibts beim Borland compiler ja auch Probleme. In der Hilfe des SDK steht was man machen muss, damit Direct3D auch mit dem Borlandcompiler funktioniert.

[ChaosAngel]

Dazu hab ich in der Hilfe doch glatt was interessantes gefunden.

What compiler do I need for DirectShow development?

Any compiler capable of generating Component Object Model (COM) objects should work once the compiler's environment has been configured correctly. If you use a compiler other than Microsoft Visual C++, you might need to rebuild the base class libraries, because of differences between compilers.

Man muss also die libs neu compilieren ?
Dazu braucht man aber doch den SoureCode oder irre ich mich da ?
Und ist es normal das man bei einem Produkt (OpenSource oder nicht) es für jeden Compiler neu compiliert ? Ich glaube doch nicht Denn dann würde das Programm das z.B. mit dem BCB entwickelt wurde nur auf BCB libs laufen, und man könnte es ohne diese nicht weitergeben...

[RenéG]

Also:

1. Exceptions sind C++ - Objekte, haben also nix mit API zu tun, weil API weiterhin reines C ist!

2. Jeder Compiler handelt Exceptions etwas anders, so dass alle Programme, die auf die DLL aufbauen, mit dem gleichen Compiler erstellt werden müssen.

3. DirectX ist COM, und COM wirft keine Exceptions im eigentlichen Sinne, sondern erstellt ein IErrorInfo-Objekt.

Fazit: Innerhalb einer DLL sollten alle von C++ erzeugten Exceptions abgefangen und durch Rückgabewerte oder/und inhaltliche Exceptionobjekte ersetzt werden!

[ChaosAngel]

Was hat denn API mit C zu tun ?!?!

Eine Api ist ein Application Programming Interface ...
Dieses kann 1. sowohl in C als auch C++ stehen und 2. auch Exceptions beinhalten ...

PS: Wird bei dem IError Objekt denn dann auch der Stack unrolled ? Ich denke doch mal nicht !
Es gibt einfach Sachen wo man eine Exception schmeissen muss !!! *heul*

[RenéG]

@ChaosAngel:

1. Da Dein Posting hier im WinAPI steht, bezog ich mich auf das WinAPI, ist das so daneben?

2. Eine Funktion, die einen Stack-Fehler verursacht, ist ganz einfach falsch programmiert. Und selbst wenn es aufgrund Stack-Speichermangels dazu kommen sollte, was nützt es, wenn Du dann folgendes lesen kannst:
0xab00cd34
0xde45gd21
.
.
.

[RenéG]

Achja, nochwas:
Wenn es so notwendig wäre, unbedingt Exceptions in DLL's schmeissen zu müssen, hätte sich COM und ActiveX bis heute nicht durchsetzen können!

[ChaosAngel]

Nun werd mal nicht gleich sauer !
1. Das ist im WinApi Forum weil es hierhin verschoben wurde. Es gibt kein anderes Forum für DLL-spezifische Fragen.

2. Hier hat keiner was von einem Stack Fehler gesagt, und ich will den Stack auch nicht auslesen ...
Exceptions haben den Vorteil das sie hinter sich aufräumen, das heist sie gehen solange rückwärts bis sie gefangen werden. Und auf dem Weg dorthin wird der Stack unrolled, also praktisch rückgängig gemacht was bis dahin passiert ist (Speichertechnisch, Destruktormässig)

Und in einem simplen Beispiel ist es nötig.

Ich schreibe eine Engine, und meine DLL exportiert dafür mehrere Klassen.

Nun hat eine Klasse zum Beispiel den op-> überladen ...

Bar* Foo::operator->()
{
return m_pbar;
}

Damit kann man von einem Foo Objekt auf sein Bar Objekt zugreifen
Falls m_pbar nun aber null ist endet so ein Zugriff immer in einer Katastrophe !

Beispiel:

class Bar
{
public:
    void blupp()
         {
            // MembervariablenAccess
         }
};
Foo a;
a.m_pbar = NULL; // aus was für Gründen auch immer
a->blupp(); // böses Aua

Und dort kann ich leider keinen Rückgabewert checken, deshalb muss ne Exception her ...

Naja, ich werd da schon nen Kompromiss finden, DLL's sind wohl einfach nichts für C++

[RenéG]

Unter COM wird direkter Zugriff auf Membervariablen untersagt. Man muss innerhalb der Memberfunktionen halt abfangen, ob der Zugriff überhaupt gültig ist.
Wenn Du DLLs programmieren willst, musst Du Dir einen anderen Programmierstil angewöhnen. Vor allem direkter Pointerzugriff, da ist es nicht mehr weit her mit Threadsynchronisation

[ChaosAngel]

ARGH
Ich programmiere nicht so !
Das mit dem Memberzugriff war doch nur dafür da um ein Beispiel zu liefern !!!

Der Pointer wird erst initialisiert wenn eine DLL geladen wird. Dies geschieht dynamisch. Deshalb sollte der User vorher nicht den op-> verwenden. Falls er dies doch tut kann ich dies nur innerhalb des -> Aufrufes abfangen, und da kann ich schlecht mit Returnwert Rückgabe arbeiten, da hilft nur eine Exception !