[vtk-developers] Templated filters

[David Cole]

On Sat, Feb 6, 2010 at 11:07 AM, David Doria
<daviddoria+vtk at gmail.com<daviddoria%2Bvtk at gmail.com>
> wrote:

> Is there any reason we can't have a templated single input, single output
> filter?
>
> Currently, it looks like the preferred method is to derive from the class
> *Algorithm of the intended output type and change the input type in the
> FillInputPortInformation function.
>
> Lets take an example of a filter which takes as input a vtkPointSet and
> produces a vtkPolyData:
>
> *Current method:*
>
> class MyFilter : vtkPolyDataAlgorithm
>
> int MyFilter::FillInputPortInformation( int port, vtkInformation* info )
> {
>   if (port == 0)
>     {
>     info->Set( vtkAlgorithm::INPUT_REQUIRED_DATA_TYPE(), "vtkPointSet" );
>     return 1;
>     }
>
>   return 0;
> }
>
> *Proposed method:*
> *
> *
> class MyFilter : vtkFilter<vtkPointSet, vtkPolyData>
> *
> *
> *
> *
> Thoughts? I may be over my head in template programming and pipeline stuff,
> but maybe the experts can discuss/comment?
>
> Thanks,
>
> David
>
>
As others have commented, please avoid using templates. It complicates the
wrapping mechanisms used to build python, java and tcl wrappers for VTK.
When wrapped, only concrete instantiations of templates may be wrapped, and
since there is usually no template mechanism in the target languages, the
only way to do it is to invent a mangled name for use in the target
language. It gets pretty ugly pretty fast.

The official policy should be:
-- no C++ template parameters allowed in:
  -- class declarations of public classes that derive from vtkObject
  -- public method signatures of those same classes

Of course, you may use templates internal to a *.cxx file as long as they do
not affect the API.

I don't know if this policy is expressed anywhere, (anybody from the ARB
listening?) and there is a single violation of it (that I know of) that we
certainly don't want to propagate to other uses.


Thanks,
David C.


P.S. - The subclasses of vtkDataArrayTemplate and the trickery we use with
#define vtkDataArray are the single violation I speak of. Look it up, it's
not pretty.

For example, from vtkLongArray.h:

// Fake the superclass for the wrappers.

#define vtkDataArray vtkDataArrayTemplate<long>

class VTK_COMMON_EXPORT vtkLongArray : public vtkDataArray

#undef vtkDataArray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100206/2bb94d46/attachment.html>