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!
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
Only from fbc version 1.08.dodicat wrote:I don't see any of these constants in my fbc-int/array.bi, and I have the official build 1.07.1.
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. :)MrSwiss wrote: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?
Confirmed: replacing the 'middle' one is sufficient to make Gcc behave.fxm wrote: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.
fxm wrote: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.
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.coderJeff wrote: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. :)MrSwiss wrote: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?
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.MrSwiss wrote: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).
Code: Select all
#Include "windows.bi" ' Ok
#Include "commctrl.bi" ' not ok, needs inc\win\commctrl.bi or full path
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.jj2007 wrote:I've stumbled over this problem with ...Code: Select all
#Include "windows.bi" ' Ok #Include "commctrl.bi" ' not ok, needs inc\win\commctrl.bi or full path
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
I've corrected my post three days ago. Here is what the FB manual says on #include, it's really crystal clear:coderJeff wrote:Prefer if you stop misinforming users that "inc\" or full path is required.
Maybe a little example would help n00bs like me to understand it better?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)
Code: Select all
#Include "windows.bi" ' it's a Windows application
#Include "win\commctrl.bi" ' we need common controls, too
...