[vtk-developers] vtkVector class -- proposed rewrite

[David Lonie]

On Mon, Jul 25, 2011 at 3:22 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> On Mon, Jul 25, 2011 at 12:17 PM, David Lonie <loniedavid at gmail.com> wrote:
>>
>> Would using a typedef be possible for the wrappers? e.g. "typedef
>> vtkVector<float, 3> vtkVector3f"? That would eliminate most of the
>> complexity in this patch.
>
> Right now, no, it won't work, but it would be easy to make it work,
> easier than handling the macro expansion (would it make the macro
> expansion unnecessary, though?)

It should -- this is actually how the Eigen linear algebra library
works -- they have a Matrix<type, rows, cols> template class that they
typedef into common classes, e.g. Matrix<double, 3, 1> is a Vector3d.
Since they are only typedef'd and not inherited, the need to handle
return types is eliminated, thus removing the need to have the big,
nasty, reinclusion scheme I proposed to generate concrete classes.

We would lose the ability to remove functions that don't make sense
(e.g. SetZ(double) on a size=2 vector), but this is trivial.

> The type vtkVector<float, 3> would then be bound to two different
> names in the wrappers: the original templated name, and the typedef'd
> name.  Both names would refer to the same python class.
>
> One advantage of using subclasses (like the current vtkVector
> implementation) is that vtkVector3f is its own class, instead of just
> being an alias.  There is a chance that some introspection tools might
> misbehave if types are aliased.

Eigen has used this approach for quite a while now, and I'm not aware
of any major issues -- in c++. I know nothing about language wrapping,
so I'm not sure how this would impact the scripting libraries.

Dave