QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: Ophelius on August 09, 2020, 01:31:01 pm
-
There's definitely some internal bugs when it comes to those. Before I found out this feature was added, I had several Types for various objects, but any strings were put in separate arrays like this:
'All the following code is just for examples
REDIM SHARED Obj(0 TO n) AS ObjType
REDIM SHARED ObjText(0 TO n) AS STRING
Both arrays always had the same numbers of elements so it was easy to reference the strings for whatever objects I needed. This worked great and was better than trying to use fixed-length strings in Types.
But when I found out about variable-length strings added to Types, I added the strings to my Types like this in order to clean up my code:
Type ObjType
a as integer
b as integer
Text as string
End Type
REDIM SHARED Obj(0 to n) AS ObjType
After I did this, my program became possessed, weird bugs would happen, some that were even different if I ran the program at another time, even though no code changed.
They appear to be related to the internal memory of how QB handles the strings in the Types.
The bugs seems to always happen in places when I would get the Len of the string -> LEN(Obj(id).Text). I checked and the function is returning the correct length in all my tests, so there's something more internal going on. There seems to be memory overlaps, causing random elements and objects to change their behavior because memory locations are being corrupted.
Another thing that might be affecting it is I have several dozens of objects, each being REDIMed _PRESERVEd when they were created/added to the array, maybe that has something to do with it.
So after scratching my head all day looking if it was my own code, I came to the conclusion that it wasn't my code and put my code back to what it was, putting the strings back in separate arrays. After I did that, my program became normal again working perfectly.
Sorry I can't be more specific, the bugs were really random and weird, but I can tell it's some internal memory problem.
-
We have found that you can't assume Types initialized to 0 or "" for strings, maybe your code is assuming this?
If you say DIM x you can count on x being 0 to start or DIM s as string you can count on s ="", not so with variables in defined types.
Oh, also with a REDIM PRESERVE expanding an array, don't assume all is 0 or "".
-
We have found that you can't assume Types initialized to 0 or "" for strings, maybe your code is assuming this?
If you say DIM x you can count on x being 0 to start or DIM s as string you can count on s ="", not so with variables in defined types.
Oh, also with a REDIM PRESERVE expanding an array, don't assume all is 0 or "".
There were places where I wasn't initializing the variables, I was assuming uninitialized Type variables would be 0 or "" like you said. That's probably why. But since I already reverted my code to what it was prior, I'll just keep what I have which works. Good to know for the future.Thanks
-
I think something is off when it initialises the string descriptor, causing it to smear data over the other elements. Despite what bplus says you should be able to expect variables to always be initialised to 0/"" so it's definitely a problem.
-
Despite what bplus says you should be able to expect variables to always be initialised to 0/""
Despite?
Bplus expected it and was sorely disappointed. ;(
This was discussed here at forum some time ago.
-
Despite what bplus says you should be able to expect variables to always be initialised to 0/"" so it's definitely a problem.
Except with _MEMNEW. Galleon never had mem blocks reset to null, so as to not add any overhead to them initializing. Mem is for speed, and if you’re just going to fill your block as soon as you create it, it doesn’t matter if it’s been nulled or not.