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