[vtk-developers] New header file Wrapping/vtkParseType.h

[David Cole]

On Wed, Apr 28, 2010 at 11:58 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Wed, Apr 28, 2010 at 9:35 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> > On Wed, Apr 28, 2010 at 11:30 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>
> >> There were no comments about my changes to the wrappers so I went
> >> ahead and pushed them.  So if anyone found vtkWrapPython.c to be
> >> completely incomprehensible before, they should find the code to be a
> >> little bit friendlier now.
> >>
> >> In the longer term, I'm looking at how the wrappers can be made to
> >> handle special types (with vtkVariant being the favorite).  The
> >> wrappers used to handle special types fairly well, many years ago, but
> >> support for special types fell by the wayside when vtkObjectBase was
> >> introduced.  Last night I did some work to resurrect the old
> >> special-type handling code with good results.
> >
> > I would love to see handling for vtkVariant, along with vtkStdString, and
> > the unicode variant. It would also be great to have a way to wrap some
> C++
> > data structures so that they could be used from the wrapped languages. Is
> > there a document on how this is/could be achieved?
> > Marcus
>
> There already is support for vtkStdString, it is directly converted
> into the native "string" type in the wrapper languages.  The unicode
> strings can eventually be handled in exactly the same way.
>
> For vtkVariant, it will appear in Python as "vtkVariant" and have all
> the same methods as the C++ version.  In fact I wrapped it last night
> and got it working nicely except that only the default constructor was
> wrapped.  The other (non-constructor) methods were wrapped
> automatically, though.  That was enough to convince me that this isn't
> such a big job after all.
>
> The wrapper generator code is very difficult to read and, as far as I
> know, there is no documentation.  For one of my projects with Queen's
> University I have made a tool called WrapVTK that makes the data
> structures a bit easier to handle.  I'll see if I can push it to a
> public git repository and maybe (eventually) write a paper about it.
> All that WrapVTK does now is generate XML descriptions of the classes,
> but it would probably be useful for seeing how things work.
>
>   David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
The tcl wrapping support for vtkStdString is way less than ideal in its
current state. This is because the generated layers that handle
transitioning between Tcl and C++ assume that a vtkStdString (as a method
return value) is valid for as long as the object is valid. This is true only
sometimes. And when it's true, usually only because of an implementation
detail that is not guaranteed.

Dave Partyka and I spent the better part of a few hours figuring this out a
month or so ago with mysterious tcl test failures... The quick fix for it
was to not use a stack-based vtkStdString as the return of a method
implementation.

The problem with objects that are copied automatically by C++ semantics in
terms of these wrapping layers is just that: such objects are copied (and
then discarded) automatically. So if the wrapper layer casts a temporary
vtkStdString value into a (const char *) and then a few lines later tries to
use it... bang. Shot dead.

So.... if you are going to say that stuff other than plain old data types
and vtkObject-derived classes should be wrapped/wrappable, I'd like to see
it proven with a comprehensive accompanying unit test suite.

At a minimum, the generated code for handling vtkStdString needs some work.


FWIW,
David C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100428/32515aaf/attachment.html>