This method was originally deprecated to avoid confusion with the
indexing of the components in `ExtractComponent`. However, there might
be good reason to want to know the non-flat number of components, so
maybe getting rid of it is not a great idea. Unmark the method as
deprecated, at least for now.
Previously, `ArrayHandleSOA` worked with any value type that supported
`VecTraits`. That means that `ArrayHandleSOA` worked with scalar types
like `Float32`. However, for scalar types, the behavior is essentially
the same as `ArrayHandleBasic`, but with lots of extra templating and
code generation.
Although there is nothing _wrong_ with allowing `ArrayHandleSOA` holding
a scalar, there is no real reason to either (other than likely template
convenience). Generally, there is nothing wrong with supporting it, but
if you want to support `ArrayHandleSOA` in places where types are not
known (e.g. `Field`), then templating tends to iterate over the cross of
all supported types with all supported storage. That means such code
will automatically generate a bunch of code for `ArrayHandleSOA` with
scalars even if there is no reason for those code paths.
So, we can just disable the use of `ArrayHandleSOA` with scalars to
allow us to use `ArrayHandleSOA` as a default storage without creating
all these useless code paths.
`ArrayHandleRecombineVec` is used when calling
`ExtractArrayFromComponents` from `UnkownArrayHandle`. It needs special
handling with the `Fetch` for an output array.
This method allows you to extract an `ArrayHandle` from
`UnknownArrayHandle` when you only know the base component type.
Also removed the `Read/WritePortalForBaseComponentType` method
from `UnknownArrayHandle`. This functionality is subsumed by
`ExtractArrayFromComponents`.
The primary purpose of `ArrayHandleRecombineVec` is to take arrays
returned from `ArrayExtractComponent` and recombine them again into a
single `ArrayHandle` that has `Vec` values.
932c8e5ec Wrap test_equal_ArrayHandles into a precompiled library
5610d674d Print TestEqualResult messages in VTK_TEST_ASSERT
84bfcc238 Move test_equal_* classes to top namespace
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2363
The previous implementation of test_equal_ArrayHandles was several
templates that had to be resolved by any test that used them, which
could be costly for unknown array types. Simplify this a bit by moving
the implementation of testing unknown arrays into a library.
Another advantage of the new implementation is that is handles more
cases. Thus, you should not need to `ResetTypes` on the unknown/
uncertain arrays.
Some of the `test_equal` functions return a `TestEqualResult`
instead of a `bool` to capture more information about what
the error was. Unfortunately, using this was awkward because
you couldn't just call the `test_equal_*` inside of a
`VTKM_TEST_ASSERT`. Rather, you would have to do the comparison
and then check it.
This change adds an overload to `VTKM_TEST_ASSERT` that specifically
takes a `TestEqualResult`, checks its condition, and prints out
the contained messages. Thus, your command can just look like
`VTKM_TEST_ASSERT(test_equal_ArrayHandles(...));` and it will
provide the additional information.
These helper functions were in vtkm::cont::testing, but that made them
hard to discover (and I personally kept forgetting about them). Move
them to the top namespace so that IDE of test_equal will helpfully
remind us of these other test functions.
Recent merge requests !2354 and !2356 both edited ArrayHandleView. Git
successfully merged the changes, but the changes were still incompatible
with each other, causing an unexpected compile error on master. This
fixes the issue.
