> void *judyx=NULL,*judyy=NULL;
> Word_t *px,*py;
> unsigned x,y;
> ...
> for(x=0,px = JudyLFirst(judyx, &x, NULL); px; px = JudyLNext(judyx, &x,
> NULL)) {
> for(y=0,py = JudyLFirst(*px, &y, NULL); py; py = JudyLNext(*px, &y, NULL)) {
> printf("x=%u, y=%u\n", x, y);
> ...
> }
> }
>
> This interface call is much simpler as the macros. You can agree that
> using this interface is more natural.
Right, that was my point. The macros don't lend themselves well to
for() loops, you end up writing while() loops...
>> "Judy-star" (as in Judy*()), along the lines of, JudyL()'s values are
>> long-words, etc.
> Where can i find this.
The code does not exist, sorry. There MIGHT (or might not) be some
discussion of it in the SourceForge documents. It never got past the
"what if" discussion stage.
I know, you could write your own wrapper functions to simulate this, but
it wouldn't be as nice as if libJudy could do it for you. The wrappers
would have to cover any form of call you needed -- insert, retrieve,
free...
Note well the difference between longer or variable-length KEYS
(indexes), the previously discussed topic -- also discussed
length-associated versus length-terminated strings or other indexes --
and longer or variable-length VALUES. Ultimately it would be nice to
have an API supporting both: "Map this M-bit key to an N-bit value."
> Actualy i'm using array-of-array of unsigned to emulate 64-bits ints.
Sure, that sounds reasonable... If you mean the keys/indexes are the
64-bit objects... If you are mapping from 64-bit to 64-bit, can you
just use the 64-bit versions of the Judy libraries?
> I don't know how Judy works internally, but i think you do a search
> first (like JudyGet) of parameter passed to JudyNext/JudyPrev and then
> return the next/prev element. With the cursor interface you can store
> the current pointers (tree path) in the structure and use this info at
> the next call (without a new search at each call).
Ah, OK. Well, of course libJudy internal data is volatile, as the
manual entries warn you. But in fact they only change upon insert,
delete, or free. You're right that each Next call starts with locating
the index in the tree... But it's important to note that for a
cache-smart algorithm like libJudy, the overhead time to do this after a
previous lookup is virtually zero. That's one reason we didn't worry
about giving you back some kind of quickref/"cursor" for the next call.
> I think the best way is that the caller copies their data into the
> returned valuep area. As actually done with the returned Word_t
> pointer.
OK.
Thanks,
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
