Variable-length strings in TYPEs

[Cobalt]

And that's if you set a 2GB (or 4GB if you use an UNSIGNED LONG) limit to store that string length).  Since some folks (like soniaa in the Dim A thread) need to access larger sizes than that, an INTEGER64 would probably need to be used to stop any issues and work for future expansion, so you'd probably have to add 8 bytes per string...

Even the longest book ever written comes in at under 10 million(estimated) ASCII characters. And you have to consider memory size(the DIM A thread) in there as well. And data structure, so a limit of UNSIGNED LONG(cause you can't have a negative string anyway) is more than enough in any practical application. and even at that you could only have 4 or 5 arrayed of that type on most typical computers. While I agree that special occasions may call for a much larger value, most users of QB64 aren't going to have machines that could handle it. And large corporations like Apple or Google or the like that would have the means to have machines with terabyte and petabyte ram values will probably have efficient data structures or custom software anyway, you know this. So just for simplicity my vote is on keeping it small, either a string terminator(0A0D like most text editors maybe) or pre-string LOS(Length Of String) integer.

Don't get me wrong I see where you are coming from I just don't see the practical simplistic side of it.

[codeguy]

Here's an idea.
A fixed delimiter of any size (in this case a*), namely sep$ for arbitrary lengths.

Code: QB64: [Select]

1. TYPE Identity
2.     FirstName AS STRING * 256
3.     Lastname AS STRING * 32
4.     NamesOfPets AS STRING '* does not work without String * nnnn
5. END TYPE
6. DIM qx AS Identity
7. '                  1      2         3   4              5    6             7        8              9                                       X
8. Del$ = "*a"
9. qx.FirstName = del$+"thea*bomina*bleSnowMa*nWa*sHereVistingSa*squa*tchThisIsARea*llyLongNa*meAndNobodyWa*ntsToWriteThisOutCompletelyAMillionSqua*redTimes"
10. NthOneToGet& = 7 '7 = llyLongN using del$ as delimiter
11.  
12. PRINT GrabThatNth$(qx.FirstName, NthOneToGet&)
13. FUNCTION GrabThatNth$ (m$, n&)
14.     For I = 1 to Len(m$)
15.            If asc(m$,I)=0 then
16.                Exit for
17.            End if
18.     Next
19.     Sep$=left$(m$,I)
20.     p& = Len(sep$)+1
21.     c& = 0
22.     DO
23.         m& = INSTR(p&, m$, sep$)
24.         IF m& < 1 THEN
25.             GrabThatNth$ = MID$(m$, p&)
26.             EXIT DO
27.         ELSEIF c& < n& THEN
28.             p& = m& + sepLen&
29.             c& = c& + 1
30.         ELSE
31.             GrabThatNth$ = MID$(m$, p&, m& - p&)
32.             EXIT DO
33.         END IF
34.     LOOP
35. END FUNCTION
36.  

[FellippeHeitor]

Say what??

[SMcNeill]

Say what??

No idea.  I didn't comprehend what Codeguy was referring to either. 

[codeguy]

The approach I use is for the string using fixed-length delimiters to find the Nth substring, no matter how far away the next delimeter is. The delimiter could be any length so as not to conflict with Individual strings already contained. Maybe a random string prepended with character 0 appended to that eg:
RsYv109!+chr$(0)+some stuff betweendelimeter+RsYv109!+chr$(0)+thenextString+RsYv109!+chr$(0)...
You get the idea. The lengths of substrings can then be limited only by memory. Hope that helps.

[TempodiBasic]

Using a special mark like end of string is a procedural solution. The right issue noted by Steve can be minimized using a big mark as EOF (a sequence of 4-8 byte),so we change the case of premature end of string rare but not impossible.

so IMHO Codeguy suggests to use this mark EndOfString to be able to distinguish among the single string (substring), it is a way if we have a UDT made only with strings of variable length .... like

Code: QB64: [Select]

1. TYPE
2.  FirstString AS STRING
3.  SecondString AS STRING
4.  ThirdString AS STRING
5. END TYPE
6.  
7. ' using a pre_fixed_length delimiter QB64 can package all this Strings in a one SuperString to PUT# and/or GET#
8. ' internally QB64 makes these operations:
9.  
10. DIM SuperString AS STRING ,ContStringAS INTEGER
11. ContString = 3
12. SuperString = FirstString + Delimiter$+ SecondString + Delimiter$+ ThirdString+ Delimiter$
13. PUT/GET#1, SuperString
14.  
15. FOR cont% = 1 TO ContString
16. IF  INSTR(Delimt%+1,SuperString, Delimiter$) THEN
17. ' if there is a Delimiter$ at its left there is a string
18.  IF cont%= 1 THEN FirstString = ExtractString SuperString, Delimiter$
19.  IF cont%= 2 THEN SecondString = ExtractString SuperString, Delimiter$
20.  IF cont%= 3 THEN ThirdString = ExtractString SuperString, Delimiter$
21. END IF
22. NEXT
23.  
24. FUNCTION ExtractString (SupStr$, Delim$)
25. Delimt%= INSTR(Delimt%+1,SupStr$, Delim$) ' it finds the end of a string
26.  ExtractString =MID$ (SupStr$,1,Delimt%)  'it returns the string at left of SupStr$
27. SupStr$ = RIGHT$(SupStr$,LEN(SupStr$)-( Delimt% + LEN (Delim$))) ' it returns the rest of SupStr$ without the last extracted string
28. END FUNCTION
29.  

IMHO this case is like the array of string

TYPE
 FirstString AS STRING
 SecondString AS STRING
 ThirdString AS STRING
END TYPE

is equal to write

CONST FirstString = 1, SecondString =2, ThirdString = 3
DIM ArrayString (FirstString TO ThirdString) AS STRING

IMHO QB64 can manage PUT#/GET# with ArrayString.
So it is possible that QB64 internally can translate an UDT of strings variable to an array of Strings

--------
On the other hand, but how do Qbasic/QB4.5/QB7.1  create/manage strings in RAM?

[codeguy]

Something along the lines of what's pictured. I will upload a doable and faster version with substring splits loaded to an array for FAR easier and faster string lookup. It may have to involve HashTables and multidimensional arrays to be more usable for very large strings and with many substrings. It would greatly reduce the horsepower a CPU needs to extract the 999,368th substring for example.

[bplus]

Either that or linked lists using _get and _put yet to be created that use linked lists or something else... ;)

[pinology]

kind of along the same lines I was wondering if you could use an array in a type variable something like
type a
  b(20) as integer
  c as string * 5
end type

[luke]

kind of along the same lines I was wondering if you could use an array in a type variable something like
type a
  b(20) as integer
  c as string * 5
end type

That's on the cards as the next thing to work on

[pinology]

cool luke, that would come in real handy for putting data into random files and being able to access some of your variables numerically

[TerryRitchie]

kind of along the same lines I was wondering if you could use an array in a type variable something like
type a
  b(20) as integer
  c as string * 5
end type

That's on the cards as the next thing to work on

Oh man, that would make writing this updated sprite library so much easier, LOL.

[luke]

Making GET and PUT work in any fashion turned out to be much harder and more work than I expected, since I need to find a way to embed UDT structural info into the final executable. Until I do that, I have published the changes allowing for variable length strings in UDT's to the development build of QB64. I would appreciate any attempts to find bugs with it (bugs are likely to be crashes, garbage data in variables, compiler errors when there shouldn't be).

[FellippeHeitor]

Good news!

[Cobalt]

Hey, Luke, LEN() always returns 4 regardless how many characters are in the string.