Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Accessviolation in Klassen-Prozedur (https://www.delphipraxis.net/49998-accessviolation-klassen-prozedur.html)

barf00s 19. Jul 2005 15:26

Re: Accessviolation in Klassen-Prozedur
 
es kann ja sein das er in einer späteren version seines programmes IRGENDeinen vergleich braucht, um fehler zu vermeiden - und - ich habe im implementation teil einfach die parameter weggelassen weil ich zu faul zum tippsen war -

[edit]
Zitat:

stimmt nicht so ganz - standardmäßig entspricht ein Real einem Double, d.h. du kannst ruhig Real verwenden, damit kommt die FPU von sich aus schon klar. du meisnt wahrscheinlich den alten TurboPascal-Real mit 48Bit und einem Borland-eigenen format, mit dem die FPU so nicht klarkommt und der erst umgewandelt werden muss (was natürlich zeit kostet). den gibt es unter delphi (aus welchen grunden auch immer) noch immer, er heisst Real48.
real entspricht nicht einem double, sondern einem single, und real ist tatsächlich aus kompatiblitätsgrundn noch in delphi implementiert/vorhanden

[/edit

BlackJack 19. Jul 2005 15:31

Re: Accessviolation in Klassen-Prozedur
 
Zitat:

Zitat von barf00s
und - ich habe im implementation teil einfach die parameter weggelassen weil ich zu faul zum tippsen war -

das hatte ich schon erkannt ;)

aber so eine property wie ich sie gepostet habe (die also per read und write direkt mit einer variablen verbunden ist) macht doch aber tatsächlich keinen sinn, oder?

Zitat:

Zitat von barf00s
real entspricht nicht einem double, sondern einem single, und real ist tatsächlich aus kompatiblitätsgrundn noch in delphi implementiert/vorhanden

oha, man lehrnt nie aus, ich dachte immer ein Real wäre ein double. naja aber ich sehe trotzdem keinen grund nicht weiter mit Real zu arbeiten (obwohl ich auch lieber single oder double benutze).

knusprig 19. Jul 2005 17:24

Re: Accessviolation in Klassen-Prozedur
 
Also ich übergeb jetzt die Werte in die procedure. Die sieht jetzt so aus:

Delphi-Quellcode:
procedure TSchieber.DrawLine(Canvas: TCanvas; a,l,r: double);
begin
  //Berechnung der Strecken
  b := sqrt(sqr(l)-sqr(a));

  //Berechnung der Koordinaten
  canvas.MoveTo(center.x, center.y + b);
  canvas.LineTo(center.x + a, center.y);

end;
Jetzt hab ich zum einen noch das Problem dass die Werte a und b Integer sein müssen. Sollte ich vielleich runden?!? Aber nun hab ich das Problem "Ungültige Gleitkommaoperation in der Zeile wo b berechnet wird....
:(

Robert_G 19. Jul 2005 17:45

Re: Accessviolation in Klassen-Prozedur
 
Zitat:

Zitat von BlackJack
aber so eine property wie ich sie gepostet habe (die also per read und write direkt mit einer variablen verbunden ist) macht doch aber tatsächlich keinen sinn, oder?

Doch, sie abstrahiert die Felder der Klasse und gibt dir somit die Möglichkeit später zum Bleistift einen setter dazwischenzuschieben, der meinetwegen einen Event auslösen oder auch andere Felder invalidieren kann. ;)
btw: Selbst eine Property, die per "read fFeld" deklariert ist, sollte im Code auch nur als Property und nicht als Feld verwendet werden. Es sollte dadurch keine Performanceprobleme geben und du hast wieder die Verwendung soweit vom Feld getrennt, das spätere Änderungen in einem Getter möglich sind...
Ist es eine readonly Property muss man natürlich das Feld zum Schreiben nehmen. ;)

Außerdem könnte man die Property in den published Teil schieben, wenn man das Delphi streaming system bzw. RTTI verwenden will. ;)

kurz gesagt: Barfoos hat das schon ganz richtig gemacht. Und es sieht hübscher aus... :mrgreen:

marabu 19. Jul 2005 17:57

Re: Accessviolation in Klassen-Prozedur
 
Zitat:

Zitat von knusprig
Aber nun hab ich das Problem "Ungültige Gleitkommaoperation in der Zeile wo b berechnet wird.

Sqrt() ist nur für nicht-negative Werte definiert - wo ist deine Prüfabfrage?

Grüße vom marabu

PS: Berechnung einer Strecke? Sqrt(Abs(...))

knusprig 19. Jul 2005 18:02

Re: Accessviolation in Klassen-Prozedur
 
Zitat:

Zitat von marabu
Zitat:

Zitat von knusprig
Aber nun hab ich das Problem "Ungültige Gleitkommaoperation in der Zeile wo b berechnet wird.

PS: Berechnung einer Strecke? Sqrt(Abs(...))

Vielen Dank. Damit erscheint schonmal keine Fehlermeldung mehr :) Wieder ein Schritt weiter. Vielleicht bekomm ich das ja doch noch gebacken :)

BlackJack 19. Jul 2005 19:01

Re: Accessviolation in Klassen-Prozedur
 
Zitat:

Zitat von Robert_G
Zitat:

Zitat von BlackJack
aber so eine property wie ich sie gepostet habe (die also per read und write direkt mit einer variablen verbunden ist) macht doch aber tatsächlich keinen sinn, oder?

Doch, sie abstrahiert die Felder der Klasse und gibt dir somit die Möglichkeit später zum Bleistift einen setter dazwischenzuschieben, der meinetwegen einen Event auslösen oder auch andere Felder invalidieren kann. ;)

ok, an abgeleitete kalssen habe ich nicht gedacht, da macht das natürlich sinn.

Zitat:

Zitat von Robert_G
btw: Selbst eine Property, die per "read fFeld" deklariert ist, sollte im Code auch nur als Property und nicht als Feld verwendet werden. Es sollte dadurch keine Performanceprobleme geben[...]

erzeugt delphi da echt keinen overhead und handelt eine "read fFeld write fFeld"-Property dann intern (also nachher in der binary) wie einen direkten zugriff auf die vairable fFeld? dann sollte ich mir das mal überlegen tatsächlich immer mit propertys zu arbeiten, mich hat da immer der (vermeintliche?) overhead und die damit zusammenhängenden geschwindigkeitsverluste abgeschreckt, da ich oft relativ zeitkritische programme schreibe.

p.s.: [OT] ist das normal dass beim Firefox im eingabefeld (also da wo ich jetzt gerade tippe) der cursor so "laggt"? das nervt allmählich wie sau! :kotz:


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:07 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz