Rundungs-Probleme bei Ausgabe als String

[Fritzew]

Also wenn es sogar im Header der Dll so vermerkt ist, solltest Du meiner Meinung nach bei Aufrufen in die Dll so verfahren:

// Nur so hingetipt Pseudo Code

Delphi-Quellcode:

Procedure callToDll ;
begin
  Set8087CW(DllCW);  // DllCw = CtrlWord das die Dll erwartet
  CallToDll;
  Set8087CW(MYCW); // Das was Du erwartest
end;

Einfach um sicher zu gehen das die Dll auch sauber arbeitet und davon ausgeht das immer "Ihr" Wert gesetzt ist

[raller09]

Zitat von Fritzew:

Also wenn es sogar im Header der Dll so vermerkt ist, solltest Du meiner Meinung nach bei Aufrufen in die Dll so verfahren:

// Nur so hingetipt Pseudo Code

Delphi-Quellcode:

Procedure callToDll ;
begin
  Set8087CW(DllCW);  // DllCw = CtrlWord das die Dll erwartet
  CallToDll;
  Set8087CW(MYCW); // Das was Du erwartest
end;

Einfach um sicher zu gehen das die Dll auch sauber arbeitet und davon ausgeht das immer "Ihr" Wert gesetzt ist

genau das mache ich jetzt ja auch. Ich benutze nur nicht den "dokumentierten" Wert. Sondern den, der sich bei meinen Versuchen als "gleich" gezeigt hat. Dokumentation ist schon etwas älter, da ist mittlerweile auch der Compiler der .dll gewechselt worden...

Danke,

[Luckie]

Ach das steht so in der Doku der DLL? Was macht die um Gottes Willen für komische Sachen.

[freimatz]

wäre da nicht auch noch ein try finally sinnvoll

[Fritzew]

Zitat von freimatz:

wäre da nicht auch noch ein try finally sinnvoll

Nee.....
Wenn eine Exception in der Dll auftritt hast Du ganz andere Probleme
da kannst Du Dir das finally echt sparen. Exceptions aus anderen Compilern und oder Sprachen sind eh nicht kompatibel zu Delphi.

Zitat von Luckie:

Ach das steht so in der Doku der DLL? Was macht die um Gottes Willen für komische Sachen.

Für das ist das FPU Controlword ja da. Bei gemixten Application/Dll muss man dann schon dafür sorgen das alle glücklich sind.
Da es in dieser speziellen Dll ja sogar dokumentiert ist, einfach daran halten.

[Zacherl]

Zitat von Fritzew:

Zitat von freimatz:

wäre da nicht auch noch ein try finally sinnvoll

Nee.....
Wenn eine Exception in der Dll auftritt hast Du ganz andere Probleme
da kannst Du Dir das finally echt sparen. Exceptions aus anderen Compilern und oder Sprachen sind eh nicht kompatibel zu Delphi.

Delphi benutzt SEH zum Fangen von Exceptions. Das heißt, dass sämtliche CPU Exceptions grundsätzlich gefangen werden können; auch dann, wenn sie in einer fremden DLL auftreten. Ob man den State daraus dann noch sinnvoll recovern kann, ist allerdings fragwürdig. Höher-Sprachige Exceptions sind in vielen Fällen auch damit behandelbar. C++ Exceptions z.b. erzeugen am Ende tatsächlich auch eine spezielle CPU Exception. Delphi wird zwar den Typ nicht mehr differenzieren können, aber die Exception ansich bekommst du mit.

[Fritzew]

Zitat von Zacherl:

Delphi benutzt SEH zum Fangen von Exceptions. Das heißt, dass sämtliche CPU Exceptions grundsätzlich gefangen werden können; auch dann, wenn sie in einer fremden DLL auftreten. Ob man den State daraus dann noch sinnvoll recovern kann, ist allerdings fragwürdig. Höher-Sprachige Exceptions sind in vielen Fällen auch damit behandelbar. C++ Exceptions z.b. erzeugen am Ende tatsächlich auch eine spezielle CPU Exception. Delphi wird zwar den Typ nicht mehr differenzieren können, aber die Exception ansich bekommst du mit.

Das ist aber im Regelfall das letzte was Du mitbekommst, stabil ist was anderes.

[Zacherl]

Zitat von Fritzew:

Zitat von Zacherl:

Delphi benutzt SEH zum Fangen von Exceptions. Das heißt, dass sämtliche CPU Exceptions grundsätzlich gefangen werden können; auch dann, wenn sie in einer fremden DLL auftreten. Ob man den State daraus dann noch sinnvoll recovern kann, ist allerdings fragwürdig. Höher-Sprachige Exceptions sind in vielen Fällen auch damit behandelbar. C++ Exceptions z.b. erzeugen am Ende tatsächlich auch eine spezielle CPU Exception. Delphi wird zwar den Typ nicht mehr differenzieren können, aber die Exception ansich bekommst du mit.

Das ist aber im Regelfall das letzte was Du mitbekommst, stabil ist was anderes.

Ja, das stimmt schon. Wenn die Exception in der Dll nicht selbstständig behandelt wird, kann man das Programm im Grunde auch direkt crashen lassen, da man sehr wahrscheinlich keinen validen Zustand mehr herstellen kann.