John, > IMHO the "macros" are a serious fault, and should be moved to a > separate header. The macros are badly documented, and the underlying > C code is only barely documented. The use of void* makes it > especially confusing and defeats compiler error checking.
Yes, yes, I know... But it's up to Doug to revise this, if he chooses. (Every fault is obvious in hindsight!) Still, it's not the macros per se. I'm using libJudy a lot in paid work now, and it's great, and I chose to use the macros rather than the functions to hide unnecessary details. The pointer type issue is, I think, not directly related to the macro/function issue. > The actual C interface is slightly tricky but it is supremely LOGICAL. We did something right? :-) > A Judy array of any kind is always supplied as a VALUE where there are > no insert or delete operations, but an LVALUE (pointer) where there > are insert or delete operations, because in those cases the address of > the 'head' node can change so must be stored somewhere. True. > bottom line: if you understand the *functionality* each Judy function > provides and how it relates to the structure of a Judy array, you > don't need any documentation, you can DEDUCE how the interface must > actually be. Yeah, that sounds vaguely familiar from ~2001 when we designed the function API and debated the signatures. Alan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
