Freebasic 1.20.0 Development

[fxm]

Why not just use:
#define C chr(0)

[fbfans]

Why not just use:
#define C chr(0)

Because const has higher operational efficiency

[fxm]

Why not just use:
#define C chr(0)

Because const has higher operational efficiency

Indeed, "Constants" have similar visibility rules than variables for Namespace blocks, Type blocks, and compound block statements, while "Defines" are only scoped inside compound block statements.

[coderJeff]

For fbc version 1.20.0 only:
- Can you correct the cases '2.1 pass' and '2.2 pass' at least ?
(the '0' of the terminal character of zstring does not play its role of end)
- Could you correct other 'NON OK' cases ('return' cases) ?
- Note: Only the cases '1.1' and '1.2' are compatible with the use of Chr(0) by user, and the results are similar (only the case '1.2 return' fails).

Thank-you for the test cases. I am overlooking (ignoring) chr(0) issues for the moment.

Tricky, but I think '2.1 pass' and '2.2 pass' can be fixed.

For the 'return' cases of '(func(arg))=expr', it seems would be impossible to track the association between argument having one type and the return of func having another type. '(func(arg))=expr' ===> 'tmp = func(arg) : tmp = expr'. Fixing 2.1 pass and 2.2 pass may change my opinion.

[fxm]

For fbc version 1.20.0 only:
- Can you correct the cases '2.1 pass' and '2.2 pass' at least ?
(the '0' of the terminal character of zstring does not play its role of end)
- Could you correct other 'NON OK' cases ('return' cases) ?
- Note: Only the cases '1.1' and '1.2' are compatible with the use of Chr(0) by user, and the results are similar (only the case '1.2 return' fails).

Thank-you for the test cases.....

I improved my code (to test the 'Byref' passing/returning to/from a function) without changing the output view:

The 2 utility Sub's are transformed into macros and only the two main functions remain in the form of procedures (because, for a most reliable test possible of parameter passing, the verification part must not use any parameter passing).

[coderJeff]

I improved my code (to test the 'Byref' passing/returning to/from a function) without changing the output view:

The 2 utility Sub's are transformed into macros and only the two main functions remain in the form of procedures (because, for a most reliable test possible of parameter passing, the verification part must not use any parameter passing).

Thank you. This fix is tricky - Just when I think I have a solution, it doesn't work out. However, it touches on the areas where I would like to go next and therefore is a worthwhile effort to continue, but not today. As shown in another post, some uses of wstring result in memory leaks. This is related to same areas of the compiler as your test cases passing string type arguments to string type parameters where the types do not exactly match. fbc needs to generate some code before the call and after the call to manage the differences.

I have some other changes and bugfixes I am going to push, so should see those soon.

[fxm]

@Jeff,

Typo in :

Commit [d38178]

fbc: allow UDT operators to support array() parameters

- add sf.net feature request # 273 285: Let overloads should support
array parameters; allow UDT operators (LET, +=, etc) to support
array parameters
.....

changelog.txt

+- sf.net feature # 273 285 fbc: allow UDT operators (LET, +=, etc) to support array parameters

[fxm]

Should we now disallow 'SIZEOF(array_name)' and even more so 'LEN(array_name)' ?

Example:

Code: Select all

#if __FB_VERSION__ >= "1.09.0"
    #include once "fbc-int/array.bi"
#endif

Scope
    Dim As Zstring * 5 s(1 To...) = {"1", "12", "123"}

    Print "SIZED ARRAY : 'Dim As Zstring * 5 s(1 To...) = {""1"", ""12"", ""123""}'"
    Print "Len(s(1))", "Len(s(2))", "Len(s(3))", "Len(s)", "Len(Typeof(s))"
    Print Len(s(1)), Len(s(2)), Len(s(3)), Len(s), Len(Typeof(s))
    Print "Sizeof(s(1))", "Sizeof(s(2))", "Sizeof(s(3))", "Sizeof(s)", "Sizeof(Typeof(s))"
    Print Sizeof(s(1)), Sizeof(s(2)), Sizeof(s(3)), Sizeof(s), Sizeof(Typeof(s))
    #if __FB_VERSION__ >= "1.09.0"
        Print "FB.Arraylen(s())"
        Print FB.Arraylen(s())
        Print "FB.Arraysize(s())"
        Print FB.Arraysize(s())
    #endif
    Print
End Scope

Scope
    Dim As Zstring * 5 s()
    
    Print "UNSIZED ARRAY : 'Dim As Zstring * 5 s()'"
    Print "Len(s(0))", "Len(s)", "Len(Typeof(s))"
    Print Len(s(0)), Len(s), Len(Typeof(s))
    Print "Sizeof(s(0))", "Sizeof(s)", "Sizeof(Typeof(s))"
    Print Sizeof(s(0)), Sizeof(s), Sizeof(Typeof(s))
    #if __FB_VERSION__ >= "1.09.0"
        Print "FB.Arraylen(s())"
        Print FB.Arraylen(s())
        Print "FB.Arraysize(s())"
        Print FB.Arraysize(s())
    #endif
    Print
End Scope

Sleep

• Code: Select all

  SIZED ARRAY : 'Dim As Zstring * 5 s(1 To...) = {"1", "12", "123"}'
  Len(s(1))     Len(s(2))     Len(s(3))     Len(s)        Len(Typeof(s))
   1             2             3             5             5
  Sizeof(s(1))  Sizeof(s(2))  Sizeof(s(3))  Sizeof(s)     Sizeof(Typeof(s))
   5             5             5             5             5
  FB.Arraylen(s())
  3
  FB.Arraysize(s())
  15
  
  UNSIZED ARRAY : 'Dim As Zstring * 5 s()'
  Len(s(0))     Len(s)        Len(Typeof(s))
   0             5             5
  Sizeof(s(0))  Sizeof(s)     Sizeof(Typeof(s))
   5             5             5
  FB.Arraylen(s())
  0
  FB.Arraysize(s())
  0
  

