Re: how to write a wrapper?

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu