Ah yes, you're right. :)  A "complete drop in replacement" given that "the key 
and value parameters meet the restrictions (sizeof(K) <= sizeof(void*) || 
K==string) && sizeof(V) <= sizeof(void*)"
The majority of my maps meet this criteria, however when they do not I fall 
back to an STL implementation.
Also the restrictions are now statically asserted by the trick you recommended.
Thanks,Justin 


--- On Thu, 2/10/11, john skaller <[email protected]> wrote:

From: john skaller <[email protected]>
Subject: Re: Future
To: "Justin Foutts" <[email protected]>
Cc: "judy" <[email protected]>
Date: Thursday, February 10, 2011, 5:31 PM


On 11/02/2011, at 12:05 PM, Justin Foutts wrote:

> 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.


Well, not quite: you still have a restriction on sizeof(Y).

You can get rid of that: if Y is too big, you can just clone it onto the heap 
and store a pointer.
This shouldn't be done automatically: should be another class (JudyLPtr or 
something).

Clearly there's an issue here if you delete something, you have to also delete 
the 
heap object.

Although Felix generates C++ it also uses a GC, so if that were used by Felix 
you'd
actually NOT want to delete anything (the GC would do it automatically which is 
much
better because there's no issue of invalidating pointers).

Rather, the GC needs a way to scan Judy arrays, which it can do now.
In fact Felix can't can STL containers yet, but it can scan Judy arrays :)


--
john skaller
[email protected]







      
------------------------------------------------------------------------------
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

Reply via email to