Bug Reports

[na_th_an]

Wow!!! This is definitely renaissance!!!

Sure. Noticed how many QB legends are making appearance? Angelo, Jonge...

[aetherfox]

I don't think that fB should start adding features from other languages...like Python...

It's a BASIC derivative, and the idea is to have a 32-bit BASIC language that most closely represents good old Quick Basic. There shouldn't (now) be the tendency to say "Hey, C/C++/ObjPascal/(why)Python does this, we should too."

[Z!re]

This code crash:

Code:

Sub LUT_Init (SINPrecission As uinteger = 2, COSPrecission As uinteger = 2, SQRRange as uinteger = 262144, SQRPrecission as uinteger = 1)
    If Initialized = 1 Then exit Sub
    Initialized = 1
    SINp = 10 ^ SINPrecission
    COSp = 10 ^ COSPrecission
    SQRp = 10 ^ SQRPrecission
    SQRr = SQRRange
    
    dim shared SIN_LUT(360*SINp) As LUT_Type
    dim shared COS_LUT(360*COSp) As LUT_Type
    dim shared SQR_LUT(SQRr*SQRp) As LUT_Type
    SQRr = SQRRange*SQRp   '# <- This row crash
End Sub

This code works:

Code:

Sub LUT_Init (SINPrecission As uinteger = 2, COSPrecission As uinteger = 2, SQRRange as uinteger = 262144, SQRPrecission as uinteger = 1)
    If Initialized = 1 Then exit Sub
    Initialized = 1
    SINp = 10 ^ SINPrecission
    COSp = 10 ^ COSPrecission
    SQRp = 10 ^ SQRPrecission
    SQRr = SQRRange
    
    dim shared SIN_LUT(360*SINp) As LUT_Type
    dim shared COS_LUT(360*COSp) As LUT_Type
    dim shared SQR_LUT(SQRr*SQRp) As LUT_Type
    SQRr = SQRr * SQRp
End Sub

Any ideas?

[v3cz0r]

What you mean by crash, that happens at runtime or the compiler crashes?

I couldn't reproduce the error, but you shouldn't be allowed to use DIM|REDIM and then SHARED inside procs, patch will be next release..

[relsoft]

How about static asn in.

Static dim array(1000) as integer


We may need those in glvertex arrays. :*)

[Z!re]

What you mean by crash, that happens at runtime or the compiler crashes?

I couldn't reproduce the error, but you shouldn't be allowed to use DIM|REDIM and then SHARED inside procs, patch will be next release..

Crash at runtime, and I think it's good that you can dim shared, as this enables you to dim inside DLLs.

The dims should be redims, but i changed it for debug purpose.

And having the ability to redim a shared array inside a function is a good thing, imo.


Anyways, the problem is when I use:
blah as type = value

And then try to use blah in math. Compiles fine, but crash on runtime.
And this is a DLL.

[v3cz0r]

Rel: you can use STATIC with arrays too, they are allowed with FB,

Code:

static array(1000) as integer

will work.

Z!re: the "right" way would be:

Code:

dim shared myarray() as mytype

at module level.

and

Code:

redim myarray(...) as mytype

at proc level.

That's how it's done in QB.. a DIM SHARED inside a function will open it to memory leaks as that array is "impossible" to erase implicitly or explicitly in other routines later. When you create a dynamic *local* array inside a proc the compiler will erase them automagically when the proc finish - if you are DIM'ing a shared array that won't be done, it's up the the user to call ERASE at a shutdown() proc or such.

[relsoft]

How about "WITH" for us lazy bastards. VB has it so why not FB?

Code:

With StructureType

     .x= 1
     .y=2
     .x =300
     .id = "Blah"

End With

[na_th_an]

How about "WITH" for us lazy bastards. VB has it so why not FB?

Code:

With StructureType

     .x= 1
     .y=2
     .x =300
     .id = "Blah"

End With

Count my vote for this Another niceness from VB. You added BYREF and OPTION EXPLICIT, so why not?

[v3cz0r]

Look at the CVS ;)

2 days v1ctor WITH added

No multiple var's WITH, as they are bad pratic, imo..