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
I always try to find existing feature requests before I open one myself. Your thread is too much about string builders (merging strings) later.
Through my thread I wanted to start the discussion about fast strings again from scratch. So that, also the fast reading of strings is more considered.
At least recently the wish to update the third-party libraries was fulfilled.
But I agree with you, the feature requests should get more reactions from the PB team, e.g. the PB team could tell us where the problems are if the feature requests are not integrated for a long time. So we could maybe help with the solution search. With the feedback from the PB team, creating feature requests would also make it more fun to create feature requests, because then we know that the PB team is paying attention to them.
kenmo wrote:However, it would be a major change to the string library, and could break 20 years of existing code (memory bugs)
Currently I don't see any problems that could break existing code after the integration of the feature request.
mk-soft wrote:The current string management works and is sufficient for 99.99% of applications.
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.
STARGĂ…TE wrote:I think some confuse a string with a memory buffer.
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.
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.
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).
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 ...

Extending string variables with memory functions (e.g.
PokeS()) is already risky, because the PB string management doesn't notice that:
Code: Select all
Define text$ = "Hello"
PokeS(@text$, "Hello world!") ; Overflow in a string memory block
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.
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.
@mk-soft: Thanks for your code, but it only partially solves the problem. You would have to rewrite every PB function that handles with strings, so the implementation in PB must be done natively.