<div class="gmail_quote">On Wed, Apr 28, 2010 at 11:58 AM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Wed, Apr 28, 2010 at 9:35 AM, Marcus D. Hanwell<br>
<<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
> On Wed, Apr 28, 2010 at 11:30 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>><br>
>> There were no comments about my changes to the wrappers so I went<br>
>> ahead and pushed them.  So if anyone found vtkWrapPython.c to be<br>
>> completely incomprehensible before, they should find the code to be a<br>
>> little bit friendlier now.<br>
>><br>
>> In the longer term, I'm looking at how the wrappers can be made to<br>
>> handle special types (with vtkVariant being the favorite).  The<br>
>> wrappers used to handle special types fairly well, many years ago, but<br>
>> support for special types fell by the wayside when vtkObjectBase was<br>
>> introduced.  Last night I did some work to resurrect the old<br>
>> special-type handling code with good results.<br>
><br>
> I would love to see handling for vtkVariant, along with vtkStdString, and<br>
> the unicode variant. It would also be great to have a way to wrap some C++<br>
> data structures so that they could be used from the wrapped languages. Is<br>
> there a document on how this is/could be achieved?<br>
> Marcus<br>
<br>
</div>There already is support for vtkStdString, it is directly converted<br>
into the native "string" type in the wrapper languages.  The unicode<br>
strings can eventually be handled in exactly the same way.<br>
<br>
For vtkVariant, it will appear in Python as "vtkVariant" and have all<br>
the same methods as the C++ version.  In fact I wrapped it last night<br>
and got it working nicely except that only the default constructor was<br>
wrapped.  The other (non-constructor) methods were wrapped<br>
automatically, though.  That was enough to convince me that this isn't<br>
such a big job after all.<br>
<br>
The wrapper generator code is very difficult to read and, as far as I<br>
know, there is no documentation.  For one of my projects with Queen's<br>
University I have made a tool called WrapVTK that makes the data<br>
structures a bit easier to handle.  I'll see if I can push it to a<br>
public git repository and maybe (eventually) write a paper about it.<br>
All that WrapVTK does now is generate XML descriptions of the classes,<br>
but it would probably be useful for seeing how things work.<br>
<div><div></div><div class="h5"><br>
   David<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>At a minimum, the generated code for handling vtkStdString needs some work.<br><br><br>FWIW,<br>David C.<br><br>