On 2/22/2011 12:28 AM, William S Fulton wrote:
> On 18/02/11 20:26, Tim Crews wrote:
>> As is often the case with such libraries, at least in the domain of
>> Windows software development, many of the API functions involve setting
>> up a structure full of parametric data, then passing a pointer to that
>> structure to the C function. Alternatively, often a pointer to an
>> freshly-allocated structure is passed in to the function, and the
>> function fills in the values in the structure.
>> From my reading, it appears that SWIG will treat all pointers as
>> opaque. I can't afford for them to be opaque -- almost everything that
>> needs to be communicated to/from these functions is in the data that is
>> pointed to by these pointers.
>> In the other direction, how would I handle a function like:
>> BOOL GetFileAttributesEx(LPCTSTR lpFileName, GET_FILEEX_INFO_LEVELS
>> fInfoLevelId, LPVOID lpFileInformation);
>> where all of the important information that comes back from
>> GetFileAttributesEx is found in the structure pointed to by
> For the code 'in the other direction' where you have an LPVOID as
> output. In C you'd probably cast this to some other type, so you'll
> have to do this too in Python, but given you can't cast C types in
> Python, you'll need a helper function which does the C cast for you
> and then call that. Otherwise you'll need to write a typemap to do the
> cast for you for a more user friendly API.
Thank you for your response.
If I understand you correctly, you are saying that pointers *aren't*
opaque. In other words, if I created a C wrapper function to perform
the void * cast, such as:
BOOL FriendlierGetFileAttributesEx(LPCTSR lpFileName,
GET_FILEEX_INFO_LEVELS fInfoLevelId, SomeStructureType *lpFileInformation)
GetFileAttributes(lpFileName, fInfoLevelId, (void *)lpFileInformation);
Then I would be able to run SWIG on this, then use this function from
gfil = GET_FILEEX_INFO_LEVELS()
sst = SomeStructureType()
FriendlierGetFileAttributesEx("C:/Temp", gfil, sst)
And I should be able to access fields of sst that were filled in by the
The sections of the documentation that lead me to believe otherwise were
sections 5.3.1 "Simple pointers", which states "All pointers are treated
as opaque objects by SWIG. Thus, a pointer may be returned by a
function and passed around to other C functions as needed... there is no
mechanism for dereferencing the pointer since this would require the
target language to understand the memory layout of the underlying
object." And section 5.3.3, which gives an example very similar to
mine, except using a FILE * pointer, with the statement "SWIG doesn't
know what a FILE is, but since it's used as a pointer, so [sic] it
doesn't really matter what it is."
I'm not arguing that you are wrong. If you are right, then I guess I
would like to make some improvements to the documentation or the example
programs. I've looked through every page of the documentation, and
didn't find any examples of a pointer being used non-opaquely. I also
looked at the "pointer" code example, which does not deal with structure
pointers, and involves lots of manual touch-up of the simple pointers
types that are accessed.
The API that I need to use does not actually pull the dirty trick of
using a void pointer instead of a real structure pointer, so I will not
have to create wrapper functions to make up for that. But the API does
have almost 400 function declarations, every one of which passes
extended parametric information in and out through structure pointers.
The structures are defined in another 3000-line header file. So if I
have to hand-create anything at all for each one of these functions or
structures, then there is no way that I will be able to afford to use
Python for this task.
I've been investigating Cython as another possible solution to this
problem. Its documentation does show examples of using APIs involving
this kind of structure pointer. But it is not obvious that I will be
able to get away without extensive hand touch-up with that, either. I'm
Thank you again for your time,