Gültigkeit von Zeigern überprüfen

[SBond]

Hallo Leute,

habe schon wieder ein Anliegen...
Wie kann ich am besten überprüfen, ob ein Pointer gültig ist? Gibt es native Funktionen (sowas wie isPointer() oder isValid()...)?
In MSDN habe ich zumindest eine API gefunden (IsBadCodePtr_), allerdings gilt diese als veraltet.

viele Grüße,
SBond

[STARGÅTE]

Welche Gültigkeit willst du denn da überprüfen?
Beispiel: Nur weil der Speicher von einem Bild gültig ist, heißt es ja noch lange nicht, dass auch das Bild selbst noch gültig ist.

Viele Zeiger stammen ja garnicht von irgendwelchen Initialisierungen, sonden sind wirklich nur Zeiger zu Listen-Elementen, Array-Felder, String-Position, ...
Die Art des Ziels steht aber nicht im Zeiger drin, somit kann auch deren Gültigkeit (ist das Array noch groß genug, existiert das List-Element, ist der String noch da) nicht überprüft werden.

Für Speicher die mit AllocateMemory erstellt wurden, aknnst du vllt diese Funktion hier nutzen:
http://www.purebasic.fr/english/viewtop ... =3&t=60264

[GronkhLP]

Das scheint für dich nützlich zu sein: http://www.purebasic.fr/german/viewtopic.php?p=247636

[ts-soft]

Nein!

Die API ist unzuverlässig und es gibt keine Möglichkeit einen gültigen Pointer zu überprüfen.
Es liegt also an Dir, nur Pointer zu nutzen, wo Du sicher bist, das diese Existieren. Aber dies
stellt ja im normalfall kein Problem dar.

Gruß
Thomas

[SBond]

ah.. ok danke

Nun ich bin gerade dabei meinen Quellcode robuster zu gestalten um eventuelle Abstürze vorzubeugen. Ich nutzte unter anderem Prototypes, also Funktionszeiger. Ich weiß nicht wie groß die Wahrscheinlichkeit ist, das so ein Zeiger ungültig wird. Bisher habe ich nur überprüft, ob ein Pointer ungleich Null ist.

Wahrscheinlich mach ich mich auch nur verrückt

[STARGÅTE]

Aber wenn du weißt das ein Pointer zu einer Funktion ungültig geworden ist (wie auch immer), dann kannst du ja die Funktion eh nicht mehr aufrufen und damit musst du dein Programm eh abrupt beenden (= kontrollierter Absturz).

Was wichtig wäre, ist ein vernünftiges OnError-Management, damit du weiß warum das Programm abgestürtzt ist und nicht im dunklen stehst.

[SBond]

öhhh...

in der Tat habe ich vor einigen Tagen das erste mal diese OnError-Funktion eingebunden. Sie ist wirklich hilfreich zumal immer wieder Fehler auftreten, die man beim Programmieren vergessen hat. Bei mir ist es oft die Division durch Null, die ich vergesse abzusichern. OnError ist da eine große Hilfe, den Fehler zu finden. Aber was genau meinst du mit "vernünftiges OnError-Management"? habe bis jetzt nur die Ausgabe der Datei und Zeilennummer. Mit den Assembler-Ausgaben kann ich gar nichts anfangen.

[edel]

In den pbosl gibt es noch eine Try&Catch Lib, funktioniert unter 32 bit sehr gut.

[hjbremer]

nun es schon eine Möglichkeit, ist zwar nur eine Krücke, funktioniert aber recht gut

Code: Alles auswählen

  If OpenWindow(0, 0, 0, 270, 160, "TextGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
     
     TextGadget(0, 10,  10, 250, 20, "TextGadget Standard (Left)")
     
     pointer = 1133
     
    If SendMessage_(GadgetID(0), #WM_SETTEXT, 0, pointer) = 0
       
       Debug "huh, bad pointer" 
       
       
    EndIf
        
    Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
  EndIf

Gründe um so etwas zu nutzen gibt es viele

z.B. wenn man als Argument für eine Procedure, wahlweise eine Zahl oder einen String übergeben will und diese Daten aus einer externen Datei holen will.

Mit folgendem Macro läßt sich dies bewerkstelligen:

Code: Alles auswählen

Macro InputField_SetAttribut(pbnr, attribut, wert1, wert2 = 0)
      
      CompilerSelect attribut
         CompilerCase #InputField_Infotext
            InputField_SetAttribute(pbnr, attribut, @wert1, wert2)
            
         CompilerDefault
            InputField_SetAttribute(pbnr, attribut, wert1, wert2)
            
      CompilerEndSelect
   
   EndMacro

[funker]

In den pbosl gibt es noch eine Try&Catch Lib, funktioniert unter 32 bit sehr gut.

Unter 64 Bit nich? Schlecht!