From: William S F. <ws...@fu...> - 2011-02-22 07:28:55
|
On 18/02/11 20:26, Tim Crews wrote: > Hello: > > I am brand new to SWIG. I've read my way through the SWIG user manual. I > don't think I've grokked it all yet. > > I have been considering using SWIG to help me with a Windows application > written in Python. This application must use a library that was > published as a Windows DLL with a large C header file (more than 5000 > lines, hundreds of functions). I do not have source code for the DLL -- > only a header file. > > > 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. > > > Have I misunderstood this limitation of SWIG pointer handling? With this > limitation, that would put most of the Win32 API off-limits, for > example. Just turning to a random page of my Win32 book, how would SWIG > be used for an API like this: > > > BOOL CreateDirectory(LPTSTR lpszPath, LPSECURITY_ATTRIBUTES lpsa); > > > where much of the important data being sent to CreateDirectory is being > sent through a structure pointed to by lpsa? > > > 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 > lpFileInformation? > > > From my reading, I think perhaps I am supposed to use typemaps to > convert these parameters into actual return values or separate > non-structure parameter values? But if that is the case, I cannot afford > to write typemaps for 5000 lines worth of header files. > > > Ss there any hope of automatically (or at least *mostly* automatically) > generating a Python API for 5000 lines worth of functions defined like > this? If not, then it is very likely that this development task will be > moving from Python to C++ -- and I really don't want that! > The default wrappers result in you writing Python code that will be much like a C equivalent. Consider: BOOL CreateDirectory(LPTSTR lpszPath, LPSECURITY_ATTRIBUTES lpsa); You need to ensure the types are parsed by SWIG before parsing the above line, so probably something like: typedef int BOOL; typedef char * LPTSTR; typedef unsigned long DWORD; // You can instead use %include <windows.i> which is a SWIG library already with the above defined typedef struct SECURITY_ATTRIBUTES { DWORD nLength; ... member vars... } *LPSECURITY_ATTRIBUTES; then from Python you use it like this: sa = SECURITY_ATTRIBUTES() sa.nLength = 20; ... b = CreateDirectory("C:/temp", sa) 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. William |