[vtk-developers] vtkVector class -- proposed rewrite

[David Lonie]

Hi Marcus

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 am not sure how this will parse with our documentation parser, but
> could try it out. It sounds like you have explored quite a few
> approaches, but I would like to explore this a little further. I
> certainly agree we need more operators, and there is currently more
> duplication than necessary (and using a typedef would solve many of
> these issues).

Absolutely.

Dave