Question about DIMing user-defined types

[jakeh0916]

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
5. End Type
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.

[bplus]

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.

[TempodiBasic]

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 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
here a demo

Code: QB64: [Select]

1. Type point3D
2.     X As Long
3.     Y As Long
4.     Z As Long
5. End Type
6.  
7. Type D2point
8.     As Long X, Y, Color
9. End Type
10.  
11. Dim A As Integer, B(1 To 10) As point3D, c As D2point
12. Clear
13. Print A
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
17. Next d

or for single dynamic array you can use ERASE https://www.qb64.org/wiki/ERASE.
Good Coding

[SpriggsySpriggs]

You could do this as well:

Code: QB64: [Select]

1. Option _Explicit
2.  
3. Declare CustomType Library
4.     Function ZeroMemory%& Alias SecureZeroMemory (ByVal ptr As _Offset, Byval cnt As _Unsigned Integer)
5. End Declare
6.  
7. Type test
8.     As Long data1, data2
9. End Type
10.  
11. Dim As test test
12. Dim As _Offset a
13.  
14. a = ZeroMemory(_Offset(test), Len(test))

[bplus]

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
5. End Type
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
12. Next
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
22. Next
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
32. End Sub
33.  

Update: this code didn't generate any in v1.3 or v1.4 either so... a watched pot never boils.

[luke]

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.

[bplus]

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
3. _ScreenMove _Middle
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
12. End Type
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
26. Next
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
35. Next
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.  
61. End Sub
62.  
63.  

  [ You are not allowed to view this attachment ]  

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...
  [ You are not allowed to view this attachment ]  

[SMcNeill]

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

[bplus]

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?

[SMcNeill]

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.