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 > 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 _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
