I see what you mean about a proper Judy wrapper.  My goal was to implement std::map, rather than to best wrap Judy.

I also just realized that Aleksey Cheusov has already done the same thing:

However Aleksey's implementation does not appear to support JudySL, and instead handles string maps with a hash function.

I will continue to maintain my version at:


--- On Wed, 2/9/11, john skaller <> wrote:

From: john skaller <>
Subject: Re: Future
To: "Justin Foutts" <>
Cc: "judy" <>
Date: Wednesday, February 9, 2011, 4:06 PM

On 10/02/2011, at 8:33 AM, Justin Foutts wrote:

> Hi John,
> Thanks.  Great points.
> Yes there is no error handling :)  In my own philosophy data-structures should assert or throw if they detect internal corruption and crash on null dereference if malloc returns zero.

Generally I agree. However, you still need the error flag because some Judy functions require
you to examine it for normal operation: I think JudyByCount or something.

Also, you need the error code to be able to throw something meaningful,
in fact you should make a wrapper for the error code and throw that.

> Sorry I'm still using the macros :/.  Should I upgrade my Judy to the new small implementation?

Don't know what that is. Just expand the macros by hand. Macros suck.
So do C++ references: generally pointers should be used instead.
Same reason: they hide when a variable is required to be an lvalue.

> Most of std::map is implemented below.  I am using the code as a drop in replacement by changing a few typedefs.
> Yes the STL iterator model does not fit Judy perfectly.

If I were doing this, the first thing I would do would be to make a *lightweight* wrapper.

That is, I'd implement the Judy C functions in C++ *exactly* the same signatures
*except* that the array variable and error is replaced by a C++ class.

Eg instead of

   Judy1First(array, key, error)

you'd have

   array->Judy1First(key, error)

The array is the object now. The point of this wrapper is that there's nothing to learn
to use it, all the Judy docs are still applicable (except that the array argument
is now a class and the functions are method).

There is the issue whether to put the error in the class or not. If you don't,
you have to provide it everywhere, but the class is then exactly one pointer
size, and its compatible with a C Judy array so you can actually cast between them.

Otherwise, you could eliminate the error by throwing it: that gets rid of the variable
easily :)

> Great suggestion regarding boost::enable_if.  I am still trying to figure out how it works :)

It uses a side-effect that certain constructions can fail to compile without error.
I think this arose from smart pointers: you can use some methods of a class when
other method can't compile. That's allowed.

There's a name for it, SNAFE or something.

john skaller