http://lucidfusionlabs.com/svn/lflpub/lfapp/judymap.h
I have updated the code to use template partial specialization to unify the
string and word implementations into one judymap. And updated the integration
recommendations:
#ifdef USING_JUDY#define Map(K, V) judymap<K, V>#else#define Map(K, V) map<K,
V>#endif
By substituting "typedef Map(k, v) map_t" in place of "typedef map<k, v> map_t"
Judy can be used as a complete drop in replacement for std::map.
I happily use Judy for my default map implementation on Windows, Mac OSX, and
Linux.
However on iPhone I substitute EASTL's map.
Thanks,Justin
--- On Wed, 2/9/11, Justin Foutts <[email protected]> wrote:
From: Justin Foutts <[email protected]>
Subject: Re: Future
To: "john skaller" <[email protected]>
Cc: "judy" <[email protected]>
Date: Wednesday, February 9, 2011, 5:05 PM
John,
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:
http://judyhash.sourceforge.net/
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:
http://lucidfusionlabs.com/svn/lflpub/lfapp/judymap.h
Thanks,
Justin
--- On Wed, 2/9/11, john skaller <[email protected]> wrote:
From: john skaller <[email protected]>
Subject: Re: Future
To: "Justin Foutts" <[email protected]>
Cc: "judy"
<[email protected]>
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
[email protected]
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
-----Inline Attachment Follows-----
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
