Externed Types and resizable arrays

BlitzMax Forums/BlitzMax Programming/Externed Types and resizable arrays

JoshK(Posted 2010) [#1]
This works as I would expect. Nothing is printed:
Type foo
EndType

Local f:foo[]

f=f[..5]

If f[0] Print "Oh noes!"


This works differently:
Extern "C"
	
	Type foo
	EndType
	
EndExtern

Local f:foo[]

f=f[..5]

If f[0] Print "Oh noes!"



Czar Flavius(Posted 2010) [#2]
As they are C, are they stored by value instead of by reference? Just a guess.


GW(Posted 2010) [#3]
f[x] is null until its created.


JoshK(Posted 2010) [#4]
I just proved otherwise. I think NULL for C Types is 0x00000 and NULL for BlitzMax objects is something else. When the array is resized, it is filled with NULL values that are not the same as what C Type use.

Last edited 2010


Gabriel(Posted 2010) [#5]
I think that's a fairly valid stab at the problem. A null pointer doesn't *always* have a value of zero in C, but it often does. I'm almost certain that BlitzMax null objects not being zero kicked me in the dingly-danglies once before, so I'm pretty sure you're right on that bit. I thought at the time it was a bit unfortunate to have a language which can import C as freely as BlitzMax does handle null differently, but slicing arrays never occurred to me.


beanage(Posted 2010) [#6]
Weird.

BlitzMax NULL seems to be 0x00503000:

Type foo
EndType

Local f:foo[]

f=f[..5]

If f[0] Print "Oh noes!"
Print Hex((Int Ptr Varptr f[0])[0])
Print Hex((Int Ptr Varptr f[1])[0])

Local v:foo = Null

Print Hex((Int Ptr Varptr v)[0])



JoshK(Posted 2010) [#7]
Right, but since the original array is filled with C NULL, when it is resized it should not be a problem to fill it will C NULL again. I think it's just an oversight.