Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi GetMem -Funktion geht nicht (https://www.delphipraxis.net/18864-getmem-funktion-geht-nicht.html)

Virchov 25. Mär 2004 15:12


GetMem -Funktion geht nicht
 
Tach, Herrschaften!



Ich habe folgende 2 Zeilen im c++:

YPosArray = (int*) ( calloc(cxImage*2,sizeof(int)) );
PosArrayRect = (int*) calloc(cyImage*2,sizeof(int));


Die habe ich auf die Weise in Delphi übersetzt:
Delphi-Quellcode:
 YPosArray:= pInteger (  (GetMem(cxImage*2, SizeOf(integer)) )  );
 PosArrayRect:=pInteger(  (Getmem(cyImage*2, SizeOf(integer)) )  );

Der Compiler schreibt: "Inkopatible Typen".

Was kann falsch sein?

ps YPosArray und PosArrayRect sind vom Typ pInteger, cxImage und cyImage - integer. :wall:

d3g 25. Mär 2004 15:18

Re: GetMem -Funktion geht nicht
 
GetMem() ist eine Prozedur.

Delphi-Quellcode:
try
  GetMem(YPosArray, cxImage * 2 * SizeOf(Integer));
  Getmem(PosArrayRect, cyImage * 2 * SizeOf(Integer));
except
  on EOutOfMemory do
    ShowMessage('Out of Memory');
end;

Virchov 25. Mär 2004 15:30

Re: GetMem -Funktion geht nicht
 
Danke :coder:

shmia 25. Mär 2004 16:19

Re: GetMem -Funktion geht nicht
 
Zitat:

Zitat von d3g
Delphi-Quellcode:
try
  GetMem
  ...
except
  on EOutOfMemory do
    ShowMessage('Out of Memory');
end;

Bitte nicht so (Exception abfangen und ShowMessage aufrufen), sondern:

Delphi-Quellcode:
try
  GetMem
  ...
except
  on EOutOfMemory do
  begin
     // Sinnvolle Fehlermeldung produzieren
     E.Message := E.Message + #13#10'Anlegen der Bilddaten nicht möglich !';

     // Exception erneut auslösen, denn wir wollen ja nicht in den
     // folgenden Code rauschen, wenn kein Speicher mehr vorhanden ist
     Raise;
  end;
end;

Luckie 25. Mär 2004 20:05

Re: GetMem -Funktion geht nicht
 
Wo ist da der Unterschied? Ich würde sogar einen try-fianlly Block drumlegen, um die Ressourcen auf alle Fälle wieder frei zu geben.

shmia 26. Mär 2004 09:51

Re: GetMem -Funktion geht nicht
 
Eine Exception abzufangen und per ShowMessage anzuzeigen macht
fast nie einen Sinn.

1. Problem:
die eigentliche Fehlermeldung (und die Exception-Klasse) wird verschluckt, obwohl diese
nützliche Informationen liefern könnte.

2. Problem
Der folgende Programmcode wird weiter ausgeführt, obwohl ja ein Fehler
vorliegt. Ein Aufruf von Exit würde das Problem nur in die aufrufende
Funktion verlagern.

3. Problem
Sollte die Exception in einer Schleife austreten und per ShowMessage
ausgegeben werden, dann müsste man das Programm mit dem Taskmanager
abschiesen, denn niemand hat Lust, 200 Fehlermeldungen hintereinander mit
Return zu bestätigen.

4. Problem
Bei grösseren Anwendungen wird die Exception auf Applicationsebene abgefangen
(mit Application.OnException) und die Exception in einer Log-Datei gespeichert.
Manchmal wird dem Benutzer angeboten die Exception-Daten automatisch per EMail
nach Hause zu schicken.
Würde die Exception abgefangen und per ShowMessage angezeigt würde dieser
Mechanismus ausgehebelt.

Meine goldene Regel zu Exceptions wäre:
"Niemals Exceptions anfangen und per ShowMessage anzeigen sondern
abfangen, mit Informationen anreichern und erneut auslösen"

Delphi-Quellcode:
   // Beispiel
   for i := 0 to 10000 do
   begin
   try
      MachWas(i);
   except
      on E:Exception do
      begin
         // mit nützlichen Informationen anreichern
         E.Message := E.Message +#13#10+Format('Fehler bei MachWas(%d)',[i]);
         // Exception erneut auslösen
         raise;
      end;
   end;
   end;

Es gibt nur eine Ausnahme:
Programmcode, der von Aussen über eine Automatisierungsschnittstelle
aufgerufen wird, muss spezielle Vorkehrungen treffen und darf
auch ShowMessage zu Anzeigen benutzen, falls der Client die Exception
nicht anzeigen kann.


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:44 Uhr.

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 by Thomas Breitkreuz