`RecombineVec` is the class used as the value type for
`ArrayHandleRecombineVec`. It is a `Vec`-like object, but has several
limitations (including arithmetic operators like `+` won't work).
Arithmetic assignment operators are useful so you don't have to create
impossible intermediate values.
Previously, the arithmetic assignment operators (`+=`, `-=`, `*=`, `/=`)
on `VecBaseCommon` only accepted another subclass of `VecBaseCommon`.
Changed the operators to accept any type.
The benefit of this change is that the assignment operator of classes
that inherit from `VecBaseCommon` can now work with `Vec`-like classes
that do not inherit from `VecBaseCommon`. I think the only real downside
is that the template could match other classes that would lead to
invalid comparisons. But such use would lead to a compile error anyway.
The difference is that instead of getting an error that no overloaded
version of the operator is available, you will get an error inside the
code of the operator.
The base C types have several "duplicate" types that the compiler
considers different even though the byte representation is the same. For
example, `char` and `signed char` have the same meaning but are treated
as different types. Likewise, 'long', 'int', and 'long long' are all
different types even though 'long' is the same as either 'int' or 'long
long'.
When pulling extracted components from `UnknownArrayHandle`, there is
little value for creating multiple code paths for types like `char` and
`signed char`. Instead, allow implicit conversion among these types.
Some organizations use a firewall that intercepts SSL communications and
replaces the authentication token with an organization-wide token that
is just supposed to be accepted. Browsers can be locally configured for
this intentional trickery, but it's a little more tricky for the use of
`curl` in a batch script that is shared with external collaborators.
The easiest solution is to just disable the security for the `curl`
download. This makes the script more susceptible to "man in the middle"
attacks, but it's probably easier to just slip malware in the public
repos anyway.
Some of the special `ArrayHandle`s require specialized versions of
`vtkm::exec::arg::Fetch`. The specializations were not put in the
respective vtkm/exec/arg/Fetch*.h header files because the definition of
the `ArrayHandle`s was not available there. The implementation was in
the ArrayHandle*.h files, but it is hard to find the specialization
there.
Instead, make a secondary header file in vtkm/exec/arg that implements
the Fetch specialization and include it from the ArrayHandle*.h file.
That way, the basic Fetch does not have to include odd `ArrayHandle`
types but the `Fetch` implemenations are still all located together.
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.
`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.
