On Mon, 2007-09-17 at 11:43 -0700, Doug Baskins wrote:

> > The functions are the critical thing. The standard judy header
> > shouldn't contain the 'convenience' macros, put them in 
> > another header so they can be used or not at the client's
> > discretion.
> ...
> 
> Good suggestion, perhaps you should read the error section in Judy_3x
> man
> page. (also Judy_3x.htm#ERRORS).  It starts off:  "A lot of thought
> (and time)
> went into making error handling in Judy simple, ...".  

Yes, but you then document Judy in terms of the macros I will
never use, so most of the documentation is useless to me.

For the Felix binding, I don't need any macro crud, since Felix
provides its own strongly typed wrapper. For example:

  type JLArray = "void**";

  proc JudyLGet: JLArray * word * JError_t * ptr[ptr[word]] = 
    "*$4=(Word_t*)JudyLGet(*$1,$2,$3);";

  proc JudyLFirst: JLArray * ptr[word] * JError_t * ptr[ptr[word]] = 
    "*(Word_t**)$4=(Word_t*)JudyLFirst(*$1,$2,$3);";

[The notation X * Y just means a pair x,y as in Cartesian Product]

Since Felix does NO automatic conversions at all, there is no way
to make an error calling the Felix functions (as you can in C).

of course.. the wrappers can be bugged.. :)

As to the Felix gc, the number of calls to Judy is small,
and the 'convenience' of error handling etc the macros purport
to provide actually gets in the way: I'd rather call the library
functions directly so I know exactly what I'm getting into
in terms of performance and error handling.

Just as an example of the problems with the macros:

       JLI( PValue,  PJLArray, Index);          // JudyLIns()
       Word_t   Index, Index1, Index2, Nth;

Ok, so the third argument is a Word_t.. but what you don't say
is that it has to be an lvalue. In C++ you'd call that

        Word_t&

but it isn't mentioned anywhere which arguments are values
and which are lvalues. In the C library functions it is explicit
in the type: C doesn't have references so the argument is given as

        Word_t*

It's obvious to you as the author but initially I didn't realise that
functions like

        JudyLNext

actually modify the Index argument as well as returning a pointer
to the slot containing the data. The plain C interface makes that
clear .. the macros simply *obscure* the semantics.

IMHO of course :)

> > I forget what that is?
> 
>      Word_t *abc = (void *)JudyLGet();
> 
> is an error in C++, even though both are pointers.  I thought void *
> was a
> pointer to anything you wanted to make it.

        Ah. Yes, C++ banned *implicit* conversion FROM a void*.
You can implicitly convert any pointer TO a void*. The argument
is that converting TO a void* is always safe, but converting
FROM a void* to a type should require an explicit cast to say
what type you put in it. So you have to write:

        void *pv;
        Word_t *abc = (Word_t*)pv;

This case is a bit unfortunate, having to repeat the type name.
But 'implicit conversion' also applies to

        void f(Word_t*);
        f(pv);          // ERROR
        f(*Word_t*)pv); // OK

This is particularly important in C++ because of overloading:
if the conversion were implicit, you might accidentally call
the wrong function with a void* argument because ANY function
accepting a pointer to anything would accept it -- so the rule
requires an explicit cast.

The same thing applies to integer<-->pointer casts: in K&R C
I think this was implicit and explains why HUGE amounts of C
code are bugged by Unix programmers.

[I have a pet hatred of Unix nerds, because I originally worked
on 16 bit segmented DOS code and got sick of the uppity 
'so superior' attitude these people had .. so now I laugh,
because DOS programmers never made the mistake of assuming
pointers and integers were the same size .. or even that pointers
were linear .. :]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel

Reply via email to