Re: array of JudySL arrays

[john s. <sk...@us...>]

On 23/05/2008, at 3:32 AM, Alan Silverstein wrote:
>>
> Array-of-array is the trickiest part of using libJudy.  You must pay
> close attention to pointer levels and types.  Here's an example from
> actual code that uses the macros to create JudySL -> JudySL -> Judy1.
> Dunno if this will help you or not.

>
>    subpp = (PPvoid_t) valuep; JSLI(valuep, *subpp, index2);
>    subpp = (PPvoid_t) valuep; J1S( rc,     *subpp, index3);
>
> The macros hide error handling and "conform" the signatures (parameter
> types), which makes this look very simple, but also requires the odd  
> use
> of PPvoid_t and then passing *subpp.  But it works -- very well -- and
> can be written very briefly.
>
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.

The actual C interface is slightly tricky but it is supremely LOGICAL.
For example JudyLIns "returns" the address of a created data slot,
and so does not actually insert any data into it: you have to deref the
returned address, but the key must be given by value. OTOH search
functions return the keys, so you have to give a pointer to where to
put the key. These properties are *unusual* but they're logical for
Judy because JudyL data is immobile (provided you don't delete the
associated key) and so the addresses are persistent.

For a C++ programmer the macro documentation is seriously bugged
because it fails to carefully state where an lvalue is required: in such
cases it is taking the address of the supplied expression. 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.

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.

Len: BTW: I do not understand why you would have an array of Judy  
arrays.
It's already an array..why not put everything in a single Judy array?
The fact you're using an array suggests the data is all of one type.
Is this thing a database key structure? [That would suggest one
Judy array per key ..]

--
john skaller
sk...@us...