A small math bug crept into my code when subtracting a double from a float. This bug will be fixed in the next update.
The compiler will generate the wrong assembly code for the subtraction of a double from a float. The follwing code illustrates the problem:
global sub main()
{
double b;
float c;
b = 5.0;
c = 1.0f;
writeln(str$(c-b)+"\n");
while GetKey() = "";
return 0;
}
Changing c to a double or b to a float type is a workaround.
Paul.
Now thats one of the problems which will arise in mixing C with C++ in one language!!
Nothing against the hard work Paul is making, i am amazed what he has done allready!! Progress is very fast, tried this mixing of C with C++ myself but that was not easy!
If I remember correctly the "implied" conversion is standard for C++ but in C you will get (if it is a sane compiler) a warning the least, very sane compliers give an error!!
Oke i admit used C some odd 25 years ago till about 1995, proffesionally and have the bible from Kernighan & Ritchie (or K&R for short) on my bookshelf (worn to pieces almost). page 184 $6.2 of K&R states that mixing FLOAT with DOUBLE converts the FLOAT to DOUBLE with padding zero its fraction (of the FLOAT).
So better to convert a FLOAT to a DOUBLE in the abover code of Paul!! The otherway CAN (and will) introduce a round off error in next calculations the so called "compounding roundoff error". Try THAT in a spreadsheet and you are broke in 3 months!!
Still like the language C, but some pointer cast-ing can drive someone stirr crazy (pointer tot a pointer to a pointer to a structure inside a structure, yeah right and that is normal practise? Not! it is bad coding!! But you can do that especially more in C++ than any other language, most laguages do it wrong after two pointers ;D )
Nothing likes me more than a mix of C (it's simple robustness) with some C++ (its simple classes). So yes i will buy Autora soon, when it is a tad more mature.
Keep up the good work Paul!!
Jan V.
Actually it was just a logic problem. A typo in my subtraction generating code.
In C you can get unwanted results if you don't force precedence
if(loc1.type & 0xFF == TYPE_FLOAT)
{
}
if( (loc1.type & 0xFF) == TYPE_FLOAT)
{
}
== has higher precedence int C than the & operator. So what was happening is the C compiler was comparing 0xFF to TYPE_FLOAT and 'anding' it with loc1.type. When I wanted it to 'and' it first, then compare. Correcting the typo was all that was needed.
Paul.