Anders Gammelgaard wrote:
> Hi.
>
> I use SWIG + Python for testing C code and like the ease of playing around
> with C code and derived Python functions. But more wants more.
>
> For me an ultimate goal would be if developers could change api.h
> a little, run SWIG, and then immediately have access to
> corresponding python functions - without needing to change
> interface files. Maximum automization is key to this.
>
> It springs to my mind that given an api.h file with (sp)lint annotations
> some of the api.i definition can be automatically inferred.
>
> Example:
>
> bool create_obj(int inst_no,
> int /*@out@*/ *handle);
>
> This API function allows several instances of an object to be created;
> creation can fail (signalled by returning false), objects have user
> selected global IDs (the inst_no), but for fast object access, the ID
> chosen by the API and returned in handle should be used instead.
>
> This function should map to a Python function that could be used as:
>
> success, api_id = create_obj(my_id)
> if success: ...
>
> It's pretty obvious what to put in api.i to achieve this - for SWIG 1.3.19:
>
> %include "typemaps.i"
> %typemap(python, in, numinputs=0)
> int *handle {
> int temp;
> $1 = &temp;
> }
>
> %typemap(python, argout)
> int *handle {
> PyObject *tmp_out;
> /* Return value is a simple Python object; convert to tuple */
> tmp_out = PyTuple_New(2);
> PyTuple_SetItem(tmp_out, 0, $result);
> PyTuple_SetItem(tmp_out, 1, PyInt_FromLong(*$1));
> $result = tmp_out;
> }
>
> But this is much more text than the bare /*@out@*/ annotation so the
> question arises: Could some of api.i become auto-generated from /*@out@*/?
>
> (An additional benefit in exploiting an /*@out@*/ annotation is that it
> frees the developer from dealing with the extra complication of converting
> results to a Python tuple only for the first out argument, not for the
> following.)
>
> I have sought the mailing-list for earlier proposals of this quite obvious
> feature, but not found much.
>
> Full automization for all kinds of parameter conversions is probably an
> illusion. So it's OK if people still have to deal explicitly with some of
> the API mapping, but I guess it's worthwhile to investigate if .i files
> could declare such automatic conversions explicitly - something like:
>
> %auto_param_convert(/*@out@*/)
> <The above code-snippet, properly parameterized>
>
> I'm sure somebody has considered possibilities like this one before? Or is
> the SWIG macro-language already strong enough to define %auto_param_convert
> by hand? Have I simply overlooked a nice feature in the manual? If not,
> how long would it take me to add such a feature to current SWIG? Days,
> weeks, months?
>
>
Something like this would be a nice addition. Some changes to the parser
would be required for storing C comments. This also needs doing to
extract doxygen comments at some point i the future. For the doxygen
comments, each comment would be attached to a method or class in the
same way that your C comment could be attached to a parameter type. It
would then be up to each language module to take the comment and do what
it wants with it. However, as you suggest any comment attached to a
parameter could be mapped from a comment name to a typemap and would
need to be handled by the core. Not sure how long it would take to
implement, probably a few days.
William
|