Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: jakeh0916 on March 03, 2021, 05:45:36 pm

Title: Question about DIMing user-defined types
Post by: jakeh0916 on March 03, 2021, 05:45:36 pm
Hi everybody, I had a quick question about DIM and how it works with user-defined types.

Say I create a type for a 3d point,
Code: QB64: [Select]
  1. Type vec3
  2.    x as double
  3.    y as double
  4.    z as double
  6.  

When I DIM something of this type, can I safely assume that it will always DIM the type with defaulted values (x = 0, y = 0, z = 0), or is there a chance that the program will reuse some bits of memory, and end up with my x, y or z variables equaling something other than 0? The superstitious part of me wants to do something like this to ensure that my variables always get set up properly:

Code: QB64: [Select]
  1. ' Set up some "default" variable at the beginning of the script...
  2. Dim Shared vec3_default as vec3
  3. vec3_default.x = 0
  4. vec3_default.y = 0
  5. vec3_default.z = 0
  6.  
  7. ' And use that default variable to initialize any DIMed variable
  8. Dim someRandomPoint as vec3
  9. someRandomPoint = vec3_default
  10.  

So my question is, in general: when you DIM a user defined type, does the program make sure to reset all of the bits and whatnot in memory, or does it just dimension the variable without looking at whether there was already some stuff there in memory? My thinking is that it will actually reset the memory when it DIMs any variable, but I wasn't quite sure.
Title: Re: Question about DIMing user-defined types
Post by: bplus on March 03, 2021, 06:18:25 pm
No it's not safe to assume UDT's will start at zero or "" best to assign them to 0 if not some other initial value.

This might of been fixed but I don't remember when.

I recently did programMap UDT in v1.4 and was getting crazy stuff happening until I remembered to 0 out all values at the start.

Code: QB64: [Select]
  1.     UBPM = UBound(Program$)
  2.     ReDim ProgramMap(1 To UBPM) As ProgramLine
  3.     For i = 1 To UBPM 'oh yeah ============================ Zero Out Type array!!!!!!!
  4.         ProgramMap(i).LoopLevel = 0: ProgramMap(i).IFLevel = 0: ProgramMap(i).GoToT = 0
  5.         ProgramMap(i).GoToAlt = 0: ProgramMap(i).Cmd = "": ProgramMap(i).ArgLine = ""
  6.         k = Len(Program$(i))
  7.  
  8.  

Now I am remembering ReDim _Preserve as well, the new parts might have to be 0'd also though I don't recall any incidents from that.
Title: Re: Question about DIMing user-defined types
Post by: TempodiBasic on March 03, 2021, 07:17:19 pm
Hi Jakeh0916

I'm used to initialize my variable, both predefinied kind of variable both UDT variable. But I can affirm that I have had no issue about a casual wrong value into a variable DIMmed.

Wiki spent no a word about this your issue https://www.qb64.org/wiki/DIM (https://www.qb64.org/wiki/DIM) at page of DIM keyword.
Just a tip to you, here you can find 2 different ways to get initialization to 0 or ""
CLEAR after declaring all the variables and arrays http://www.qb64.org/wiki/CLEAR (http://www.qb64.org/wiki/CLEAR)
here a demo
Code: QB64: [Select]
  1. Type point3D
  2.     X As Long
  3.     Y As Long
  4.     Z As Long
  6.  
  7. Type D2point
  8.     As Long X, Y, Color
  10.  
  11. Dim A As Integer, B(1 To 10) As point3D, c As D2point
  14. Print c.X, c.Y, c.Color
  15. For d = 1 To 10 Step 1
  16.     Print B(d).X, B(d).Y, B(d).Z
or for single dynamic array you can use ERASE https://www.qb64.org/wiki/ERASE (https://www.qb64.org/wiki/ERASE).
Good Coding
Title: Re: Question about DIMing user-defined types
Post by: SpriggsySpriggs on March 03, 2021, 07:28:16 pm
You could do this as well:

Code: QB64: [Select]
  2.  
  4.     Function ZeroMemory%& Alias SecureZeroMemory (ByVal ptr As _Offset, Byval cnt As _Unsigned Integer)
  6.  
  7. Type test
  8.     As Long data1, data2
  10.  
  11. Dim As test test
  13.  
  14. a = ZeroMemory(_Offset(test), Len(test))
Title: Re: Question about DIMing user-defined types
Post by: bplus on March 03, 2021, 08:45:43 pm
I am not finding non zero's in v 1.5 trying a number of things that might throw it off.

Code: QB64: [Select]
  1. Type vec3
  2.     x As String
  3.     y As String
  4.     z As String
  6.  
  7. ReDim Shared V3(1 To 100) As vec3
  8. ReDim a(1 To 1000000) As Double
  9.  
  10. For i = 1 To 1000000
  11.     a(i) = Rnd
  13. ReDim a(1 To 1)
  14. makeV3Bigger
  15. For i = 1 To 1000000
  16.     Print i, V3(i).x, V3(i).y, V3(i).z
  17.     If Val(V3(i).x) <> 0 Or Val(V3(i).y) <> 0 Or Val(V3(i).z) <> 0 Then
  18.         Beep
  19.         Print "Found non 0 in line above.  Zzz... press any"
  20.         Sleep
  21.     End If
  23.  
  24.  
  25. Sub makeV3Bigger
  26.     For i = 1 To 1000000
  27.         Print "MakeBigger:"; i
  28.         If UBound(V3) < i Then ' of course we do this at every step
  29.             ReDim _Preserve V3(1 To i) As vec3
  30.         End If
  31.     Next
  33.  

Update: this code didn't generate any in v1.3 or v1.4 either so... a watched pot never boils.
Title: Re: Question about DIMing user-defined types
Post by: luke on March 04, 2021, 03:05:04 am
TYPE elements are always* initialised to 0. This includes when REDIMming an array of them.

* There's an elusive bug that sometimes causes elements to not be initialised to 0, but this is only for TYPEs that have an AS STRING element.
Title: Re: Question about DIMing user-defined types
Post by: bplus on March 04, 2021, 07:46:33 pm
The "Nessie" of QB64 is now captured on film! ( v1.5 )

I have replicated conditions that gave me recent sighting of non zero initializing of Long type variables in UDT:
Code: QB64: [Select]
  1. Screen _NewImage(1024, 672, 32)
  2. _Delay .25
  4.  
  5. Type PgMap ' duplicating  the situation where I got stuff in non zeroed long values in new UDT array
  6.     S1 As String
  7.     S2 As String
  8.     L1 As Long
  9.     L2 As Long
  10.     L3 As Long
  11.     L4 As Long
  13.  
  14. ReDim Shared P$(1 To 200) ' i was working with another string array
  15. ReDim Shared UBPM As Long, PM(1 To 1) As PgMap
  16. For i = 1 To 200 'put stuff in p()
  17.     'Print "Building p() array line:"; i
  18.     If Rnd < .5 Then
  19.         rstop = Int(Rnd * 10) + 1
  20.         b$ = ""
  21.         For j = 1 To rstop
  22.             b$ = b$ + Chr$(Int(Rnd * 26) + 65)
  23.         Next
  24.         P$(i) = b$
  25.     End If
  27. Parser
  28. ' now see if anything unusual in pm  specially the L values
  29. For i = 1 To UBPM
  30.     Print i, PM(i).S1, PM(i).S2, PM(i).L1, PM(i).L2, PM(i).L3, PM(i).L4
  31.     If i Mod 20 = 0 Then
  32.         Print "Zzz... press any"
  33.         Sleep
  34.     End If
  36.  
  37. Sub Parser
  38.  
  39.     UBPM = UBound(p$)
  40.     ReDim PM(1 To UBPM) As PgMap
  41.     For i = 1 To UBPM
  42.         'Print "First pass building PM() the UDT not zero'd out line:"; i
  43.         If P$(i) <> "" Then
  44.             PM(i).S1 = Left$(P$(i), 2)
  45.             PM(i).S2 = Mid$(P$(i), 3)
  46.         End If
  47.     Next
  48.     For i = 1 To UBPM
  49.         Print "2nd pass building PM() with UDT not zero'd out line:"; i
  50.         If Left$(PM(i).S1, 1) = "A" Then ' assuming .L1, .L2... are 0 so adding 1 first time makes it 1...
  51.             PM(i).L1 = 1
  52.         ElseIf Left$(PM(i).S1, 1) = "B" Then
  53.             PM(i).L2 = 1
  54.         ElseIf Left$(PM(i).S1, 1) = "C" Then
  55.             PM(i).L3 = 1
  56.         ElseIf Left$(PM(i).S1, 1) = "D" Then
  57.             PM(i).L4 = 1
  58.         End If
  59.     Next
  60.  
  62.  
  63.  

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

The items in each of the 4 columns on right represent Long Type and can at MOST have 1 in either of 4 columns,
instead you can see all kinds of crazy data. Run again, and at first it may appear correctly with all 0's or 1 but page down (press key through SLEEPs and find a line or 2 of outrageous number (not 0 or 1).

2nd Run and Nessie looks like she's gone but no... page through all 200 lines...
  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: Question about DIMing user-defined types
Post by: SMcNeill on March 04, 2021, 09:02:26 pm
Quote from: luke on March 04, 2021, 03:05:04 am
TYPE elements are always* initialised to 0. This includes when REDIMming an array of them.

* There's an elusive bug that sometimes causes elements to not be initialised to 0, but this is only for TYPEs that have an AS STRING element.

Not to rain on your parade, but Luke already mentioned how to generate this glitch, above.  You have to have an AS STRING element in your UDT....

Which is just another reason why I personally just consider variable-length strings as being experimental still, and they’re something I try to avoid in my TYPEs.  Now, once we can somehow GET/PUT types with variable-strings in them, I’ll probably use them like a fat kid uses candy, regardless of other hoops which I might need to watch for (like non-initialized arrays).  ;D
Title: Re: Question about DIMing user-defined types
Post by: bplus on March 05, 2021, 12:30:23 am
Yeah but don't you find it curious, most curious, how the introduction variable length strings corrupts the integrity of Longs of other numeric type?
Title: Re: Question about DIMing user-defined types
Post by: SMcNeill on March 05, 2021, 12:49:05 am
Quote from: bplus on March 05, 2021, 12:30:23 am
Yeah but don't you find it curious, most curious, how the introduction variable length strings corrupts the integrity of Longs of other numeric type?

Not really.  If I had to guess, the internal process is probably using some process like:

Find first element memory address.
Count total space of type.
Multiply space * array size.
Mem fill address, total size, 0’s...

Now, with the first element being a variable-length string, that’s NOT where the array starts; it’s a pointer to where that string is stored in memory.  That could be the issue.

Or...   total type size could be off.  2 * Variable STRING + 3 * LONG...  What is the LEN(TYPE)?  12?  0?  Something else?   That can affect the mem fill...

I’d say it’s  basically something related to the above that is causing the issue.  The easiest way to initialize a variable/array to zero is just memfill m, m.offset, m.size, 0 — but how do you calculate those fill values?

When variable length strings are in use, you almost have to have a loop similar to:
FOR I = lbound TO ubound
   t$(I) = “”
NEXT

Since TYPEs never handled variable lengths until recently, it makes sense that their fill routine went the quick and simple route of memfill, rather than a slower loop fill structure.
Text Only | Text with Attachments