[Paraview] Convert file types with python

David Doria daviddoria at gmail.com
Sat Apr 25 21:30:47 EDT 2009


On Sat, Apr 25, 2009 at 8:26 PM, pat marion <pat.marion at kitware.com> wrote:

> Hi Dave,
>
> Usually we try to minimize the number of extra includes placed into a
> header.  Is it possible to rewrite the method declaration as:
>
> void WriteAPolyData(vtkPolyData* pd, const char *OutputFilename);
>
> and then replace the 3 added includes with the line:
>
> class vtkPolyData;
>
> About your compile error, you didn't include the specific error
> message so I can only guess, but I think it is a parse error from the
> python wrapper.  The python wrapper doesn't recognize template
> arguments like vtkSmartPointer or std::strings.  If a method uses such
> types then its declaration must be preceded with a line containing
> //BTX and followed by //ETX, this tells the parser to skip over the
> declaration.  It also means this method will not be available from
> python.
>
> Another suggestion, in vtk it is preferred to use vtkstd::string or
> vtkStdString instead of std::string.
>
> Pat
>

Hi Pat,
In this case none of the string functionality is used anyway, so char* would
be fine - std::string just always seems like the "new" way to do things to
me, and with almost no overhead (maybe I'm wrong?). Also, why would you not
want to use a smart pointer around the polydata (and I had also used smart
pointers around all of the other variables (normals, points, etc) in the
function)? I thought that was the "vtk way" to do things? Maybe it is only
to keep the python support like you mentioned?

I understand the forward declaration of the class that already has some of
the other headers that I had included - wouldn't it be more clear to
explicitly show which headers are used though? I have never worked on a big
project like this so maybe there are significant costs of re-including the
headers that I'm not used to caring about?

Also - I didn't mention that I changed the printf's to use std::ofstream - I
suppose that's out of the question too?

You were exactly right about the parser error - it compiled fine with the
//BTX //ETX tags.

(Maybe we should move this to a dev list instead of the users list? Or take
the discussion offline?)

Thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090425/ee1a5ed7/attachment.htm>


More information about the ParaView mailing list