Fix compile warnings that come up with the flags
-Wconversion -Wno-sign-conversion
This catches several instances (mostly in the testing framework) where
types are implicitly converted. I expect these changes to fix some of
the warnings we are seeing in MSVC.
I was going to add these flags to the list of extra warning flags, but
unfortunately the Thrust library has several warnings of these types,
and I don't know a good way to turn on the warnings for our code but
turn them off for Thrust.
Previously ArrayTransfer and ArrayManagerExecution received a reference
to a Storage class in their constructor and held the reference as an
ivar. In retrospect, this is just asking for trouble. First, it is way
too easy to pass by value when you mean to pass by reference. Second, if
there ever is a bug where the Storage goes out of scope before the
classes holding a reference, it is that much harder to debug.
This includes changing methods like LoadDataForInput to PrepareForInput.
It also changed the interface a bit to save a reference to the storage
object. (Maybe it would be better to save a pointer?) These changes also
extend up to the ArrayManagerExecution class, so it can effect device
adapter implementations.
This API change effects both ArrayTransfer and ArrayManagerExecution.
This is in preparation for a future change to make the API more
consistent with ArrayHandle.
The functors in the ForEach, StaticTransform, and DynamicTransform
methods sometimes can use the index of the parameter that they are
operating on. This can be a helpful diagnostic in compile and run-time
errors. It is also helpful when linking parameters from one
FunctionInterface with those of another.
This new features are now replacing implementations using the Zip
functionality that was removed earlier. The implementation is actually
simplified a bit.
Providing these types tends to "lock in" the precision of the algorithms
used in VTK-m. Since we are using templating anyway, our templates
should be generic enough to handle difference precision in the data.
Usually the appropriate type can be determined by the data provided. In
the case where there is no hint on the precision of data to use (for
example, in the code that provides coordinates for uniform data), there
is a vtkm::FloatDefault.
Before we assumed that we would only use the basic types specified by
the widths of vtkm::Scalar and vtkm::Id. We want to expand this to make
sure the code works on whatever data precision we need.
For MSVC we use the non-portable wrapper stdext::checked_array_iterators
because the compiler insists on it for safety. When we check to make sure
our templates are giving us raw pointers, we have to check for this wrapper
instead of the raw pointer itself.
After a talk with Robert Maynard, we decided to change the name
ArrayContainerControl to Storage. There are several reasons for this
change.
1. The name ArrayContainerControl is unwieldy. It is long, hard for
humans to parse, and makes for long lines and wraparound. It is also
hard to distinguish from other names like ArrayHandleFoo and
ArrayExecutionManager.
2. The word container is getting overloaded. For example, there is a
SimplePolymorphicContainer. Container is being used for an object that
literally acts like a container for data. This class really manages
data.
3. The data does not necessarily have to be on the control side.
Implicit containers store the data nowhere. Derivative containers might
have all the real data on the execution side. It is possible in the
future to have storage on the execution environment instead of the
control (think interfacing with a simulator on the GPU).
Storage is not a perfect word (what does implicit storage really mean?),
but its the best English word we came up with.
It was originally put there to support CopyInto in ArrayHandle, but that
has already been removed. It really only makes sense for trivial
examples and testing code, and it sometimes causes complications with
coding.
Each type of point coordinates has its own class with the name
PointCoordinates*. Currently there is a PointCoordiantesArray that contains
an ArrayHandle holding the point coordinates and a PointCoordinatesUniform
that takes the standard extent, origin, and spacing for a uniform rectilinear
grid and defines point coordiantes for that. Creating new PointCoordinates
arrays is pretty easy, and we will almost definitely add more. For example,
we should have an elevation version that takes uniform coordinates for
a 2D grid and then an elevation in the third dimension. We can probably
also use a basic composite point coordinates that can build them from
other coordinates.
There is also a DynamicPointCoordinates class that polymorphically stores
an instance of a PointCoordinates class. It has a CastAndCall method that
behaves like DynamicArrayHandle; it can call a functor with an array handle
(possible implicit) that holds the point coordinates.
This is used with the FunctionInterface::DynamicTransformCont method to
convert a call of arguments using dynamic array handles to a function
templated on concrete types.
