This is to be used in place of BOOST_STATIC_ASSERT so that we can
control its implementation.
The implementation is designed to fix the issue where the latest XCode
clang compiler gives a warning about a unused typedefs when the boost
static assert is used within a function. (This warning also happens when
using the C++11 static_assert keyword.) You can suppress this warning
with _Pragma commands, but _Pragma commands inside a block is not
supported in GCC. The implementation of VTKM_STATIC_ASSERT handles all
current cases.
This class implicitly stores the point coordinates for a rectilinear
cell (such as a voxel) with just the location of the lower left point
and the spacing in each dimension. In addition to saving space, this
class should allow cell-specific functions to specialize for faster
processing.
We have been using the term "shape" in the cell set and connectivity
classes. To be consistent, use the term "shape" for the geometric
identify of the cell everywhere.
This class holds a Vec and exposes some number of components. The class
is used when you need a Vec of a size that is not known at compile time
but that a maximum length of reasonable size is known.
Clean up CellSet
Underneath the CellSet implementation is a set of supporting classes that manage the actual structure in both the control and execution environments. However, the implementation of these classes was a bit confusing and inconsistent. The following changes are made:
* Most significantly, there is no longer any Connectivity classes in the control environment. This functionality has been wrapped up into the CellSet classes, which is more consistent and easier to understand. (There was a definite distinction between CellSet and Connectivity, but it was subtle and difficult to understand.) This also means that edits to CellSets happen to CellSets directly.
* The set of classes for structured and explicit cell sets match. There is different functionality within, but the class naming and meaning are consistent.
* Make the class names more consistent with the rest of VTK-m class names. Specifically classes like ExplicitConnectivity become ConnectivityExplicit. Also, the words regular and structured were being used interchangeably. Now, always use structured except when dealing specifically with grids of regular spacing.
* The connectivity classes were using the nomenclature "From" and "To" to specify topological elements of links. The same concept in worklet classes were using the nomenclature "Src" and "Dest." For consistency, all references are changed to "From" and "To".
* Unlike explicit cell sets, structured cell sets have functionality shared between control and execution environments. Rather than duplicate it or create unique exposed classes, have a shared internal implementation in vtkm::internal.
See merge request !117
Previously there was a Connectivity* structure for both the control
environment and the execution environment. This was necessary before
because the connectivity is explicit to the from and to topology
elements, so you would get this structure from the appropriate call to
CellSet*. However, the symantics are changed so that the type of
connectivity is selected in the worklet's dispatcher. Thus, it is now
much cleaner to manage the CellSet structure in the CellSet class itself
and just have a single set of Connectivity* classes in the execution
environment.
Also moved from vtkm namespace to vtkm::internal namespace. This change
is to then move the structured connectivity classes to the cont and exec
namespaces.
Previously, the items used to identify parts of topology like points,
cells, faces, etc. were in an enumeration. However, they are only really
used in template specialization, and it is easier to use tags in this
case. So, change the enumeration to a set of tag structures. Also made
the following changes:
* Renamed TopologyType to TopologyElement, which is more indicative of
what we are referring to.
* Moved the structures from the vtkm::cont namespace to the vtkm
namespace. There is no reason not to be able to use them from either the
control or execution environments.
* Added a VTKM_IS_TOPOLOGY_ELEMENT_TAG macro to do type checks on
template arguments that are supposed to be topology element tags.
The zip capability allows you to parameter-wise combine two
FunctionInterface objects. The result is another FunctionInterface with
each parameter a Pair containing the respective values of the two
inputs.
Being able to zip allows you to do transforms and invokes on data that
is divided among multiple function interface objects.
Provies a list of types in a template like boost::mpl::vector and a
method to call a functor on each type. However, rather than explicitly
list each type, uses tags to identify the list. This provides the
following main advantages:
1. Can use these type lists without creating horrendously long class
names based on them, making compiler errors easier to read. For example,
you would have a typename like MyClass<TypeListTagVectors> instead of
MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic
templates are not supported). This is the main motivation for this
implementation.
2. Do not require variadic templates and usually few constructions. That
should speed compile times.
There is one main disadvantage to this approach: It is difficult to get
a printed list of items in a list during an error. If necessary, it
probably would not be too hard to make a template to convert a tag to a
boost mpl vector.
