Code: Select all
dim as integer aa
dim as string bb
dim as integer ptr ppi
dim as string ptr pps
aa = 1
bb = "l"
ppi = @aa
pps = @bb
print typeof(aa)
if ((typeof(aa)) = (typeof(bb))) then print "true" ' or any variation of (())
if ((typeof(ppi)) = (typeof(pps))) then print "true"
(I want this to work in the runtime, not the preprocessor. When only pointers are flying around, this could be valuable.)
2 - And, am I seeing that the new array features effort would allow this to work as a true, full keyword in the runtime - for arrays only?
If so, shouldn't any new UDT type be enumerated so each would have its own type id in the runtime? The preprocessor has to do this already. I have to believe that the debug code should have an amount of code that could point the way. A programmer just has to know his code and old libraries and that a UDT id is not fixed if he codes some static linked functions. Or, better, could that new id be derived or assigned (think, FREEFILE) so that he can track them himself. Lots of possible wrinkles around this.
There should be room for 2 bytes (and a new table in debug) or so to allow something like this.
If new, extra code is included just for the array feature work, and TYPEOF modded (or a new keyword introduced) - shouldn't it be complete?
With this, '-exx' or '-nostrip' could keep and table the typenames so more convenient errors checks/msgs could be possible. The error/debug routines are going to have to be addressed, anyway. If the meat of your routines lie in only pushing pointers around, your view gets muddy very quickly.
Is this not practical?
(Just my thoughts.)
david