To serialize an `UnknownArrayHandle`, a pair of lists were created to
specify all possible value and storage types. These were then used in an
`UncertainArrayHandle::CastAndCall`, which would in turn take the cross
of these two lists. This resulted in a _really_ long list that gave
compilers trouble.
Reduce the size of the list by separating out value types by the number
of components, which can be easily deduced.
b8c1f5aac make calling to emplace_back type safe
43dd4638e use auto in range-based for loop
9958394fa tidy-up language usage and coding style conformation
b3327e544 move auto field = ... around to minimize accidential capture
455c20437 Migrate field_transform
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2696
The `StorageListEfficientExtract` type is never used in
`UnitTestSerializationArrayHandle`. Although these types are used,
because they all support efficient component extraction from the array,
there is no need to treat them special. As such, this list was never
used.
When calling `ArrayExtractComponent`, some arrays cannot really have a
component extracted. In this case there is a fallback and a warning is
generated.
Of course it is good to test this behavior. The
`UnitTestArrayExtractComponent` does test this and as such generates
this warning (intentionally). Add a note to the output that this warning
is expected.
`ArrayHandleCast` was giving warnings about casting to a type that could
not hold the range to the source even when that was not true. The
problem was it was using `std::numeric_limits::min` for the lower end of
the range. But for floating point values, `min` is not really `min`.
Rather, it is the smallest representable number. (This is probably a C++
bug we are stuck with.) You really need to use `lowest`.
The actually serialization was not doing any inefficient component
extraction, but the array handle comparisons were. This made it hard to
verify that the actual serialization was not being slow. Fixed the
comparison to make sure that it only used efficient paths.
One of the tests was to make sure that the `ArrayHandleMultiplexer` is
working in the exec environment. It was doing this with an `ArrayCopy`.
However, the `ArrayCopy` was falling back to the host, so the test was
not doing what was expected.
Now use `DeviceAdapterAlgorithm::Copy` to force the array to work on the
device.
The `ExtractStructured` code was calling `ArrayCopy` on a permutation of
odd arrays, which was causing problems with the copy. Specifically use
`ArrayCopyDevice` to ensure the copy happens efficiently.
ca032801a Allow ArrayExtractComponent to work with Vec-like value types
f48b4b761 Add implementation of VecTraits for Range and Bounds
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Gunther Weber <ghweber@lbl.gov>
Merge-request: !2683