Array Copy

[John]

Hi bitvast,

Currently BaCon does not have such a function. But there is a way to work around it using the C function 'memcpy'. If we import it into BaCon it is possible to create a copy of an array without a loop.

BR,
Peter

Code: [Select]

PROTO memcpy ALIAS MEMCOPY

DECLARE array[5], copy[5] TYPE long

array[0] = 15
array[1] = 24
array[2] = 33
array[3] = 42
array[4] = 51

' We have to copy 5 times a long value
MEMCOPY(copy, array, 5*SIZEOF(long))

FOR x = 0 TO 4
PRINT copy[x]
NEXT


There is no limit on the number of indices. You can use as many as you like. Also there is no limit on the index values other than the index values have to be integer and that memory may limit the array sizes. Positive, negative or zero integers can play the role of an index. Whenever you access an array element or assign a value to that ScriptBasic automatically checks if the referenced array element exists or not and adjusts the array if necessary. An array element may contain any of the SB types. (long, double, string or another array) With the SB Tools extension module, arrays can be converted to strings and restored back to arrays from the string. The T module allows you to create an XML representation of your array structure as a string.

I think ScriptBasic's array/matrix feature set is one of the language's strong point.

Arrays in ScriptBasic

[Mike Lobanovsky]

John,

The gist of Peter's suggestion is to use memcpy() available in the C runtime (and every MS Windows kernelXX.dll too) to copy an array's entire contents to another array in one go rather than atomizing the process into indiviadual element assignments. memcpy()-ing will do it much, much faster.

However, such a trick will only work with C-compliant arrays. memcpy() expects the array elements to strictly follow one another in the process memory and accepts a total number of bytes to copy as its last argument.

According to ScriptBasic's User Guide, arrays that you're calling "standard" and "associative" are implemented as arrays of poniters or perhaps even as linked lists with elements allocated at random locations in the process memory. Such arrays are not C- or WinAPI-compliant though they will serve their purpose perfectly well when used in native language statements.

For the same reason, your emulation of user-defined Types and/or Unions will only work with the language's standard vocabulary. You won't be able to use such structures in a call to third-party code.

FBSL's Types and Unions have controllable alignment and are strictly C-compliant. FBSL's strong-typed static arrays (a.k.a. fixed-size arrays) are C-compliant too. FBSL's Variant arrays and anonymous arrays (a.k.a. unnamed arrays) are C-compliant with each element being 16 bytes long (that's the length of one FBSL Variant structure which is also COM-compatible). FBSL's dynamic arrays (a.k.a. growable arrays) are implemented as doubly-linked lists and are therefore not C-compliant.

FBSL has also a native MemMove() function that ensures correct bit block copy even within overlapping memory areas.

[John]

Correct. C functionality is performed in SB extension modules and only a high level interface to external resources is provided. SB tries to maintain a traditional BASIC syntax for the user and SDK/API wrapping is left to extension modules. A simple DECLARE makes the resource available to the SB script.