[vtk-developers] vtkVector class -- proposed rewrite

[Marcus D. Hanwell]

On Sun, Aug 7, 2011 at 8:06 AM, David Lonie <loniedavid at gmail.com> wrote:
> On Mon, Jul 25, 2011 at 10:27 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> On Mon, Jul 25, 2011 at 10:14 AM, David Lonie <loniedavid at gmail.com> wrote:
>>> On Mon, Jul 25, 2011 at 9:55 AM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> On Fri, Jul 22, 2011 at 8:13 PM, David Lonie <loniedavid at gmail.com> wrote:
>>>>> I'd like to ask for opinions on the following patch:
>>>>>
>>>>> http://github.com/dlonie/VTK/commit/6fd3b1c50244174d2ecb2e8bf4ae40996b0f61d6
>>>>>
>>>> <snip>
>>>>>
>>>>> A neat feature of this approach is that the vectors only take up the
>>>>> same amount of memory as an array of equal length, and most (if not
>>>>> all) functions are inlined by the compiler, making the vtkVector
>>>>> objects very efficient for both storage and performance.
>>>>>
>>>>> The problem:
>>>>> The existing vtkVector class had few math functions, and handling
>>>>> return types was difficult: implementing the math functions in
>>>>> vtkVector meant returning a vtkVector<> class, so if we defined, say,
>>>>> operator+, in the base vtkVector class we couldn't do something like:
>>>>>
>>>> I think there is perhaps a simpler, more readable approach to
>>>> accomplishing this goal. I do feel a little uncomfortable with the
>>>> maintainability of this approach. How about a macro to define the
>>>> concrete classes, with their operators? With some of the new changes
>>>> in the wrapping perhaps the typedef would be more palatable too?
>>>
>>> I tried writing a macro to define an entire concrete class at first,
>>> but since the preprocessor expands the entire class on one line, the
>>> "// Description:" comments knocked out the rest of the class (I'm not
>>> even sure if the parsers would expand the macros?). This approach
>>> would work if we could use /* C-style comments */ for documentation,
>>> the doc parser doesn't require a newline after "Description:", and the
>>> parser will expand the macros.
>>>
>>> I thought the current implementation was quite maintainable (once the
>>> initial confusion passes, of course ;-) ). All classes share the same
>>> section of source code, and I really like the ability to exclude some
>>> functions using ifdefs (e.g. SetZ() only if the size >= 3).
>>>
>>> But I fully agree -- a typedef would be ideal here.
>>>
>> I think at a minimum we should separate out the definition of the base
>> class from the definition of the derived one. So vtkVector would be in
>> vtkVectorBase perhaps, and the others might stay in vtkVector and a
>> standard header guard could be used there.
>
> I'm not sure I follow -- how would the class be split? Which methods
> should go where?
>
It is not really relevant if we are using a typedef here. I was
pointing out that the logic you had set up could be simplified by
defining the vtkVector base class in a separate header, and including
that in the existing header.

Marcus