[Paraview-developers] good way to wrap different array types?

[Mark Olesen]

Thanks Dave for the basics.
If there is any rewriting, I think we'll need something more coordinated than gitlab merge requests.
Either email, or some design document/discussion on gitlab first to get the main layout etc.

For the reader code itself, we really need a separate 'OpenFOAM' directory, and later a namespace for all the bits and pieces.
For the git mv, should I raise an issue, or can someone from KitWare just do it?

Cheers,
/mark
________________________________________
From: David Lonie <david.lonie at kitware.com>
Sent: Monday, April 24, 2017 4:57:06 PM
To: Mark Olesen
Cc: ParaView Developers
Subject: Re: [Paraview-developers] good way to wrap different array types?

On Sat, Apr 22, 2017 at 7:39 AM, Mark Olesen <Mark.Olesen at esi-group.com> wrote:
> I was considering some cleanup of the OpenFOAM reader - there are loads of special int32, int64 handling. For example near here:
> https://gitlab.kitware.com/vtk/vtk/blob/master/IO/Geometry/vtkOpenFOAMReader.cxx#L5716 ,
> which also uses a number of helper functions for retrieving back the correct value from the vtkDataArray.
>
> Since the decision of 32/64-bit input is run-time, I don't see any really elegant means of avoiding explicitly specifying and later checking 32 vs. 64-bit.
> What I would like is something along the lines of a wrapped vtkDataArray with additional flag (32/64).
> For example,
>
> struct someIntArray : public vtkDataArray
> {
> bool is64;
>
> // Construct with 32/64?
> someIntArray(bool use64Bit)
> : is64(use64Bit)
> {
>    if (use64Bit)
>    {
>     ... etc
>    }
>
> }
>
> The question is if this approach even makes sense. How the constructor should actually look. Should the constructor use a New, smartpointer, whatever?

Feel free to clean up the internals of that class as much as you like :-)

As for the data array class, I like the idea, but wouldn't try to make
a full-fledged subclass of vtkDataArray. VTK supports arbitrary
subclasses of vtkDataArray, but using the built-in versions gives much
better performance since performance-critical areas of code in VTK
have fast-paths implemented for them. Plus it's a giant pain to get
the APIs right for new vtkDataArrays :-)

Instead, I think an internal wrapper class that basically encapsulates
the helper functions and the use64bit boolean would simpler, e.g.

class vtkFOAMLabelArray
{
  vtkNew<vtkTypeInt32Array> Data32;
  vtkNew<vtkTypeInt64Array> Data64;
  bool Use64BitArray;

public:
  vtkFOAMLabelArray(bool use64BitArray) {...}

  vtkTypeInt64 GetValue(...) {...}
  void SetValue(..., vtkTypeInt64) {...}

  vtkDataArray *GetDataArray() {...}
};

You can interact with the arrays through the wrapper API, and then
call GetDataArray at the end when building up the final data set.

HTH,
Dave