Re: how to write a wrapper?
don cole wrote:
>
> CChris wrote:
> >
> > CChris wrote:
> > >
> > > Jules wrote:
> > > >
> > > > Andy wrote:
> > > > >
> > > > > You should only be fine with a reference to c. Just go over some
> > > > > documentation
> > > > > of C and you should be fine
> > > >
> > > > oh dear, I've been (politely) RTFM'ed.
> > > >
> > > > probably better if I post something specific. I'll get as far as I can
> > > > and
> when</font></i>
> > > > stuck I'll return.
> > > >
> > > > Thanks anyway.
> > >
> > > You need three things actually:
> > >
> > > 1/ A fair idea of what the dll/so you wrap has inside. You'll get this
> > > knowledge
> > > from the documentation of the shared file, which may or may not be
> > > suitably
> > > organised. In some cases, feedback from users, if available, may help.
> > >
> > > 2/ A fair idea of what the ysers of your wrapper would like to do with it,
> > > and
> > > which sort of pivture of what the hared lib handles they have. The most
> > > important,
> > > because you are the one who is going to translate the shared lib's
> > > ressources
> > > into stuff users may have interest in and can grok.
> > >
> > > No C so far.
> > >
> > > 3/ The knowledge, from the documentation of the shared file, of the
> > > prototypes
> > > of the routines/vars you are going to use from the lib. You have to know
> > > what
> > > is a char, signed or not, a wchar, a tchar, an int and perhaps all sorts
> > > of
> > > fancy things. Pointers are well handled by the C_POINTER data type in the
> > > define_c_*()
> > > definition sequence, so the issue isn't as big as one would think. That's
> > > the
> > > only place some basic knowledge of C is needed.
> > >
> > > Unless you need to understand the source of the lib, if available. That's
> > > another
> > > matter.
> > >
> > > Also, remember that things are straightforward for shared libs coded in C,
> > > but
> > > not quite if they were output by a C++ compiler. I think the doc of fptr.e
> > > by
> > > M. Lewis contains useful information; I never tried it myself. Looking at
> > > the
> > > wxEuphoria wrappers is probably even more educational.
> > >
> > > CChris
> >
> > A couple things I forgot mentioning:
> > 3'/ The documentation for define_c_func() states that
> > <quote>
> > Parameter types which use 4 bytes or less are all passed the same way, so it
> > is not necessary to be exact when choosing a 4-byte parameter type. However
> > the distinction between signed and unsigned may be important when you
> > specify
> > the return type of a function.
> > </quote>
> > As a result, you can get along with only 4 data type declaration: C_FLOAT
> > (32
> > bit fp numbers, nothing else), C_DOUBLE (64 bit fp numbers, nothing else),
> > C_LONG
> > (anything else signed), C_POINTER (anything else unsigned). Using more
> > precise
> > datatypes helps memorising or making sense of the prototypes, but doesn't
> > really
> > matter. As you can see, you even don't have much to know about C data types
> > - just grab the difference between fp and non fp, 32 and 64 bit fp, signed
> > and
> > unsigned data.
> >
> > 4/I have found very useful to document things as you create them. This
> > technique
> > allows to detct inconsistencies, redundancy and areas still to cover.
> > Perhaps
> > that's just me, but I'm mentioning it just in case. This strategy initially
> > slows down development, but considerably shortend later stages. It also
> > applies
> > for any development, not only wrappers.
> >
> > CChris
>
> What does fp stand for? Floating Point?
>
Yes, C knows about 2 sorts of floating points as defined in IEEE754, and
Euphoria knows them too (see atom_to_float32() and atom_to_float64()).
I don't know if the bug with Watcom compilers mentioned in the entry for
define_c_func() was fixed - didn't check. The doc may have been written for
v10.6.
CChris
> I whole heartedly agree with and now document the symplest of my programs.
> Because as someone else pointed out, You may write some thing like:
>
> function ar43(sequence b1, sequence b2)
> return getdec(b1)+64 * getdec(b2)/144
> end function
>
> You may understand this at the time of the writing.
> But go back to it six months from now and say "What the **** is this?"
>
> Don Cole
|
Not Categorized, Please Help
|
|
