OpenEuphoria

Re: how to write a wrapper?

• Posted by don cole <doncole at pac?e?l.net> Aug 04, 2007
• 456 views

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

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