RE: Judy API design

[Toni C. <tca...@to...>]

Sorry: that should read:

//In Judy header to declare the type
DECLARE_HANDLE(HJUDY);

//Declare my variable and init to NULL
HJUDY hJudy =3D NULL;

DWORD* pValue;
int Index =3D 1;

//Insertion
//NOTE: if I passed 'hJudy' or anything BUT '&hJudy', this line
//      would not compile
pValue =3D (DWORD*)JudyLIns(&hJudy, Index);


Regards,
=A0
Toni.
=A0
----
Toni Cassisi
Tovica Ltd
http://www.tovica.com
Tel: +44 (0) 7971 874 054
Skype: tcassisi
IM: AOL/Yahoo/MSN: tcassisi



-----Original Message-----
From: jud...@li...
[mailto:jud...@li...] On Behalf Of Toni =
Cassisi
Sent: 17 January 2008 15:29
To: aj...@fr...; dou...@ya...
Cc: jud...@li...
Subject: RE: Judy API design

Alan, Doug:

RE: Comments on the lack of type safety in the Judy API=20

The Windows API is a C-API that covers many things including data types =
like
(thread-safe) lists. As such, it is a good example of how to handle new
structures in an old (C) style way.

>From winnt.h:
#define DECLARE_HANDLE(name) \=20
   struct name##__ { int unused; }; \
   typedef struct name##__ *name

>From a C-style Zip wrapper:

DECLARE_HANDLE(HZIP);

//Return a type-safe pointer to the internal "Zip" one
HZIP CreateZip(const TCHAR * UNIQUEPTR fn,=20
              const char * UNIQUEPTR password);

//The following will ONLY accept an HZIP; void* or HZIP*,
//or any other mistakes will be caught by the compiler
DWORD ZipAddFolder(HZIP hz, const TCHAR * UNIQUEPTR dstzn);

Now, if you replace the DECLARE_HANDLE with just a void* typedef
Then you will have the problem Judy has right now.

This is an okay method as, just like Windows, you can use a #define
to turn it off (they use "STRICT") for those compilers that
cannot handle it.

(To be clear, you just replace the DECLARE_HANDLE macro with
A void* typedef).


RE: Error handling in Judy

Personally, I would prefer to override this in a similar way to how the
memory allocation does. That is, Judy internally calls a function that
returns the (signed int) error code to return from the Judy function if
appropriate; this value is ignored (but the error handler still called) =
for
those functions that return NULL for errors.

This means on Windows I could change this to:
a) use TLS (or Window's global SetError) to store the code if I wish, or
more likely, log the details in my own way, choosing to remap the return =
if
I wish to something I personally can deal with.

b) log the issue and use RaiseException() - which might be caught by my =
own
structured exception handler so I can do a MiniDump and exit.

c) simply raise a C++ exception

d) by default, Judy could just store the result into a global PJE0, and
provide
   a simple function (JudyGetLastError()) to get it -- see below


I also think that all functions should return the error code or NULL. =
The
better Windows API bits ones just use a BOOL or "special" return value =
(like
NULL).

-----

Here is an example, assuming I'm storing DWORDs as values for Judy
=20
//This would do '=3D NULL' to ensure the value is initialised to NULL
//However, it is still a struct*, so is type safe
DECLARE_JUDY_HANDLE(HJ);

DWORD* pValue;
int Index =3D 1;

//Insertion
//NOTE: if I passed 'HJ' or anything BUT '&HJ', this line
//      would not compile
pValue =3D (DWORD*)JudyLIns(&HJ, Index);

//Use NULL for the error=20
//Internally, the error handler is called with the exact code
//So all three methods above will work fine for checking it

//If I was not mapping errors to some form of exception=20
//like b) or c) above, then I'd have to check the result

//By default Judy could provide a simple global non-thread safe
//default error handler which writes to a single global
//"PJE0" variable
//This ensures you could keep the macro functions for backwards
//compatibility, so existing code bases would just compile
//with only the definition of the HJ having to be updated
//first


if (pValue =3D=3D NULL) {
   //ERROR: actual code available via default Judy function
   PJE0 pCode =3D JudyLastError();
   ...
}


Hope this clarifies my previous comments,


Regards,
=A0
Toni.
=A0
----
Toni Cassisi
Tovica Ltd
http://www.tovica.com
Tel: +44 (0) 7971 874 054
Skype: tcassisi
IM: AOL/Yahoo/MSN: tcassisi


-----Original Message-----
From: Alan Silverstein [mailto:aj...@fr...]=20
Sent: 16 December 2007 22:59
To: dou...@ya...; tca...@to...
Cc: jud...@li...
Subject: RE: Save the array to a file?

Toni,

> When I first looked at Judy, the most frustrating issues I had were
> dealing with the preprocessor macros and the lack of type safety in
> the use of (void*).

I hear you...  At least, I think so.  I'm curious what you would use
instead of generic pointers.  I guess for Judy array pointers, you would
want a declared type for Judy1, JudyL, or JudySL?  This seems reasonable
to me.

But what about JudyL and JudySL value-word (Word_t *) pointers?  How can
the library be any more specific about those, since the definition of
what goes into the value word is up to the caller?

> A secondary issue is the error handling which needs to be a single
> check on each function return - personally, I am not a fan of
> returning error codes via arguments and prefer to just have a FALSE or
> NULL return from the function directly.

OK, but what do you do with something like JudyLGet() where NULL means
not found, otherwise any other value could (at least theoretically) be a
valid address.

I'm trying to recall if we had the functions return -1 (all 1's) for an
error...  Yes, PPJERR.  So doesn't this meet your needs?

Thanks,
Alan Silverstein


-------------------------------------------------------------------------=

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
Jud...@li...
https://lists.sourceforge.net/lists/listinfo/judy-devel