XProfan

- Página 2 -

Was ha una NullByte con el Redimensionierung a tun?

Ein Imprimir String$(B#,0) es absolut no aussagekräftig como lo hier a a una NullByte liesst.

Wenn uno en un Zona una Null-Byte benötigt, porque una Función como cadena$ a hay hin liesst, entonces debería al NULL-Byte conjunto.

Oder kappier Yo sólo algo no?

Jörg
Sellmeyer

Wenn Profano una Zona dimensioniert, liest String$(...) el siempre a a korrekt eingestellten Größe des Bereichs de. Das macht lo pero no mehr, si la Zona neu dimensioniert wurde. Das ha nix así a tun, si Yo una NullByte necesidad, como el Abschlußbyte sí sonst auch de Profano gesetzt se.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Jörg Sellmeyer

Wenn Profano una Zona dimensioniert, liest String$(...) el siempre a a korrekt eingestellten Größe des Bereichs de.

Wird no hauptsächlich a a una Byte 0 gelesen?

RGH

String$ liest a para ersten Byte(0), Char$ el angegebene Anzahl Signo.

Saludo
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

Jörg
Sellmeyer

Irgendwie drehen nosotros ahora en el Kreis, oder? Natürlich se a para ersten NullByte gelesen. Wenn dimensioniert se, se esta Byte aber automáticamente a el letzte Punto gesetzt. ¿Por qué debería Dim en el el zweiten Anwendung anders hacer. außerdem ha String$(...) así Zugriff en Speicher, el ya no mehr para Programa gehört. Das debería meiner Meinung no ser. Nach el zweiten Dim Es el Función String$ praktisch nutzlos.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Frank
Abbing

Jörg ha lo genauso dijo como es. Das zweite String$ liest de unerlaubtem Speicher. El Redimensionierung es en dieser Form fehlerhaft.

Lo va also sólo por lo tanto, en uno Vergrößerung des Speicherbereiches, el angehangenen Teil con Null a füllen?

Jörg
Sellmeyer

Nein!!! Lo va por lo tanto, en uno Verkleinerung una Nullbyte einzufügen:
Ein Zona se deklariert:
Kompilieren Marca Separación

Declare Bereich#

Dann se él dimensioniert:
Kompilieren Marca Separación

Dim Bereich#,10

Dann sieht Zona después de mi Verständnis así de:

0|0|0|0|0|0|0|0|0|z

Wobei 0 auch beliebige Daten ser puede, el gerade a el Punto en el Speicher posición. Es sí no con Claro Zona gelöscht.
Jetzt escribir Yo qué rein:
Kompilieren Marca Separación

String Bereich#,0 = "123456789"

Jetzt müßte Zona así aussehen:

1|2|3|4|5|6|7|8|9|z

jetz neu dimensionieren:
Kompilieren Marca Separación

Dim Bereich#,6

Um korrekt a trabajo müßte Zona ahora así aussehen:

1|2|3|4|5|z

el Speicher detrás de esto es ahora abgetrennt - el gesamte Zona Ahora debe así aussehen:

1|2|3|4|5|z7|8|9|z

Profano ha also weder por Char$ - en el Überschreiten el Speichergrenze meckert - todavía por String$ Zugriff en el Speicher hinter Zona.

Der gesamte Speicherbereich sieht aber siempre todavía así de:

1|2|3|4|5|6|7|8|9|z

Sonst hätte Profano no Zugriff por String en el restlichen Teil.
Wenn Yo otra vez vergrößere, sieht lo otra vez así de (debería):

1|2|3|4|5|z7|8|9|z

Das Nullbyte es natürlich siempre todavía drin y ahora es el Programmierer gefordert, seine Daten vernünftig auszulesen/einzutragen.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Das Redim kann se doch pero no al cadena$ oder char$ orientieren.

Auf Speicher, el no reserviert es darf no zugegriffen voluntad - el darf uno ahora hier pero no vermischen.

Wenn una 10 Byte Speicherbereich

HALLO WELT

en 5 Byte redimensioniert se, entonces muss el Ergebnis necesariamente (y natürlich)

HALLO

ser, y no

HALLz

Yo finde XProfan reagiert hier völlig korrekt - Yo sería lo erwürgen si hier el Speicher incluso verändert.

Was Ihr wollt macht uno schliesslich incluso, indem uno eben no en 5 pero 6 dimensioniert y el z-Byte incluso en el Speicher schreibt bevor uno z.B. String$ drüberjagt...

Frank
Abbing

IF versteht lo todavía no, herje! Wichtiger es aber, dass Roland lo versteht.
¿Por qué se en una 5 Byte grossen Speicher una 9 Byte grosser Texto en el String kopiert? Ist doch echt no sooo schwer...

Frank Abbing

¿Por qué se en una 5 Byte grossen Speicher una 9 Byte grosser Texto en el String kopiert?

Nach welchem Ejemplo? Das hier bricht korrekt de:
Kompilieren Marca Separación

 {$cleq}
cls
mem test=5
string test#,0="HALLO WELT"
print string$(test,0)
waitkey
e

Frank Abbing

Wichtiger es aber, dass Roland lo versteht.

Hast Usted el hilo verfolgt?

Es doch bastante anders. Es gefährlich el Función String$ en una Zona loszulassen (si no weitere Prüfung enthalten es) en el no sichergestellt es, el él con un Nullbyte endet. Dim sin embargo ha hier garnichts a Veränderungen des Speicherinhalts a tun...

Jörg
Sellmeyer

Nein, es eben no gefährlich, como Dim el Zona automáticamente con un NullByte abschließt. Erst una erneutes Dim macht lo gefährlich. Aber Yo tener ahora alles dijo, Yo dazu a sagen habe. Soll Roland se überlegen, si él Zugriff en Speicher außerhalb des Programms como Bug oder Feature ansieht.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...