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

[David Gobbi]

On Wed, Apr 28, 2010 at 10:10 AM, David Cole <david.cole at kitware.com> wrote:
>
> 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.

Looks like I replied off-list by mistake... so here's an on-list reply.

I've taken a good look at the vtkStdString wrapping, and yes, it's
much less ideal than I remembered.  In fact, fixing vtkStdString will
be more difficult than adding vtkVariant.  Here's why, in a nutshell.

The special types that we want to wrap fall into two distinct categories:
1) things like vtkIdType, vtkStdString, and vtkUnicodeString need to
be completely transparent, i.e. converted directly to the
python/Java/Tcl equivalent basic type
2) things like vtkVariant need to be wrapped in a manner similar to
vtkObjects, i.e. python will have a vtkVariant constructor and will
make all vtkVariant methods available

Since neither category (1) or (2) is reference counted, any
conversions to and from the wrapper language must use copy semantics.
Because the current wrappers just grab the "const char *" from the
vtkStdString, things have gone south.

Each special type in category (1) needs a hexidecimal "type constant"
to be defined in vtkParse.  There _should_ be 255 slots available for
such types instead the twenty-some that are in use now.  Once the code
is better organized (though the use of vtkWrapType.h), these extra
slots can be made available.  At that point, adding proper handling of
vtkStdString and vtkUnicodeString will be straightforward.

The special types in category (2) do not need any special handling.
The wrappers can be made to handle them generically.  For all intents
and purposes, vtkVariant and its ilk can be handled by the wrappers
just like any VTK class, with the following exceptions: (1) copy
semantics will be used instead of reference counting, (2) type
hierarchies will not be recognized.

Of course, very little of the work has been done, so I'd be glad to
hear from anyone who is interested in pushing this forward.  I can do
the changes to the core parser and the python wrappers, but would need
someone willing to work on Tcl and Java.  And Brad might have to peek
at the code now and then to keep everything kosher.

   David