On Sat, Nov 27, 2010 at 05:16:08PM +1300, Ralph Versteegen wrote: > 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.
Thank you for reminding me that valgrind can do that. You have knocked down the last bit of my objection. When you have the new arrays in, can you make a wiki page that describes the interface? That would help me in learning to use them myself. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
