Freebasic 1.20.0 Development

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
fxm
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Freebasic 1.20.0 Development

Post by fxm »

Why not just use:
#define C chr(0)
fbfans
Posts: 17
Joined: Nov 27, 2023 0:29

Re: Freebasic 1.20.0 Development

Post by fbfans »

fxm wrote: Mar 26, 2024 13:15 Why not just use:
#define C chr(0)
Because const has higher operational efficiency :D
fxm
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Freebasic 1.20.0 Development

Post by fxm »

fbfans wrote: Mar 26, 2024 14:13
fxm wrote: Mar 26, 2024 13:15 Why not just use:
#define C chr(0)
Because const has higher operational efficiency :D
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
Site Admin
Posts: 4323
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

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).
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
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Freebasic 1.20.0 Development

Post by fxm »

coderJeff wrote: Mar 29, 2024 16:05
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).
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:
fxm wrote: Mar 25, 2024 17:00 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
Site Admin
Posts: 4323
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

fxm wrote: Mar 30, 2024 16:40 I improved my code (to test the 'Byref' passing/returning to/from a function) without changing the output view:
fxm wrote: Mar 25, 2024 17:00 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
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Freebasic 1.20.0 Development

Post by 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
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Freebasic 1.20.0 Development

Post by 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
Site Admin
Posts: 4323
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

I don't think I have much thought about LEN(array) and SIZEOF(array).
fxm wrote: Apr 01, 2024 13:51 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
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Freebasic 1.20.0 Development

Post by 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
Site Admin
Posts: 4323
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by 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
Moderator
Posts: 12107
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Freebasic 1.20.0 Development

Post by 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
Posts: 300
Joined: Nov 07, 2019 20:08

Re: Freebasic 1.20.0 Development

Post by 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
Moderator
Posts: 1924
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Freebasic 1.20.0 Development

Post by Imortis »

adeyblue wrote: Apr 03, 2024 18:31 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
Moderator
Posts: 1732
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: Freebasic 1.20.0 Development

Post by paul doe »

adeyblue wrote: Apr 03, 2024 18:31 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...
Post Reply