[vtk-developers] vtkVector class -- proposed rewrite

[David Lonie]

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?

Dave