[vtk-developers] Sized types: vtkInt32Type et al

[David Gobbi]

Hi All,

Last night I wrote and committed a new header file for VTK, vtkSizedTypes.h,
that defines a whole new batch of types for VTK with names like 
vtkUnsignedInt8Type
and vtkFloat64Type.  Currently, only vtkImageReslice.cxx uses this 
header file.  I know
that there are several people who are interested in types like this, so 
please take a look
at the file and give your thoughts.

Fully integrating these new types with VTK is a huge project, and I know 
that I'm
opening up a can of worms here because many people want a feature like 
this but
few people if any people have the time to write the code.  The header 
file that I
wrote represents less than one tenth of the work involved.  Other bits 
and pieces on
the to-do list are as follows:

1) Wrapping these new types

The files vtkParse.l and vtkParse.y would have to recognize and assign 
values to the types,
e.g. vtkInt16Type would be seen as 0x82 in the wrappers, and vtkParse.h 
would have to
provide a utility function for converting these types to native types, 
e.g. 0x81 would
be converted to 0x05 to map vtkInt16Type to "short".

The wrappers for the individual languages could do either of two things: 
convert the new
types to native types, or wrap the new types directly.  The Python, Tcl, 
and Java wrappers
would almost certainly use the former options, but a Matlab or Octave 
wrapper might use
the latter.

2) Defining a few new macros

My header file already contains a vtkSizedTemplateMacro for templating 
over all the new
types.  Several other macros are needed:

vtkSetSizedTypeMacro(name):  a macro to automatically generate methods 
of the form
Set##name##ToFloat32(), Set##name##ToInt32(), etc.

vtkImageSizedTypeNameMacro(type): a macro to get the name of a type, for 
example
vtkImageSizedTypeNameMacro(VTK_INT) would give "vtkInt32Type" the same 
way that
vtkImageScalarTypeNameMacro(VTK_INT) currently gives "int".

Developing these macros is far more work than most people imagine, 
because the situation
is complicated by the fact that certain types are not available on all 
platforms and a certain
amount of macro voodoo is necessary.

3) Defining new array classes

New vtkDataArray-derived classes would have to be written to support the 
new types.  For
example, a new vtkUnsignedInt8Array class would be a subclass of 
vtkUnsignedCharArray.
Or to make things as easy as possible, define statements can be used 
instead:
#define vtkUnsignedInt8Array vtkUnsignedCharArray
The only difficulty with using "define" is that GetClassName() will 
return unexpected
results.

4) Changing a few hundred classes to use the new data types

This is definitely a big job, but not as big as people might imagine.  
Any classes that use
vtkTemplateMacro would have to use vtkSizedTemplateMacro instead, and 
any classes
that have a SetScalarType()-like methods would need to have 
vtkSizedTypeMacro() added.

5) Documentation

When everything is done, somebody has to write up complete documentation 
on how to
use the new types so that Will Schroeder can incorporate it into the 
next book.

Thoughts on this matter are welcome. 

 - David