AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Warum wird eine dynamisch erzeugte Matrix scheinbar automatisch freigegeben?
Thema durchsuchen
Ansicht
Themen-Optionen

Warum wird eine dynamisch erzeugte Matrix scheinbar automatisch freigegeben?

Ein Thema von Andreas13 · begonnen am 27. Mai 2022 · letzter Beitrag vom 30. Mai 2022
Antwort Antwort
Seite 2 von 2     12   
Redeemer

Registriert seit: 19. Jan 2009
Ort: Kirchlinteln (LK Verden)
1.118 Beiträge
 
Delphi 2009 Professional
 
#1

AW: Warum wird eine dynamisch erzeugte Matrix scheinbar automatisch freigegeben?

  Alt 30. Mai 2022, 09:32
Ich habe es - noch zu Zeiten von Delphi 5 so gelernt - und dies seither auch stets so gehandhabt, daß jedes mit SetLegth(My_Array, Len) erzeugte dynamische Array am Ende mit My_Array:= NIL; freigegeben werden muß.
Gilt nur für threadvar, oder? Bei threadvar muss man auch Strings leeren.
Janni
2005 PE, 2009 PA, XE2 PA
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.374 Beiträge
 
Delphi 12 Athens
 
#2

AW: Warum wird eine dynamisch erzeugte Matrix scheinbar automatisch freigegeben?

  Alt 30. Mai 2022, 11:29
Ja, ThreadVar ist ein Sonderfall, aber bei allem Anderen werden gemanagte Typen ordentlich behandelt.

Aufpassen muß man z.B. wenn man Speicher für Records, oder so, via GetMem/FreeMem und Co. holt/freigibt.
Aber New/Dispose beachten sowas.



ThreadVar:

In der Hilfe wird zwar Einiges gesagt, aber das auch nicht ganz Richtig und Vieles fehlt komplett (z.B. was man dort besser nur mit viel Vorsicht verwenden sollte, oder besser garnicht, also was man da am Ende selber Freigeben muß).
Außerdem wäre es nett, wenn hier der Compiler bereits eine Warnung für solche Typen werfen würde, denn er weiß ja welches ein gemanagter Typ ist, bzw. Pointer allgemein (wo er nicht weiß, ob es nur auf was Anderes zeigt, oder ob der Entwickler dort Selbsterstelltes reintun wird).

Bei Strings/Interfaces/Objekten/Variants/DynArrays/... würde z.B. gern ein Speicherleck entstechen, wenn der Programmierer es nicht freigibt, denn Delphi/Windows macht es nicht automatisch, beim Ende des Threads,
also wäre es besser sowas besser nicht zu verwenden.

Zitat:
Bei Zeigern und Funktionen ist diese Art der Deklaration nicht möglich. Typen, bei denen ein Schreibzugriff einen Kopiervorgang impliziert, wie lange Strings, können nicht als Thread-Variablen deklariert werden.
Das stimmt so nicht ganz -> Doch, kann man.

Die Referenzzählung ist thread-save, auch was den "Kopiervorgang" betrifft, denn erst wird referenzgezählt (beim Schreibzugriff auf Unique geändert) und dann in die "eine" eigene Referenz geschrieben.
Ganze Strings zuweisen geht ohne Probleme, was hängen könnt, wäre z.B. wenn man via PChar/Pointer drauf zugreift, bzw. einzelne Chars über den Arrayzugriff auslesen will (schreiben geht, bei LongStrings, aber nicht bei DynArrays).
Bei DynArrays gibt es leider kein Copy-on-Write, was das Ändern einzelner Felder etwas unpraktisch macht, wenn man das Array nicht vorher selber "unique" macht.
Strings mit Pointerzugriff könnte man vorher via Delphi-Referenz durchsuchenUniqueString explizit absichern, was aber beim Cast mit PChar meistens bereits automatisch gemacht wird.
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu (30. Mai 2022 um 11:34 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:01 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-2025 by Thomas Breitkreuz