[vtkusers] vtk and python - some questions.

[Jonathan M. Gilligan]

At 12:52 AM 10/25/2000, Prabhu Ramachandran wrote:
>1) It does not have a parser like swig.  I am told that finding a
>proper c++ parser is a really tough job.  Infact there are no
>opensource ones that people seem to be aware of.  All the existing
>parsers dont have some feature or the other.  However there is hope
>for VTK because we already have a working parser that can be used to
>generate the current wrappers.  I don't know all the details but I
>think that this may be enough to wrap vtk using py_cpp.

This is a bit off-topic, but part of the problem with parsing C++ is that 
the grammar is not context-free, so you cannot separate parsing and 
semantic analysis (e.g., consider the symbol foo::bar you cannot tell 
whether bar is an object in namespace foo or a member of class bar simply 
by parsing tokens from a lexer---you have to consult a symbol table). This 
has significant implications for wrapper generators in the event that vtk 
is ever put into its own namespace. It also means that a serious attempt to 
process an arbitrary C++ source file for wrapping or other purposes will 
have to go a long way towards implementing a full C++ compiler.

There are additional complexities due to the preprocessing stage, as David 
Gobbi has pointed out with regard to vtkSetGet, but since it would be 
trivial for the makefiles to preprocess the source with the local C++ 
compiler (I don't know of any that can not be told to spit out the 
preprocessed source), this is really a nonissue for wrapping.

One advantage of the vtk project's wrapper generator is that it can be 
tailored to the coding standards of the vtk project without wasting effort 
on C++ idioms that do not appear in the vtk code.

I would recommend looking towards the future and asking whether an 
investment in developing a new wrapping technology will grow with VTK or 
may turn into a dead end a year or so down the line.

Just my HO, but I thought it might be helpful.

Jonathan
===========================================================================
Jonathan M. Gilligan                     <jonathan.gilligan at vanderbilt.edu>