Sorry: that should read: //In Judy header to declare the type DECLARE_HANDLE(HJUDY);
//Declare my variable and init to NULL HJUDY hJudy = NULL; DWORD* pValue; int Index = 1; //Insertion //NOTE: if I passed 'hJudy' or anything BUT '&hJudy', this line // would not compile pValue = (DWORD*)JudyLIns(&hJudy, Index); Regards, Toni. ---- Toni Cassisi Tovica Ltd http://www.tovica.com Tel: +44 (0) 7971 874 054 Skype: tcassisi IM: AOL/Yahoo/MSN: tcassisi -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Toni Cassisi Sent: 17 January 2008 15:29 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected] Subject: RE: Judy API design Alan, Doug: RE: Comments on the lack of type safety in the Judy API 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) \ 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, 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 //This would do '= 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 = 1; //Insertion //NOTE: if I passed 'HJ' or anything BUT '&HJ', this line // would not compile pValue = (DWORD*)JudyLIns(&HJ, Index); //Use NULL for the error //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 //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 == NULL) { //ERROR: actual code available via default Judy function PJE0 pCode = JudyLastError(); ... } Hope this clarifies my previous comments, Regards, Toni. ---- 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:[EMAIL PROTECTED] Sent: 16 December 2007 22:59 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
