XProfan

- page 2 -

quoi hat un NullByte avec qui Redimensionierung trop 1faire?

un Imprimer String$(B#,0) ist absolu pas aussagekräftig là es ici jusque einem NullByte liesst.

si on dans einem Bereich un zéro-Byte nécessaire, weil une Funktion comment string$ jusqu'à là hin liesst, ensuite sollte on cela NULL-Byte mettons.

ou bien kappier je seulement quelque chose pas?

Jörg
Sellmeyer

si Profan une Bereich dimensioniert, liest String$(...) den toujours jusque korrekt eingestellten Taille des Bereichs aus. cela fait es mais pas plus, si qui Bereich récente dimensioniert wurde. cela hat nix avec cela trop 1faire, si je un NullByte besoin, là cela Abschlußbyte oui sonst aussi de Profan gesetzt wird.

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

Jörg Sellmeyer

si Profan une Bereich dimensioniert, liest String$(...) den toujours jusque korrekt eingestellten Taille des Bereichs aus.

Wird pas principale jusque einem Byte 0 gelesen?

RGH

String$ liest jusqu'à zum ersten Byte(0), Char$ qui angegebene Anzahl marque.

Salut
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 wir uns maintenant im Kreis, ou bien? Bien sûr wird jusqu'à zum ersten NullByte gelesen. si dimensioniert wird, wird cet Byte mais automatisch à qui dernier Stelle gesetzt. pourquoi sollte Faible cela chez qui zweiten Anwendung anders faire. aussi hat String$(...) so Zugriff sur grenier, qui déjà pas plus zum Programme est. cela sollte meiner attitude pas son. Pour dem zweiten Faible ist qui Funktion String$ pratique nutzlos.

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

Frank
Abbing

Jörg hat es genauso dit comme ist. cela zweite String$ liest aus unerlaubtem grenier. qui Redimensionierung ist dans cette forme incorrect.

und dir alors seulement tout autor, chez einer Vergrößerung des Speicherbereiches, den angehangenen partie avec zéro trop füllen?

Jörg
Sellmeyer

non!!! und dir tout autor, chez einer Verkleinerung un Nullbyte einzufügen:
un Bereich wird deklariert:
Kompilieren Marque Séparation

Declare Bereich#

ensuite wird il dimensioniert:
Kompilieren Marque Séparation

Dim Bereich#,10

ensuite sieht Bereich pour meinem Verständnis so aus:

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

Wobei 0 aussi beliebige données son peut, qui justement à qui Stelle im grenier stehen. c'est oui pas avec Claire Bereich gelöscht.
maintenant schreibe je quoi rein:
Kompilieren Marque Séparation

String Bereich#,0 = "123456789"

maintenant devrait Bereich so air:

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

jetz récente dimensionieren:
Kompilieren Marque Séparation

Dim Bereich#,6

Um korrekt trop marcher devrait Bereich maintenant so air:

1|2|3|4|5|z

qui grenier derrière elle est maintenant abgetrennt - qui gesamte Bereich sollte maintenant so air:

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

Profan hat alors weder par Char$ - cela chez Überschreiten qui Speichergrenze meckert - encore par String$ Zugriff sur den grenier derrière Bereich.

qui gesamte Speicherbereich sieht mais toujours so aus:

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

Sonst hätte Profan keinen Zugriff per String sur den restlichen partie.
si je wieder vergrößere, sieht es wieder so aus (sollte):

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

cela Nullbyte ist naturellement toujours drin et maintenant ist qui Programmierer gefordert, sa données vernünftig auszulesen/einzutragen.

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

cela Redim peux sich doch mais pas am string$ ou bien char$ orienter.

sur grenier, qui pas reserviert ist darf pas zugegriffen volonté - cela darf on maintenant ici mais pas vermischen.

si un 10 Byte Speicherbereich

HALLO WELT

sur 5 Byte redimensioniert wird, ensuite muss cela Ergebnis absolument (et naturellement)

HALLO

son, et pas

HALLz

je trouve XProfan reagiert ici völlig korrekt - je serait es erwürgen si es ici den grenier selbst modifié.

quoi vous voulez pouvoir on schliesslich selbst, indem on plan pas sur 5 mais 6 dimensioniert et cela z-Byte selbst dans den grenier écrit bevor on z.B. String$ drüberjagt...

Frank
Abbing

iF versteht es encore pas, herje! Wichtiger ist mais, dass Roland es versteht.
pourquoi wird chez einem 5 Byte grossen grenier un 9 Byte grosser Text dans den String kopiert? Ist doch vraie pas sooo schwer...

Frank Abbing

pourquoi wird chez einem 5 Byte grossen grenier un 9 Byte grosser Text dans den String kopiert?

Pour welchem Beispiel? cela ici bricht korrekt ab:
Kompilieren Marque Séparation

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

Frank Abbing

Wichtiger ist mais, dass Roland es versteht.

la hâte Du den Fil verfolgt?

c'est doch entier anders. c'est périlleux qui Funktion String$ sur une Bereich loszulassen (si aucun weitere Prüfung enthalten ist) chez dem pas sichergestellt ist, cela il avec einem Nullbyte endet. Faible cependant hat ici garnichts à Veränderungen des Speicherinhalts trop 1faire...

Jörg
Sellmeyer

non, c'est plan pas périlleux, là Faible den Bereich automatisch avec einem NullByte abschließt. seulement un erneutes Faible pouvoir es périlleux. mais je hab maintenant alles dit, quoi je en supplément trop dire habe. Soll Roland sich überlegen, si il Zugriff sur grenier außerhalb des Programms comme Bug ou bien Feature ansieht.

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