Can also be reprogrammed to UTF8, for example to save the data directly as UTF8.
For me it takes about 50 ms to add the 100000 characters
Code: Select all
; Moved to Tricks 'n' Tips
Code: Select all
; Moved to Tricks 'n' Tips
It's even possible to store the internal format and create string procedures that can use Ascii, Unicode or UTF8 internally.mk-soft wrote:Programmed on the fast one to quickly create very large strings.
Can also be reprogrammed to UTF8, for example to save the data directly as UTF8.
I always try to find existing feature requests before I open one myself. Your thread is too much about string builders (merging strings) later.User_Russian wrote:I asked for the same thing about 6 years ago. viewtopic.php?f=3&t=58892
But it is foolish to expect that it will be done sometime. Because requests are rarely fulfilled!
The requests section needs to be closed, because it's useless. viewtopic.php?f=3&t=75576
Currently I don't see any problems that could break existing code after the integration of the feature request.kenmo wrote:However, it would be a major change to the string library, and could break 20 years of existing code (memory bugs)
Here in the forum you can often see that codes with pointers are used when it comes to speed instead of using the normal string functions. I think that the PB string functions should be the preferred functions and should therefore be fast, so that codes with pointers are not necessary at all, but only in special cases.mk-soft wrote:The current string management works and is sufficient for 99.99% of applications.
With a few megabytes of string size there should be no problems. If the size is much more, I also recommend to use memory rather than variables, because AllocateMemory() allows reacting in case of a failure, so the program does not crash in any case, if the memory could not be allocated. We then have the opportunity to intervene and determine what should happen in case of failure. Then I unfortunately have to work with memory functions, although I actually want to use the string functions, because I actually work with strings. Difficult thing.STARGÅTE wrote:I think some confuse a string with a memory buffer.
My feature request is not to abolish the zero termination character. Memory should still be used for binary data. Unlike with string variables, we can not write the string length before the string in the memory, because then there is the danger that already existing codes do not work correctly anymore. After the implementation of this feature request, PeekS() for example must still search for the string end character (null character).Rinzwind wrote:Also storing the length with the string makes it possible to use them for any binary storage (since null doesnt have to have special meaning anymore if you choose so). Can be quite convenient.
Extending string variables with memory functions (e.g. PokeS()) is already risky, because the PB string management doesn't notice that:helpy wrote:-1
If internally storing string length with each PB string a new problem would arise
This problem would occour if you manipulate a PB string using pointers, memory functions and writing directly to the string memory using Poke or other *PointerToCharcter. Manipulating a string this way would not update the internal string length and PB functions would not work correctly ...
Code: Select all
Define text$ = "Hello"
PokeS(@text$, "Hello world!") ; Overflow in a string memory block
For performance reasons PB always allocates more memory for strings than necessary, so that the memory for the string does not have to be reallocated with every small string extension. So your imaginary MemorySize() function would return the string size plus the extra memory size, but not the real string size.NicTheQuick wrote:Isn't there a thing like MemorySize() for a strings buffer? How does this usually work together with AllocateMemory()?
If the operating system already knows how big the memory buffer to a given pointer is, this could be another idea.
Great mk_soft, primary, i think, we can say, it's buggymk-soft wrote:The string management of Purebasic is old and needs to be updated.
Here a sad result for comparison ...
Link: viewtopic.php?f=13&t=75750#p557919
So a big plus to the features request after all.
Your code will show the maximum length of the string, not how many characters it stores.Sicro wrote: I edited my first post for a hint in the fixed string structure. With fixed strings we don't need to store the string length, because the memory buffer surely corresponds exactly to the size needed to store the string and the string length can therefore be easily calculated:Code: Select all
stringLength = MemorySize(*fixedString) / SizeOf(Character)
Code: Select all
s.s{128}
s="1234"
Debug Len(s)
How? It causes no changes to our source codes, so old compiled exes would still work the same, and new compiled exes would just use the new compiled string code. So what's to break?
Yes, I obviously didn't think of that at the time when I created that feature request, although I also did that in my codes sometimes. Mostly this is done with WinAPI functions because they are compatible with the PB strings unlike the other API functions of the other OS.
Code: Select all
result$ = Space(255)
WinAPI_Function(@result$)
result$ = PeekS(@result$)
Debug result$
Code: Select all
result$ = Space(255)
WinAPI_Function(@result$)
; -1 = search for the null character
UpdateStringLength(result$, -1)
Debug result$
Code: Select all
result$ = Space(255)
length = WinAPI_Function(@result$)
UpdateStringLength(result$, length)
Debug result$
That's apparently pretty rare. I can't remember where I've seen this.
Code: Select all
newString.z = "Hello"
oldString.s = newString
alterString + " World"
newString = oldString
Debug newString ; Outputs 'Hello World'
Debug oldString ; Outputs 'Hello World'
Code: Select all
oldString.s{5} = "Hello World"
newString.z{5} = "Hello World"
Debug oldString ; Outputs 'Hello'
Debug newString ; Outputs 'Hello'
Code: Select all
oldString.s = "Hello World"
length = Len(oldString)
Debug Left(oldString, 5, length) ; Outputs 'Hello'
Debug Right(oldString, 5, length) ; Outputs 'World'
Code: Select all
; API Dummy
Procedure AnyApiW(*String, cbByte)
Protected r1.s, len
r1 = "Hello World"
len = StringByteLength(r1)
If *String
If len <= cbByte
PokeS(*String, r1)
ProcedureReturn len
EndIf
Else
ProcedureReturn Len
EndIf
EndProcedure
Debug "****"
t1.s = Space(1024)
r1 = AnyApiW(@t1, StringByteLength(t1))
Debug Left(t1, 5)
Debug Right(t1, 5)
Debug "****"
r1 = AnyApiW(0, 0)
t1.s = Space(r1 >> 1)
r1 = AnyAPIW(@t1, StringByteLength(t1))
Debug Left(t1, 5)
Debug Right(t1, 5)
Debug "****"
Structure sData
iVal.i
text.s{20}
null.w
EndStructure
Define d1.sData
r1 = AnyApiW(@d1\text, 40)
ShowMemoryViewer(d1, 80)
Debug Left(d1\text, 5)
Debug Right(d1\text, 5)
Code: Select all
Procedure WinAPI_Function(*value)
PokeS(*value, "Test")
EndProcedure
Define value$ = "Example"
; value$\charLength = 7
WinAPI_Function(@value$)
Debug value$
; Outputs 'Testple'
; value$\charLength = 7
I was trying to figure out which way is faster. If the length of the string is known, then you use "For i=1 To Len", and if not known, then you use the character test "While *c\c". In either case, you check whether the counter is longer than the string, or whether the character is null.
I assumed that the authors do not add string functions for the reason that they can be made independently based on the existing functionality. Why not make an additional section in the help file with examples of interesting solutions. Many beginners find it difficult to write functions on their own, so if these functions were offered as ready-made functionality in the help file, it would improve the attractiveness of the language during the learning phase.
Code: Select all
; Linux only x64 8 Byte before string.
For i=1 To 35 Step 1
s.s="TEST"+Space(i)
*plen.Integer=@s-8
slen=Len(s)
Debug Str(*plen\i)+" "+Str(slen)+" "+Str((*plen\i-19)/2) ;+" "+Hex(*p)
Next
ShowMemoryViewer(@s-8,Len(s)*2+10)
CompilerIf #PB_OS_Linux<>#PB_Compiler_OS : CompilerError "only LINUX" :CompilerEndIf
; 33 5 7
; 33 6 7
; 33 7 7
; 49 8 15
; 49 9 15
; 49 10 15
; 49 11 15
; 49 12 15
; 49 13 15
; 49 14 15
; 49 15 15
; 65 16 23
; 65 17 23
; 65 18 23
; 65 19 23
; 65 20 23
; 65 21 23
; 65 22 23
; 65 23 23
; 81 24 31
; 81 25 31
; 81 26 31
; 81 27 31
; 81 28 31
; 81 29 31
; 81 30 31
; 81 31 31
; 97 32 39
; 97 33 39
; 97 34 39
; 97 35 39
; 97 36 39
; 97 37 39
; 97 38 39
; 97 39 39
; 0000000000773878 61 00 00 00 00 00 00 00 54 00 45 00 53 00 54 00 a.......T.E.S.T.
; 0000000000773888 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 . . . . . . . .
; 0000000000773898 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 . . . . . . . .
; 00000000007738A8 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 . . . . . . . .
; 00000000007738B8 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 . . . . . . . .
; 00000000007738C8 20 00 20 00 20 00 00 00 . . ...