[vtk-developers] New VTK wrapping tools and a function pointer typedef question...

[David Gobbi]

Hi David,

I noticed that you backed out the change.  If you want, I can change
vtkParse.l to allow the __stdcall convention for callbacks.  I propose
a different name for the macro, though:

#ifdef _WIN32
// mirrors the CALLBACK macro from the win32 headers
#define VTK_CALLBACK __stdcall
#else
#define VTK_CALLBACK
#endif

It's easiest if the callback methods use this macro directly, rather
than via typedef:

void vtkProgrammableFilter::SetExecuteMethod(
  void (VTK_CALLBACK *f)(void *),
  void *arg);

I would only have to add three entries to vtkParse.l in order to support
this. Let me know what you think.

  David


On Thu, Nov 11, 2010 at 11:48 AM, David Cole <david.cole at kitware.com> wrote:
> Hey David Gobbi!
>
> Help!
>
> This commit that I just pushed to VTK 'master' is getting build errors
> on the continuous dashboard.
>
> http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=a86ee191000177c52c01b41cda36121c7f478920
>
>
> Is there something I should change in the wrapper generators to handle
> this new line of code inside of C++ classes??
>  // Description:
>  // Signature definition for programmable method callbacks. Methods passed to
>  // SetExecuteMethod or SetExecuteMethodArgDelete must conform to this
>  // signature.
>  typedef void (VTK_CB_CC *ProgrammableMethodCallbackType)(void *arg);
>
> Or should I resort to BTX/ETX here?
>
> It's ironic that this breaks the existing VTK wrappers.... The purpose
> of my commit was to make wrapping these programmable method types
> automatic as C# delegates in our ActiViz .NET code base..... :-)
>
> I'm building now with python wrapping turned on locally, so I should
> be able to verify the fix before I push it.
>
>
> Thanks for any suggestions,
> David Cole
> Kitware, Inc.
>