[vtk-developers] vtkVector class -- proposed rewrite

Marcus D. Hanwell marcus.hanwell at kitware.com
Mon Jul 25 10:27:16 EDT 2011


Hi David,

On Mon, Jul 25, 2011 at 10:14 AM, David Lonie <loniedavid at gmail.com> wrote:
> 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 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.

Marcus



More information about the vtk-developers mailing list