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

[David Gobbi]

On Fri, Apr 30, 2010 at 7:42 AM, Brad King <brad.king at kitware.com> wrote:
> David Gobbi wrote:
>> Each special type in category (1) needs a hexidecimal "type constant"
>> to be defined in vtkParse.  There _should_ be 255 slots available
>
> This is not correct.  Currently there are only 16 slots available, and
> IIRC there is only one left.  The least-significant digit is the only
> one devoted to the type.  The second digit is always either 0 or 1 to
> indicate whether the type is *unsigned*.  The third digit value specifies
> a level of indirection (*, **, &, *&, etc.).  The fourth digit is either
> 0 or 1 to indicate whether the type is *const*.

When I say there "should", I mean that the current way that the bits
are used should be changed.  I apologize not for spelling things out
more clearly.  I  meant that two hexidecimal digits should be
dedicated to the base type, instead of just one.

And that's why I added vtkParseType.h.  Once everything is done with
macros that define the bitfields, changing things around becomes a lot
easier.

> This encoding treats "unsigned" and "const" as if they were both type
> qualifiers even though C includes unsigned in the type and defines
> const as a qualifier.  Documenting and implementing this encoding
> in actual functions and enumeration values would help the readability
> of the code tremendously.

And that's what I'm doing.  The vtkWrapPython.c that I pushed to
origin/master is an example of how the appearance of the code can be
improved.

>> And Brad might have to peek at the code now and then to keep everything kosher.
>
> FYI, I've learned them only far enough to maintain them and tweak things
> on occasion.  I don't know them as if I was the original author.

Even so, can you name anyone at Kitware who knows more about the
wrapper internals than you do?

I've become quite familiar with the wrappers through my workover of
the Python wrappers several years ago, and more recently with my work
on generating Simulink wrappers for VTK.   So I'm confident that I can
get the code cleaned up and get vtkStdString and vtkUnicodeString
properly supported for all languages, and get vtkVariant working for
Python.  But I'd like there to be someone at Kitware who keeps
up-to-speed with the changes that I make.

   David