Freebasic 1.20.0 Development
Re: Freebasic 1.20.0 Development
Why not just use:
#define C chr(0)
#define C chr(0)
Re: Freebasic 1.20.0 Development
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.
Re: Freebasic 1.20.0 Development
Thank-you for the test cases. I am overlooking (ignoring) chr(0) issues for the moment.fxm wrote: ↑Mar 25, 2024 17:00 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).
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.
Re: Freebasic 1.20.0 Development
coderJeff wrote: ↑Mar 29, 2024 16:05Thank-you for the test cases.....fxm wrote: ↑Mar 25, 2024 17:00 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).
I improved my code (to test the 'Byref' passing/returning to/from a function) without changing the output view:
Re: Freebasic 1.20.0 Development
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.
Re: Freebasic 1.20.0 Development
@Jeff,
Typo in :
Commit [d38178]
changelog.txt
Typo in :
Commit [d38178]
fbc: allow UDT operators to support array() parameters
- add sf.net feature request #273285: Let overloads should support
array parameters; allow UDT operators (LET, +=, etc) to support
array parameters
.....
changelog.txt
+- sf.net feature #273285 fbc: allow UDT operators (LET, +=, etc) to support array parameters
Re: Freebasic 1.20.0 Development
Should we now disallow 'SIZEOF(array_name)' and even more so 'LEN(array_name)' ?
Example:
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)'.
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)'.
Re: Freebasic 1.20.0 Development
I don't think I have much thought about LEN(array) and SIZEOF(array).
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?
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.
Yes, I see in compiler source 'LEN(array)' is handled as 'SIZEOF(array)'
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.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.
No doubt will break some user code ... so if we are going to possibly break source level compatibility, perhaps we can consider something better.I think it is now time to disallow these 2 syntaxes : 'Sizeof(array_name)' and 'Len(array_name)'.
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
Re: Freebasic 1.20.0 Development
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).
- 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).
Re: Freebasic 1.20.0 Development
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.
Re: Freebasic 1.20.0 Development
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
Re: Freebasic 1.20.0 Development
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.
Re: Freebasic 1.20.0 Development
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.
Re: Freebasic 1.20.0 Development
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...