With the major revision 2.0 of VTK-m, many items previously marked as
deprecated were removed. If updating to a new version of VTK-m, it is
recommended to first update to VTK-m 1.9, which will include the deprecated
features but provide warnings (with the right compiler) that will point to
the replacement code. Once the deprecations have been fixed, updating to
2.0 should be smoother.
In pretty much any practical circumstance, whenusing `ListAll` or
`ListAny`, you have a list of types on which you run some sort of
predicate on each item in the list to determine whether any or all of
the items match the predicate. To make this easier, add a second
argument to `ListAll` and `ListAny` to provide a predicate that will
automatically be added.
If no predicate is given, then the operation is run directly on the
list. This is implemented by just using an identity operation.
These new features to VTK-m lists allow you to compute a single value
from a list. `ListReduce` allows you to compute a value based on a
predicate. `ListAll` and `ListAny` use this feature to determine if all
or any of a list of `true_type` or `false_type` objects are true.
If you have a really long list, compilers might error out if you have a
recursive operation on it. Such an error can be confusing, so for now
create an error if the list is too long.
The previous implementation of `ListAt` would iteratively pass through
the list to find the i'th entry. It was made faster by searching through
8 indices at a time, but it could still be time consuming for long
lists.
This change instead uses a divide-and-conquer approach. It does this by
first creating a `vtkm::List` with i repetitions of `const void*`. It
can do this by recursively splitting i in half and appending the
resulting lists together.
It then uses this list of `const void*` by constructing a method that
first takes these i `const void*` arguments, then a pointer, then
whatever. The method returns the type of that pointer. The method is
never actually defined, but a `declspec` can determine what the return
type should be.
This method was taken from brigand
(https://github.com/edouarda/brigand).
Previously, the policy specified which field types the filter should
operate on. The filter could remove some types, but it was not able to
add any types.
This is backward. Instead, the filter should specify what types its
supports and the policy may cull out some of those.
The `std::conditional` utility is very convenient, but it unfortunately
means that the compiler has to evaluate both the true and false types
even though one is guaranteed to be thrown out. This is problematic
because it requires the compiler to do a lot more work then necessary.
It is especially dumb when introducing the conditionals to reduce the
number of cases being evaluated, as was much of the case in List.h.
Was getting the following error:
vtkm/List.h(284): error C2210: 'T' : pack expansions cannot be used as
arguments to non-packed parameters in alias templates
This is probably an issue with the compiler not resolving templated
aliases correctly.
This cleans up the code a bit by removing duplication. More importantly,
it makes sure that the old ListTag functions work with both the new
`List` and old `ListTagBase`.
The newer List operations should still work on the old ListTags, so make
those changes first to ensure that everything still works as expected if
given an old ListTag.
Next step is to deprecate ListTagBase itself and move all the lists to
the new types.
`vtkm::List` is meant to replace `vtkm::ListTag`. Rather than
subclassing a base class with a variadic template, all lists expose the
list of types.
`vtkm::ListTag` was originally created before we required C++11 so
supporting variadic templates was problematic. To hide the issue we had,
we made list tags subclass other lists rather than be the list
themselves. It makes for nicer types in the compiler, but hides
important details about what is actually in the type. It also creates
lots of unnecessary new types.
The new `vtkm::List` is in some ways simpler. All lists have to be a
`vtkm::List`. Subclasses are not supported (or rather, they will not
work as expected). All manipulations (such as `vtkm::ListAppend`)
resolve directly back to a `vtkm::List`. Although the types reported by
the compiler will be longer, they will be more specific to the types
being used. Also, the new implimentation should ultimately use fewer
types.
