On 27 November 2010 16:40, James Paige <[email protected]> wrote: > On Fri, Nov 26, 2010 at 11:34:07PM +1300, Ralph Versteegen wrote: >> QB/FB arrays are the worst designed feature in any programming >> language I know of (except for *possibly* some of the stuff in MUMPS >> http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx) >> (A quick rant: >> -not 1st class: you can't return them or even place them in types! >> -uninitialised dynamic arrays are indistinguishable and will crash >> your program. You must initialise them. >> -to figure out whether an array is static or dynamic you have to check >> the dialect, the OPTION statements in effect, and whether the index in >> the DIM statement is a variable or a constant >> -unlike the rest of the language, arrays aren't properly statically >> typed: the compiler will let you REDIM a static array and crash your >> program >> -zero-length arrays not supported >> -almost zero support for arrays in the standard library: just REDIM, >> LBOUND, UBOUND, ERASE. You can't even copy an array, or get a pointer >> to the array descriptor. >> ) >> A couple days ago I had finally had enough, and started on a library >> of array utility functions written in C, effectively extending libfb >> (addressing just the last 2 complaints above). The idea is they act on >> 1D arrays starting at -1, with the -1 element ignored so we can have >> zero-length arrays. Here are a few prototypes (you use a macro to >> declare overloaded versions for each type T you want to support): >> >> declare sub array_copy overload (array() as T, source() as T) >> 'Append an element or an array >> declare sub array_append overload (array() as T, value as T) >> declare sub array_append overload (array() as T, appendlist() as T) >> 'Removes index n from array >> declare sub array_delete overload (array() as T, byval n as integer) >> 'Insert a value/array at an index. Negative indices count from end >> (-1 appends) >> declare sub array_insert overload (array() as T, byval insertbefore >> as integer, value as T) >> declare sub array_insert overload (array() as T, byval insertbefore >> as integer, insertlist() as T) >> declare sub array_sort overload (array() as T) >> >> A couple nights into implementing them (expected to be done by now, >> but the libfb array code is horribly over-complex, eg. there are about >> 8 different implementations of REDIM) I suddenly realised: if FB >> arrays are so horrible, why am I using them at all? It would be FAR >> easier to create a new array structure and write an extensive library >> for it in C. The code would be much simple, faster, there'd be no >> worry about keeping up with changes to libfb, and I can fix more of >> the problems with FB arrays. The disadvantages would be having to >> manually allocate and free them, and no bounds checking when compiled >> with -exx. However when we finally switch to -lang fb we'll get those >> back. >> >> I would implement these arrays like this: array objects would just be >> pointers of the desired type, which can be indexed like a normal >> pointer. The array descriptor (containing length and other stuff) >> would be stored before the 0th element. These pointers can of course >> be embedded in UDTs or returned from functions. Because code should be >> self documenting, to avoid confusion with normal pointers I'd do this: >> #define array ptr >> Example code: >> >> FUNCTION generate_test_array() as string array >> DIM arr as string array >> array_new arr ' allocate zero-length array >> array_append arr, "test" >> array_append arr, array_of("foo", "bar") ' I think I'll manage this
Drat, variadic macros were only implemented in August, they're not in any stable release. >> array_sort arr >> RETURN arr >> END FUNCTION >> >> DIM arr as string array >> arr = generate_test_array ' Can only do this as arr is a NULL pointer >> array_set arr, generate_test_array ' Safe way to assign an array >> print arr[length(arr) - 1] >> array_free arr >> >> So the question to the other developers is: would you rather have a >> library for FB arrays, or use these new arrays? I am definitely in >> favour of the new arrays, and would start using them and, where >> beneficial, converting code I'm working on to use them as soon as >> possible (tomorrow?). > > I would miss the loss of -exx bounds checking. That one is fairly > important to me... but other than that, FB arrays do indeed suck, and > the inability to have variable-length arrays as members of types has > always been a thorn in my side. > > --- > James Paige Bounds checking is nice, but to be honest I can't even remember the last time I saw an out-of-bounds error. On the other hand I have seen a couple out-of-bounds warnings thrown by flexmenu and others, and some crashes due to reading off the end of manually allocated memory :) Also, you will be able to run with valgrind to get the same effect. And I'm not going to go crazy converting all our arrays (until we switch to -lang fb, anyway), so there won't be very many unchecked array accesses. There don't seem to be any serious objections, so I guess I'll go with all-new arrays. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
