Reduces the amount of code that has to be generated. Also improves the
number of arrays supported and has better support for deprecated
versions of `GetRange`.
The `VariantArrayHandle` will soon be deprecated for its replacement of
`UnknownArrayHandle`. Thus, `Field` and related classes should start
using the new `UnknownArrayHandle`.
Instead, always use precompiled versions of range computing. This means
you won't be able to specify the type. Currently, types are limited to
scalars vecs up to size 4.
The main motivation for this change is to allow you to include Field.h
with a non-device compiler. This is an important feature for our
customers.
I plan in the future to implement a mechanism to pull out a component of
most ArrayHandle's as a single array. This would enable us to support a
precompiled version that can compute the range of arbitrarily sized
Vecs.
By removing the ability to have multiple CellSets in a DataSet
we can simplify the following things:
- Cell Fields now don't require a CellSet name when being constructed
- Filters don't need to manage what the active cellset is
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
Following what was done with ArrayRangeCompute, the GetRange and
GetBounds methods are embedded into the vtkm_cont library for the most
common type lists.
Also, and probably more importantly, the device adapter is no longer one
of the arguments for either of these methods. It is no longer needed as
ArrayRangeCompute no longer needs it.
This reduces the number of weak vtables vtkm generates, resulting in
a reduction of binary sizes for projects that include vtkm classes in
multiple translation units.