Illigal type conversion using Null

Blitz3D Forums/Blitz3D Programming/Illigal type conversion using Null

Fernhout

(Posted 2015) [#1]

I use Blitz3D 1.108 IDE and compiler.

When i am writting the following code i got an error massage:


Type MyCity_T
  Field HounsNumber
  Field OwnerName$
  Field TotalPeople
  Field Peds          ; Only true or false
End Type

If Housing = Null
  ;There are no houses so create them
  Housing.MyCity_T = New MyCity_T
Endif

I got this error during compilng :
"Illigal Type conversion"

And now the good part


Type MyCity_T
  Field HounsNumber
  Field OwnerName$
  Field TotalPeople
  Field Peds
End Type

Housing.MyCity_T = new MyCity_T
Delete Housing

If Housing = Null
  ;There are no houses so create them
  ;This line is still executed
  Housing.MyCity_T = New MyCity_T
Endif

Here is de compiler not complaining. Its compile the game complete and everything is working like a charm.

What is the differend in this. In both cases i do not have the type created. First one not at all and in the second one i delete the type.

The manual state that Null is checking if the Type is created or not. If the Variable name is not linked to a type then the variable is Null.

So for me its strange that number one is an error and number two not.

GfK	(Posted 2015) [#2]

In your first example, "Housing" is treated as an integer by default (you haven't told Blitz3D that it should be treated as anything else). Integers (and floats, and bytes, etc) cannot be Null.

In the second example, you're correctly defining Housing as type MyCity_T, so there is no error.

Yasha

(Posted 2015) [#3]

You can prevent this from happening by using IDEal as your editor, and turning on Strict mode. It will highlight as an error any time you forget to declare a variable using Local.

(Of course, one could argue that it's a bug because Blitz3D should never have allowed this in the first place, but that's another matter...)

Fernhout

(Posted 2015) [#4]

But Blitz3D compilng is not a one pass compiler. So it has to see during name checking that the name got used. That means that for a second pass the compiler must already knows that the New type is created.

If e.g. the name is not returning in the whole source code then i can understand why. But not with this code.

For me i use Ideal as IDE that gives me a strick uption witch is always on. So when i make a typo the name is turned red as undeclared. I like that more.

Yasha

(Posted 2015) [#5]

That means that for a second pass the compiler must already knows that the New type is created.

It knows, but it's using the first appearance to set the type; that means that if it hadn't been distracted by the type error on the = line, it would have complained about the New line being a type error instead. It's not smart enough to backtrack and infer that the first appearance didn't need to set the type to integer after all.

Fernhout

(Posted 2015) [#6]

Your right i did not think on that way but its the right way to do so.
When the compiler must pass the first time its need to set the variables.Before it can convert the sourcecode itself.

And now i thinking about it it is also needed for the more complex combination of instructions. Say get pointer of variable to bank of its pointer. When the compiler do not have the settings already it is not able of converting the code.

Oh and the IDE IDeal is not showing me that i make a mistake. Cause the type pointing is ok. Only the que of using it is wrong. And Ideal is not seeing this.

Thaks for showing me the way to think.

bart.