This allows for developers to do things such as the following
as constexpr's:
```cxx
constexpr vtkm::Id2 dims(16,16);
constexpr vtkm::Float64 dx = vtkm::Float64(4.0 * vtkm::Pi()) / vtkm::Float64(dims[0] - 1);
```
bf96d921d Add extra braces around std::array initializers
9bbf4a5a6 Corrections and expanded testing of implicit functions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !1776
Because ArrayPortalSOA calls a delegate portal to get the actual values,
it can only implement its own Set or Get if the delegate portal supports
it. Previously this was done by calling an overloaded internal method
based on the result of PortalSupportsSets/Gets. However, regardless of
whether the delegate portal supported Set or Get, ArrayPortalSOA
provided one. Thus, if something else tried to use PortalSupportsSets/
Gets on ArrayPortalSOA, it would always report true even if it was not
really supported.
Instead, use SFINAE to remove the Set or Get if that method is not
supported in the delegate portal.
Since ArrayHandleSOA is only really used for portals from basic storage
arrays, it will be rare that Set or Get is not supported. However, a
device adapter is free to remove one of these methods on a device
portal. For example, if you call PrepareForInput on an ArrayHandle, it
is possible that the device adapter will create a portal that has no Set
method because the array is not writable.
Thanks to Allison Vacanti for recomending this solution.
I kept getting warnings from different compilers about type conversions
because I was making values by adding an index to them. Change how we
create and test values so that these type issues are less likely to come
up.
This appears to be a bug in older clang and gcc compilers where they
gave a warning asking for an extra unnecessary set of braces around the
initializer of std::array. See for example
https://bugs.llvm.org/show_bug.cgi?id=21629https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
I don't think newer compilers give this warning, but we still support
some older compilers it happens on, so we live with it.
To help provide a better time writing VTK-m filter this streamlines
the CreateResult API to provide a focused set of methods, based on
how CreateResult has been used by existing filters.
For demonstration purposes, I added a vector field to one of the data
sets (the cow nose). However, the serialization test was not expecting a
field of that type and therefore had not compiled the case to serialize
that type of field, which caused a failure. Fixed the problem by
instructing the test to also consider the correct type of vector fields.
The `From` and `To` nomenclature for topology mapping has been confusing for
both users and developers, especially at lower levels where the intention of
mapping attributes from one element to another is easily conflated with the
concept of mapping indices (which maps in the exact opposite direction).
These identifiers have been renamed to `VisitTopology` and `IncidentTopology`
to clarify the direction of the mapping. The order in which these template
parameters are specified for `WorkletMapTopology` have also been reversed,
since eventually there may be more than one `IncidentTopology`, and having
`IncidentTopology` at the end will allow us to replace it with a variadic
template parameter pack in the future.
Other implementation details supporting these worklets, include `Fetch` tags,
`Connectivity` classes, and methods on the various `CellSet` classes (such as
`PrepareForInput` have also reversed their template arguments. These will need
to be cautiously updated.
The convenience implementations of `WorkletMapTopology` have been renamed for
clarity as follows:
```
WorkletMapPointToCell --> WorkletVisitCellsWithPoints
WorkletMapCellToPoint --> WorkletVisitPointsWithCells
```
The `ControlSignature` tags have been renamed as follows:
```
FieldInTo --> FieldInVisit
FieldInFrom --> FieldInMap
FromCount --> IncidentElementCount
FromIndices --> IncidentElementIndices
```
The Invoker is a control side object that handles the construction
of the relevant worklet dispatcher. Moving it to control makes it
obvious that it isn't an algorithm itself but a way to launch
worklets.
There was a special case for ArrayHandleMultiplexer where if you gave it
just one type it would treat that as a value type rather than an array
to support and instead provide a default list of types. However, GCC 4.8
is having trouble compiling the code to create the default list, the
semantics are confusing, and the more I think about it the less likely I
think we will need this functionality. So, just getting rid of that.
d80a8125c Sprinkle noexcept goodness on Variant and ArrayPortalMultiplexer
a96a13cf3 Use large case statements to CastAndCall variants
866e1d7d5 Update comparison for virtual and multiplexer arrays
5416cbeb7 Add ArrayHandleMultiplexer testing to BenchmarkFieldAlgorithms
d45106452 Add changedoc for ArrayHandleMultiplexer
0aa15c97c Fix 'Failed to specialize alias template' error from Visual Studio
7b72e31df Fixes for CUDA
5e2385352 Create ArrayHandleMultiplexer
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1726
The code was working fine on all the dashboards except for the Visual
Studio 2015 compiles on delve. It gave an error like:
ArrayHandleMultiplexer.h(398): error C2938: 'ArrayHandleToStorageTag<unknown-type>' : Failed to specialize alias template
A StackOverflow article (https://stackoverflow.com/questions/43411542/
metaprogramming-failed-to-specialize-alias-template) suggests that this
is a bug in older versions of Visual Studio. Although fixed in more
recent versions, we might have to support older versions.
Currently, ListTags are implemented by having a subtype name list set to
a brigand::list. However, there is always a chance this will change. To
make things more explicit, create a vtkm::internal::ListTagToBrigandList
to make it clear what the resulting type should be (and provide some
potential future-proofing).
Also add a convenient vtkm::ListTagApply that allows you to easily
instantiate a template with the list of types in a ListTag.