Already there is a note (warning) in the documentation on the use of 'Sizeof(array_name)' recommending against its use, but rather the use of 'Sizeof(array_element)'.

But even more the use of 'Len(array_name)' which is allowed (for the moment without a note in the documentation) is even more misleading because it actually always returns the value of 'Sizeof(array_element)' !

In addition, at the array level, there are now (since fbc version 1.09.0) the functions 'FB.ArrayLen()' and 'FB.ArraySize()' which are, for their part, consistent with their names.

I think it is now time to disallow these 2 syntaxes : 'Sizeof(array_name)' and 'Len(array_name)'.

[coderJeff]

I don't think I have much thought about LEN(array) and SIZEOF(array).

But even more the use of 'Len(array_name)' which is allowed (for the moment without a note in the documentation) is even more misleading because it actually always returns the value of 'Sizeof(array_element)' !

Yes, I see in compiler source 'LEN(array)' is handled as 'SIZEOF(array)'

In addition, at the array level, there are now (since fbc version 1.09.0) the functions 'FB.ArrayLen()' and 'FB.ArraySize()' which are, for their part, consistent with their names.

These will work with both dynamic and fixed-size arrays. It should be noted that fixed size arrays do not normally have an array descriptor, but fbc will allocate one just to satisfy the call to 'fb.ArrayLen' and 'fb.ArraySize', and the calculation is only made at run-time.

I think it is now time to disallow these 2 syntaxes : 'Sizeof(array_name)' and 'Len(array_name)'.

No doubt will break some user code ... so if we are going to possibly break source level compatibility, perhaps we can consider something better.

The size properties of fixed-size arrays are compile-time constants and therefore dimensions and sizes the array can be used in constant expressions at compile time (i.e. constant folding optimizations).

Perhaps we could allow something like this for fixed-size arrays?

Code: Select all

dim a(3 to 5, 7 to 11) as long

const a01 = sizeof(typeof(a))   '' 4    - size of element  
const a02 = sizeof(a)           '' 60   - size of entire fixed array   
const a03 = len(a)              '' 15   - number of elements in fixed array
const a04 = lbound(a,0)         '' 1    - lower bound of dimensions
const a05 = ubound(a,0)         '' 2    - upper bound of dimmensins
const a06 = lbound(a)           '' 3    - lower bound first dimension
const a07 = ubound(a)           '' 5    - upper bound first dimension
const a11 = lbound(a,1)         '' 3    - lower bound, first dimenstion
const a12 = ubound(a,1)         '' 5    - lower bound, first dimenstion
const a21 = lbound(a,2)         '' 7    - lower bound, second dimenstion
const a22 = ubound(a,2)         '' 11   - lower bound, second dimenstion

I suppose for dynamic (var-len) we would then throw an error, or call fb.ArrayLen and fb.ArraySize at runtime, thereby building these functions in to fbc.

[fxm]

I proposed to downright prohibit 'SIZEOF(array_name)' and 'LEN(array_name)' to make it easier for the user to upgrade existing code:
- at each compile error message on such keyword usage, replace 'array_name' with 'Typeof(array_name)'.

But what you propose (reestablishing their correct logical values to such keyword usages) is the best from the FreeBASIC language point of view, but will make the task of upgrading existing code more difficult for the user (because no compile errors).

[coderJeff]

OK, I understand. I agree, this change it would be worthwhile to have some method to do both. When we made the big changes for name lookups we temporarily added a #pragma to allow old name lookup logic. We could do something similar for len/sizeof but to do 1 of 3 things: 1) old behaviour, 2) error to identify code that needs to be updated, 3) new behaviour. Perhaps the combination of a new but temporary #pragma plus a permanent change to `-deprecated` command line option (the usage of -deprecated must be obsolete by now) will allow for an upgrade path for source code.

[fxm]

Other example:

Code: Select all

Dim As Zstring * 5 array(...) = {"", "1", "12"}

Print Len(array)             '' 5   but should be 3    ( Ubound(array) - Lbound(array) + 1 )
Print Sizeof(array)          '' 5   but should be 15   ( (Ubound(array) - Lbound(array) + 1) * Sizeof(Typeof(array)) )
Print Len(Typeof(array))     '' 5
Print Sizeof(Typeof(array))  '' 5
Print Len(array(0))          '' 0
Print Sizeof(array(0))       '' 5
Print Len(array(1))          '' 1
Print Sizeof(array(1))       '' 5
Print Len(array(2))          '' 2
Print Sizeof(array(2))       '' 5

[adeyblue]

At this point why don't you just audit the language for all the crap, broken and obtuse things, gut them, and rebuild them however you like with no regards for what went before (or leave them out altogether) and call it FreeBasic 2.0.

[Imortis]

At this point why don't you just audit the language for all the crap, broken and obtuse things, gut them, and rebuild them however you like with no regards for what went before (or leave them out altogether) and call it FreeBasic 2.0.

Because it is way more work that we can ask of one man doing the work in his free time. Don't get me wrong, I kind of like the idea, but wouldn't ask anyone to do it.

[paul doe]

At this point why don't you just audit the language for all the crap, broken and obtuse things, gut them, and rebuild them however you like with no regards for what went before (or leave them out altogether) and call it FreeBasic 2.0.

Second the motion here. Naturally, it's a lot of work for one person, but for progressing further it might prove worthwhile. And, less code is always a good thing, especially for a reduced dev team...