John:

Oops, forgot to get removed from documentation, thanks for
the info.

Future versions of Judy will not have error structures as
part of the calling parameters in many of the routines that do
not modify the array (tree).  Errors handling is a pain to figure
out while your thought is in program flow and often overlooked.
That is one of the reason I came up with the Macro interface
(JL*() and J1*() etc).  The only reason they were originally
put in was to detect corruptions in the array(tree).  The Macro
interface allows you to change the way errors are handled
without making large changes to the code.

On a different subject, you are not the only one to critique the
API to Judy.  The API was a result of many discussions and
nobody was ever happy with it.  So far I have not received a suggestion (with complete semantics) on a better way to do it.
(Every challenge I have offered has been ignored).

It has been on my wish-list for years to do a "thread-safe"
version of Judy.  That would require different semantics to the
Judy API (you can't have pointers to the "Value" area outside
a potential lock or modification of the array by some other
thread.)  Your help on this would be appreciated, especially
for C++.  None of the original Judy team used C++.

On still another subject,  I have wrestled many hours on the
PPvoid_t vs Pvoid_t  semantics to specify the "name" of the
Judy array.  The PPvoid_t is primarily necessary to allow the
"Array of Array" (I.E. the concept that a NULL pointer allocates
another Judy array -- such a used in JudySL, JudyHS etc).
It is absolutely necessary that the delete code be able to NULL
that pointer when the last element is removed or chaos would result.  Also since it is possible in some applications for
millions of very small arrays to exist, it is very important for
the memory efficiently to be good for very small arrays (< 10
indexes).  For JudyLIns() to be able to modify that pointer to
a different malloced piece of RAM is a big help.

I must admit that when the API was invented, C++ was not a
big part of the decision (I did not know the semantics for PPvoid_t and Pvoid_t was different than for C.)  The macro
interface was supposed to help programmers avoid that tar pit
when initially learning how to program with Judy.  I was hoping
the using PPvoid_t would stand out in the programmers mind over void**.

Thanks for your interest,
Doug Baskins

P.S. make sure you are using 1.0.4 or greater because there
is a bug in JLN().


skaller <skaller@users.sourceforge.net> wrote:
Docs say:

PPvoid_t JudyHSGet(Pcvoid_t PJHS, void *Index, Word_t Length, PJError_t
PJError);

but the header file says:

extern PPvoid_t JudyHSGet( Pcvoid_t, void *, Word_t);

and the source agrees .. a bit weird, no errors on this function..

--
John Skaller
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Judy-devel mailing list
Judy-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/judy-devel



Doug Baskins <dougbaskins@yahoo.com>