FreeBASIC 1.08 Development

[fxm]

Yes a new field has been added in the array descriptor structure which can hold the flag:
Const FBARRAY_FLAGS_FIXED_LEN = &h00000020 '' array points to fixed-length memory

See FBARRAY (array descriptor structure and access).


[edit]
Sorry, the question was not for me!

[MrSwiss]

Sorry fxm, the question is to coderJeff (and/or developers) ...

[dodicat]

fxm
I don't see any of these constants in my fbc-int/array.bi, and I have the official build 1.07.1.
Would it be worth including inserting an element in a fixed length array, thus popping off the upperbound one?
(Probably not, too much convolution)
My version (not using memcpy/move).

Code: Select all

'#define VarLen

#macro arrayinsert(a,index,insert)
    If index>=Lbound(a) And index<=Ubound(a)+1 Then
        Var index2=index-Lbound(a)
        #ifdef VarLen  '' or some way to get whether the array is static or dynamic
        Redim Preserve a(Lbound(a) To  Ubound(a)+1)
        #endif
        For x As long= Ubound(a) To Lbound(a)+index2+1 Step -1
            Swap a(x),a(x-1)
        Next x
        a(Lbound(a)+index2)=insert
    End If
#endmacro


dim as string s(1 to 10)

for n as long=1 to ubound(s)
    s(n)=str(n+rnd)
next n
for n as long=1 to ubound(s)
    print n,s(n)
next n
print
arrayinsert(s,3,"hello")
for n as long=1 to ubound(s)
    print n,s(n)
next n

sleep 

[fxm]

I don't see any of these constants in my fbc-int/array.bi, and I have the official build 1.07.1.

Only from fbc version 1.08.

[coderJeff]

I think I found the discussion is here: Array Descriptor (Split from WIki Improvements)
When bugs get assigned a ticket number I track it by that number. If I did have some test cases prepared, it's lost somewhere on my hard drive.

If I understand correctly: this fix to ERASE whould now be rather trivial (returning ERROR if array is NOT dynamic), whith the new array descriptor?

Yes, correct. The new array descriptor should make the check easy. But it was just first step, and now I can't remember if I did any work on it. lol. :)

@dodicat,
as fxm, already noted, fbc-1.08 has a new field in the array descriptor
fbc 1.08: https://github.com/freebasic/fbc/blob/m ... t/array.bi
fbc 1.07: https://github.com/freebasic/fbc/blob/f ... t/array.bi

The new field in the array descriptor will break binary compatibility any precompiled binary using arrays (so, looking forward to that). But there was no other way to track it through the run-time since array descriptor can be dynamic object create at run-time or static object created at compile time.

[jj2007]

Yes 'memcpy' may induce an undefined behavior although the compiler can easily determine in which direction to copy so as not to overlap (and it usually does), but it may also depend on the optimizations applied.
'memmove' guarantees everything.

So replace 'memcpy' (the second only in my code) by 'memmove' is safer.

Confirmed: replacing the 'middle' one is sufficient to make Gcc behave.

[fxm]

Thanks.
I have completely updated my original post including the code (viewtopic.php?p=260732#p260732).

[coderJeff]

Likewise with REDIM, a runtime error (with -exx) will come in handy if you try to resize a static array passed to a procedure, instead of doing nothing without saying anything.

If I understand correctly: this fix to ERASE whould now be rather trivial (returning ERROR if array is NOT dynamic), whith the new array descriptor?

Yes, correct. The new array descriptor should make the check easy. But it was just first step, and now I can't remember if I did any work on it. lol. :)

Turns out it was more messing around than I thought, I hadn't done any work on it, but now it's done. I wrote many tests, so hopefully no troubles with this update.
ERASE will clear the array if static (fixed length), and free memory if it is dynamic. Should correctly handle plain arrays, string arrays, object arrays.
REDIM will throw a run time error if attempting to resize a static array.

This update changes the rtlib API for arrays, what fbc itself uses. Take care with the chicken-egg problem. 1) Build compiler, 2) Build rtlib, 3) rebuild compiler. If that fails because you only have one (dev) copy of fbc, you'll need a previous version of fbc to rebuild fbc-1.08.

[MrSwiss]

Hi coderJeff,

great show, should start some fireworks to celebrate (unfortunately only allowed at specified days).
I've also seen your recent changes in: ../inc/fbc-int/*.bi (I'll try them a.s.a.p.).
Especially memory.bi looks very promissing (even if EXPERIMENTAL).

[fxm]

I've also seen your recent changes in: ../inc/fbc-int/*.bi (I'll try them a.s.a.p.).
Especially memory.bi looks very promissing (even if EXPERIMENTAL).

You can also use fb_memcopy, fb_memmove and fb_memcopyclear in the global namespace (directly accessible), which are equivalent, except for the addresses passed by reference instead of by value.

[jj2007]

Code: Select all

#Include "windows.bi"	 ' Ok
#Include "commctrl.bi"	' not ok, needs inc\win\commctrl.bi or full path

I've stumbled over this problem with my Windows GUI template (and I found some more inconsistencies, but that's another story).

Ideally, no paths should be necessary to find standard includes, and it should not be necessary to fumble environment variables. So I made some tests assuming that FBC.exe would scan the FreeBasicMainFolder\inc directory and all of its subdirectories.

My installation has 1695 *.bi files, and it takes roughly 10 milliseconds on my trusty old Core i5 to load their paths into a string array. It takes another 10...80 microseconds to find the full path of ...\FreeBasic\inc\win\commctrl.bi inside that array.

To facilitate development, especially for n00bs, fbc.exe could check if there is a backslash in the include path, and if not, find out where the matching *.bi file sits.

[coderJeff]

Code: Select all

#Include "windows.bi"	 ' Ok
#Include "commctrl.bi"	' not ok, needs inc\win\commctrl.bi or full path

I've stumbled over this problem with ...

Literally, "inc\" or full path not required. "inc\" will only work(*) if current working dir same as fbc executable. Prefer if you stop misinforming users that "inc\" or full path is required.

Otherwise,

Code: Select all

#include "windows.bi"   '' for windows.bi (includes several win/*.bi files by default)
#include "win/*.bi" '' for all other windows related .bi files

(*) only for 'standalone' version of fbc where include files are in "./inc" folder. See Normal vs Standalone

[jj2007]

Prefer if you stop misinforming users that "inc\" or full path is required.

I've corrected my post three days ago. Here is what the FB manual says on #include, it's really crystal clear:

For relative paths, or where no path is given at all, the include file is search for in the following order:

Relative from the directory of the source file

Relative from the current working directory

Relative from addition directories specified with the -i command line option

The include folder of the FreeBASIC installation (FreeBASIC\inc, where FreeBASIC is the folder where the fbc executable is located)

Maybe a little example would help n00bs like me to understand it better?

Code: Select all

#Include "windows.bi"   ' it's a Windows application
#Include "win\commctrl.bi" ' we need common controls, too
...

[fxm]

Out of respect with the author of the first post, and therefore the creator of the thread, I am against changing its title, so I am just putting the original title back here.

[jj2007]

Well done, fxm. I had not noticed that the forum software keeps the changed title. Admins might move the "Simplify includes" part to a new thread, though.