QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: bplus on September 30, 2019, 02:51:18 pm
-
Maybe I should have known this already but I didn't or have forgotten.
If you don't assign an UDT item an initial value it could start with anything. I just found and fixed a problem where I assumed an integer item would start at 0 if not assigned. It does not behave like normal variables that haven't been assigned initial values. You can't assume an unassigned integer item of UDT will be at 0.
To be more specific I found the problem in Dynamic array of UDTs where the first one in the array did seem to be consistently starting at 0 and I was REDIM _PRESERVE expansions of the UDT array.
-
So how did you solve it? Option Base 1?
-
So how did you solve it? Option Base 1?
Simply set the value to 0 or whatever initial value I want to assume before using it.
nUDT = nUDT + 1
REDIM _PRESERVE UDT(1 to nUDT) as UDTtype
UDT(nUDT).integerItem = 0 'now I can assume it is 0
-
Maybe I should have known this already but I didn't or have forgotten.
If you don't assign an UDT item an initial value it could start with anything. I just found and fixed a problem where I assumed an integer item would start at 0 if not assigned. It does not behave like normal variables that haven't been assigned initial values. You can't assume an unassigned integer item of UDT will be at 0.
To be more specific I found the problem in Dynamic array of UDTs where the first one in the array did seem to be consistently starting at 0 and I was REDIM _PRESERVE expansions of the UDT array.
MEM works the same way with _MEMNEW — it just allocates an area of memory for your needs, without initiating it to zero/null. This can save a good bit of processing time, (After all, why take the time and effort put blank data in your fields, if you’re just going to put another set of information into it right afterwards?), but it can cause you issues if you’re expecting to read the data before writing to it (such as how you were doing and assuming it’d default to zero).
Solution is, of course, as you presented it: Make certain to fill that memory with 0 before using it. (_MEMFILL is an excellent tool for this job.)
-
Thanks Bplus!
Useful information!
Yes I often uses UDT and I presume that they have initialization by compiler as for normal variables.
I think that I have not fallen in this issue because it is not so often to use a DYNAMIC UDT array!
Information memorized!
-
I'm going to say its the REDIM's fault here, I have always used UDTs and have never had an element of one pop up with a 'noise' value.
or else I have just been lucky the last several years.
-
I'm going to say its the REDIM's fault here, I have always used UDTs and have never had an element of one pop up with a 'noise' value.
or else I have just been lucky the last several years.
OK I've investigated the problem further and discovered the culprit is STRING item in the UDT:
PRINT " That was straight up DIM, press any..."
PRINT "That was REDIM, looks fine too!, press any..."
PRINT "Now for UDT with String, worked fine wo string" PRINT "but starting to see mess up with string in UDT" PRINT "for me item 0 is not 0's."
PRINT i;
","; AA
(i
).a;
","; AA
(i
).b;
","; AA
(i
).s
,
PRINT i;
","; AA
(i
).a;
","; AA
(i
).b;
","; AA
(i
).s
,
The arrays were working fine, all zero's until I added a STRING item to the UDT.
Maybe I found the thing Petr couldn't replicate?
Maybe I should go back and try the UDT with STRING on DIM and REDIM.
-
OK the problem is pretty obvious with REDIM _PRESERVE but there seems to be an issue with first item of UDT with String with REDIM (no _PRESERVE)
PRINT i;
","; d
(i
).a;
","; d
(i
).b;
","; d
(i
).s
, PRINT " That was straight up DIM for UDT with STRING Item, press any..."
PRINT i;
","; B
(i
).a;
","; B
(i
).b;
","; B
(i
).c
, PRINT "That was REDIM, UDT with all integers, press any..."
PRINT i;
","; AA
(i
).a;
","; AA
(i
).b;
","; AA
(i
).c
, PRINT "That was REDIM _PRESERVE, UDT with all integers, press any..."
PRINT i;
","; C
(i
).a;
","; C
(i
).b;
","; C
(i
).s
, PRINT "That was REDIM, UDT with a string and integers, press any..."
PRINT i;
","; AB
(i
).a;
","; AB
(i
).b;
","; AB
(i
).s
, PRINT:
PRINT:
PRINT "REDIM _PRESERVE of UDT with STRING here it is in Spades!"
-
Hi Bplus
it seems to me that the issue is a STRING not fixed in UDT
if you add for example *20 after declaration of string
as here
it seem to me to get a good result
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
Thanks TempodiBasic,
Well I've always known fixed strings are more secure but I want variable length strings to act as containers for Arrays I can Split out of a UDT. I am very OK with being sure to assign values before using, a small price to pay for arrays from a UDT.