[vtk-developers] Alternatives to vtkTemplateMacro

[Moreland, Kenneth]

Comments from the peanut gallery.

I am perhaps the only person in the world comfortable with using vtkTemplateMacro.  What is nice about it is that you can set up whatever type of call specification you want in the functor.  The definitions here force you into a very specific type of functor.  That is fine, so long as the most common use cases are straightforward to code and read.

The use case I am most worried about, because the use is very common, is a functor that needs to take two arrays that have the same type.  Typically this happens when you take an input array and use that data to construct an output array.  You know they are the same type because you made the output array.  To implement that right now, you have to pass one of the arrays as a field to the functor class, call the functor with the other array, and then do a type cast on the array.  I argue that this is awkward to code and read.  There should be a mechanism to define a functor that takes two typed arrays instead of one.

Now for the difference between the two so far proposed methods (which, for simplicity, I will call Tim's method and Brad's method).  As usual, Brad's solution is so clever that it takes me a long time just to understand all the cool magic things it does under the covers to make my life easier.  If I understand it correctly, the "issue" with Tim's method is that the functor has to implement every possible type supported by the Apply method.  Even in Tim's simple examples, the functor has to implement string versions of the function even though they are no-ops because they don't do anything.  In Brad's method, you can simply implement the types you feel you need to support.

The thing I don't like about Brad's methods is that it adds more steps to the process.  First you have to implement the functor (much like Tim's method), then you have to create an apply_map and tell the map all the types your functor you support (which you have pretty much already specified when you declared the functor in the first place).  I admit, mostly this is just an annoyance (remember, I like vtkTemplateMacro because all I need to do is define a templated function).  But there is also an increased potential for errors.  If you forget to (or inappropriately) define a type for a functor, then the compiler will give lots of nasty errors.  However, if you forget to specify one of the types for the apply_map, then it will silently fail, perhaps some time later in the future because you forgot to test that type.

I think the issue of having the functor implement types it does not really support could be addressed with Tim's method by simply offering specialized versions of Apply that only work on some subset of the possible types.  For example, a version of Apply that only downcast to numeric types would probably cover the majority of the cases.

As far as the double dispatch is concerned, I'm not sure why you can't implement that by having a templated functor with an internal templated functor that worked with the other type.  That is basically how you implement double dispatch with the current vtkTemplateMacro.

-Ken


On 9/9/09 1:12 PM, "Brad King" <brad.king at kitware.com> wrote:

Hi Folks,

The "vtkArray" hierarchy was added to VTK last year to provide
N-dimensional arrays for InfoVis and other computation.  This
wiki page describes them:

  http://www.kitware.com/InfovisWiki/index.php/N-Way_Array_Data_Structures

Several filters already perform computation on vtkArrayData objects
(pipeline containers for vtkArray instances).

Some filters need to be implemented in terms of vtkTypedArray<>, or
even vtkDenseArray<> or vtkSparseArray<> to be efficient.  Since the
vtkTemplateMacro only supports switching on the scalar type with raw
pointers, it is insufficient for these filters.  Currently they use
hand-crafted solutions or just work for only one array type.  For
example, vtkArrayNorm only works with vtkTypedArray<double> input.

Tim Shead has proposed creation of an alternative dispatch mechanism
that supports more representations than just VTK_TT* raw pointers.
He also suggests using more modern C++ meta-programming techniques
(which is easier after dropping VS 6 and other troubled compilers):

  http://www.kitware.com/InfovisWiki/index.php/N-Way_Array_Casting

Jeff Baumes asked me to review the problem and proposed approach.
Since any alternative to vtkTemplateMacro will be of general use
to all VTK filters, we've decided to bring the discussion here to
the VTK developer's list.

I've attached a sample program that shows one approach for runtime
dispatching to overloads selected at compile time.  It is different
than Tim's initial proposal.  An advantage shown is that no central
place (like vtkArray or vtkTemplateMacro) needs to know all the
possible types for which specialized filter implementations might
appear.

A drawback of all above dispatch mechanisms is that they work only
for one runtime-selected type at a time.  This is a problem when
both the input and output type of a filter affect the choice of
implementation.  The problem leads to double dispatch patterns like
that seen in vtkDeepCopySwitchOnOutput in vtkDataArray.cxx with
vtkTemplateMacro.

A better approach requires solving the "multiple dispatch", or
"multimethods" problem:

  http://en.wikipedia.org/wiki/Multiple_dispatch
  http://www.research.att.com/~bs/multimethods.pdf

I briefly toyed with some ideas on library-only implementations
of multimethods in combination with overloading.  My conclusion
is that it is possible but may not be worth the complexity in
VTK for the few filters that need it.  However, new InfoVis and
other N-way array processing filters might enjoy the power.

Comments?
-Brad



   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20090910/0c0f94e1/attachment.html>