[vtk-developers] vtkVectorOperators

[Marcus D. Hanwell]

On Tue, Jan 24, 2012 at 11:26 AM, David Lonie <loniedavid at gmail.com> wrote:
> On Tue, Jan 24, 2012 at 8:18 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> On Mon, Jan 23, 2012 at 10:58 AM, David Lonie <loniedavid at gmail.com> wrote:
>>> On Mon, Jan 23, 2012 at 7:16 AM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> Many of these functions are in a separate header, called
>>>> vtkVectorOperators.h, along with tests in
>>>> Common/Testing/Cxx/TestVectorOperators.cxx. I think it is missing
>>>> scalar multiplication, and possible negation (would have to check). As
>>>> you have everything working without, I can review the branch as is and
>>>> then perhaps get it using some of the operators again at some point in
>>>> the future.
>>>
>>> I took a stab at implementing these, but I've run into a
>>> metaprogramming issue that I'm not familiar with. I've put up a draft
>>> here:
>>>
>>> https://github.com/dlonie/VTK/commit/674474eabc45f38be7eac1406039326141c059e9
>>>
>>> The trouble seems to be in the macros used to generate the operators
>>> for the predefined types. I get this rather cryptic compiler error:
>>
>> As far as I know, compound assignment operators should be member
>> functions. If that were the case, then most of the other operators
>> could actually be simplified to re-use that code on the temporary that
>> is returned. Did you try just implementing the minimal set of missing
>> operators first?
>
> Ah, that may be it -- now that I think of it, I've never tried making
> compound assignment operators like this before. I'm planning to work
> on VTK again tomorrow morning, I'll try this out.

I would just try adding one at a time, why not skip the compound
assignment operators for now? We can always add them in a second
patch, I agree that they would be useful.
>
>>> Seems like the trouble could be the static cast from vtkVector<Type,
>>> Size> to vtkVectorXX (see the last line of the compiler snippet), but
>>> the rest of the output makes no sense to me, so I'm not sure ;-) What
>>> would be the most efficient way to cast the vtkVector<,> to a
>>> vtkVectorXX?
>>>
>>  The static_cast is probably not the most efficient way of doing this,
>> and typedefs would have yielded this behavior in a much more elegant
>> fashion. I was going to take another look if I ever got the chance, if
>> the underlying storage is the same (3 floats, 2 doubles etc) then a
>> reinterpret_cast would be the most efficient method of doing this as
>> far as I know.
>
> IIRC, the reason for choosing this design was so that the underlying
> storage would be the same as a straight array, for instance the test
> for
>
>  vtkVector2i vec2i;
>  int arr2i[2] = { 0, 0 };
>  vec2i.Set(arr2i[0], arr2i[1]);
>
>  if (sizeof(vec2i) != sizeof(arr2i))
>    {
>    // The two should be the same size and memory layout - error out if not
>    cerr << "vtkVector2i should be the same size as int[2]." << endl
>        << "sizeof(vec2i) = " << sizeof(vec2i) << endl
>        << "sizeof(int[2]) = " << sizeof(arr2i) << endl;
>    ++retVal;
>    }
>
> So AIUI a reinterpret_cast should be safe.

Yes, we have tests verifying this but when I tried adding code to do
it I ran into some compilation issues and so decided to revisit it
later. You have to make it into a pointer, do the reinterpret cast...

Marcus