PureBasic 6.40 alpha 1 is ready, surprise inside !

[HeX0R]

Basically if you patch a string by putting a zero in it, the Len() function will be wrong, and the concat functions will fail. You will need to use PeekS() for this.

Please, for really stupid people like me, can you explain in layman's terms what that actually means?

Code: Select all

a$ = "1234567890"
PokeU(@a$ + 5 * SizeOf(CHARACTER), 0) ;write an end of string after the "5" to shorten the string by "cheating"/patching
Debug Len(a$)	;PB <6.40 will show 5, ;PB 6.40 will still show 10, because it doesn't care about the end of string character
   ;solution for PB6.40 here would be:
   ;a$ = PeekS(@a$) ;just uncomment it and see the difference
   ;because PeekS() looks for the first zero byte/word and the strings size will be corrected
a$ + "67890" ;concat
Debug a$ ;PB <6.40 will show 1234567890, PB 6.40 will show 12345, because in PB 6.40 the string is now in memory "12345" + chr(0) + "7890" + "67890" (+ chr(0))
ShowMemoryViewer(@a$, 32)
Debug Len(a$) ;PB <6.40 shows 10, PB 6.40 shows 15

[ChrisR]

Just don't act surprised when that code breaks in the future because you are clearly messing with internals here. There is such a thing as over-optimizing.

Thanks Freak, for warning me about the risk for future versions!

The test on NIL (null pointer) is missing

Yep (If *s <> 0), but to know that it's the same with PeekS() :
Define PureBasicPath$ : PureBasicPath$ = PeekS(@PureBasicPath$)

It might be good to have a native function to reset the string size (with null pointer test) and without the return string, instead of PeekS

[HeX0R]

It might be good to have a native function to reset the string size (with null pointer test), instead of PeekS and without the return string

I'm fine with the native command PeekS().
And frankly speaking, you shouldn't take freaks comment too serious.
I mean, where else would you store the length of the string or what else would you like to store internally in a string in future?
Tinkering with internals always carries a risk to break in future, no question, but here I have no idea which upcoming feature might break this.
From my point of view, the code from fryquez is pretty future proof.
Although I never will need it most likely, those rare cases I might discover are fixed with a simple PeekS().
(and I need no speedtest to decide this )

btw.:

Yep (If *s <> 0), but to know that it's the same with PeekS() :

It's not the same, there is a quite huge difference between a Compiler Error and an IMA

[ChrisR]

Hi HeX0R, I agree with almost everything you wrote.
I also have no idea what functionality changes could cause problems in the future but I'm polite and Freak deserves respect.
More than the speed, which is pin-up, I was mainly interested in the procedure ingenuity.
Otherwise, I would have preferred a native function without any return value. But anyway, I won't be using it often too, and PeekS or ResetStringLength() does the job.
In future, I wouldn't be surprised to see a few bugs here and there due to forgetting to use PeekS() to recalculate the right size.
Also you're right about Compiler Error vs IMA