| |
|
|
- Page 1 - |
|
 Jörg Sellmeyer | Das hier funktioniert. SizeOf ermittelt auch den richtigen Wert. Bei String$(B#,0) wird jedoch trotzdem immer der ganze String ausgegeben: KompilierenMarkierenSeparieren Profanhilfe
Der Befehl kann ab XProfan 10 mehrmals auf eine Bereichsvariable angewandt werden und ändert dynamisch die Dimensione des Speicherbereiches. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 30.08.2008 ▲ |
|
|
|
|
| |
|
- Page 5 - |
|
 |
Da SizeOf() auch nach einem neu dimensionieren den korrekten Wert liefert, sollte es nicht schwer sein String/Char an der Bereichsgrenze auszubremsen.
Die Bereichsgrenzen einer Bereichsvariable soll man nicht eingrenzen durch weiteres ausbremsen mit String-Überprüfung usw, dieses ist ein freier Bereich per den User. Hier möchte ich meine freiheiten haben und selber vom ersten Byte bis zum letzten Byte bestimmen. Wenn ich Speicher damit reserviere und ihn überschreite muss ich damit rechnen das das Programm abstürtz. Und wenn Windows nicht alles auf "0" gesetzt hat, muss ich dafür sorgen.
mfg peter |
|
|
| |
|
|
|
 RGH | Michael Wodrich
Da SizeOf() auch nach einem neu dimensionieren den korrekten Wert liefert, sollte es nicht schwer sein String/Char an der Bereichsgrenze auszubremsen.
Klar ist das ohne Probleme possibile. Die Frage wäre hier, ob es auch von allen so gewünscht wäre. Das scheint mir nicht so. (Wenn ich mich recht erinnere, war das früher auch mal so, wurde aber aufgrund von Userwünschen entfernt.)
Oben gab es die Frage nach der Art der Speicher-Reservierung. Ich benutze in Delphi folgende Zeile:
If Z <> NIL Then ReAllocMem(Z,ParLng) Else Z := AllocMem(ParLng);
Hierbei ist Z der Pointer auf den Speicher und ParLng die angeforderte Dimensione.
Zum "Nullen" des Bereiches nach dem ersten Dim kann man Clear verwenden.
Saluto Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 08.09.2008 ▲ |
|
|
|
|
 Frank Abbing | Welche API verbirgt sich hinter den Delphi-Funktionen? |
|
|
| |
|
|
|
 | |
|
| |
|
|
|
 Frank Abbing | Nö. Rolands AllocMem hat nur einen Parameter. Zähl einfach mal nach...  |
|
|
| |
|
|
|
 | Ähm was hab ich da abkopiert? lol!
Naja hier steht auch was: [...] 
z.B. steht dort heaph.inc und das getmem benutzt wird: "Allocate new memory on the heap".
hähphähphähp... |
|
|
| |
|
|
|
 Frank Abbing | Das ist keine API, iF. Wird eine Delphi-Funktion sein. Darum wird Roland mir auch sicher sagen, dass er nicht weiss, welche API sich dahinter verbirgt *prophezei*... |
|
|
| |
|
|
|
 | Ich meine das ist Heap-Zeugs... |
|
|
| |
|
|
| |
|
- Page 6 - |
|
|
 RGH | Aus der Aiuto von Delphi 5 (in der Aiuto zu Turbo-Delphi fehlt der Eintrag):
"AllocMem weist einen Speicherbereich der angegebenen Dimensione auf dem Heap zu. Dabei wird jedes Byte des Blocks auf Null gesetzt. Mit FreeMem kann der Puffer wieder freigegeben werden."
Also wird der Speicher beim ersten DIM doch genullt! (Sorry, das war mir entfallen.) Außerdem wird er auf dem Heap zugewiesen. Damit sollten alle Unklarheiten beseitigt sein.
Und hier noch zu ReAlllocMem:
"Diese Operation wirkt sich nicht auf den Inhalt des Speicherblocks aus. Wird der Block jedoch vergrößert, sind die neu zugewiesenen Speicherbereiche nicht definiert. Kann der Block nicht an dieser Position im Speicher reserviert werden, wird er in einen anderen Bereich auf dem Heap verschoben"
Saluto Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 08.09.2008 ▲ |
|
|
|
|
 Michael Wodrich | Dann ist freepascal also die Fundgrube in der man suchen muß. Die Heap-Häppchen Reserviererei kenne ich noch aus Turbo-Pascal.
Das sollte sich aber mit ASM gut ansteuern lassen - per Übertragungen in beide Richtungen.
Momentan hab ich dafür keine Zeit, aber es ist definitiv auf der Todo-Liste.
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 11.09.2008 ▲ |
|
|
|
|
 Frank Abbing | Ja. Danke per die Infos, Roland!  |
|
|
| |
|
|