It was originally put there to support CopyInto in ArrayHandle, but that
has already been removed. It really only makes sense for trivial
examples and testing code, and it sometimes causes complications with
coding.
There is a special version of the testing methods for use in the control
environment that handles execeptions that can be thrown there. There are
tests to make sure you are using the correct version of the testing
framework, but it was broken until the last commit. Now that it's fixed,
here are two places where the wrong testing method was used.
We made this change a while ago to help with completion in IDEs.
(Completion was matching a bunch of wrapper macros that were almost
never used anywhere.) Most of the changes are in comments, but there are
a few bad macro definitions.
Whenever creating a functor to be launched in the execution environment
using the device adapter Schedule algorithm, you had to also create a
couple of methods to handle error message buffers. For convenience, lots
of code started to just inherit from WorkletBase. Although this worked,
it was a misnomer (and might cause problems in the future if worklets
later require different things from its base). To get around this
problem, add a FunctorBase class that is intended to be used as the
superclass to functors called with Schedule.
Previously, VTKM_DEVICE_ADAPTER_UNDEFINED and
VTKM_ARRAY_CONTAINER_CONTROL_UNDEFINED were set to 0. The problem is
that if someone set VTKM_DEVICE_ADAPTER or VTKM_ARRAY_CONTAINER_CONTROL
to something invalid, that would test positive when compared to 0. Thus,
you get an error about not defining the default when in fact the problem
is setting an invalid flag.
This change makes the undefined constants -1 so that the comparison will
fail unless the macro is actually properly set.
Getting the type right for ArrayHandleCompositeVector can be a bit
tricky. It is expressed in a somewhat strange function signature format
and you have to extract the right component type for the return. This
adds an ArrayHandleCompositeVectorType that makes it easier (although no
less verbose).
Using alignment on basic types when vtkm only targetted Linux/BSD/OSX was
'okay' because of how the alignment operators worked, but potential was going
to cause issues in the long run if we failed to detect the correct size and the
compiler was than forced to not use intrinsics.
Now with adding windows support we have run into another problem. Basically
using an alignment operator on a typedef means that the type must never
be passed by value, but must always be passed by reference. The reason for
this is that passing by value doesn't respect alignment requirements, and
can cause very subtle errors or crashes.
A really good read for people more interested in these problems:
http://eigen.tuxfamily.org/dox/group__TopicPassingByValue.htmlhttp://eigen.tuxfamily.org/dox-devel/group__DenseMatrixManipulation__Alignement.html
Each type of point coordinates has its own class with the name
PointCoordinates*. Currently there is a PointCoordiantesArray that contains
an ArrayHandle holding the point coordinates and a PointCoordinatesUniform
that takes the standard extent, origin, and spacing for a uniform rectilinear
grid and defines point coordiantes for that. Creating new PointCoordinates
arrays is pretty easy, and we will almost definitely add more. For example,
we should have an elevation version that takes uniform coordinates for
a 2D grid and then an elevation in the third dimension. We can probably
also use a basic composite point coordinates that can build them from
other coordinates.
There is also a DynamicPointCoordinates class that polymorphically stores
an instance of a PointCoordinates class. It has a CastAndCall method that
behaves like DynamicArrayHandle; it can call a functor with an array handle
(possible implicit) that holds the point coordinates.
This derived array handle creates an array of vectors whose components come
from other arrays of vectors. In either case ArrayHandleCompositeVector
handles scalars as vectors of size 1.
This will allow a faster conversion than the dynamic transform and will
allow you to define compile-time types for transformation unlike dynamic
transform or invoke with transform.
This is used with the FunctionInterface::DynamicTransformCont method to
convert a call of arguments using dynamic array handles to a function
templated on concrete types.
The FunctionInterface class is a convienient way to wrap up a variable
number of arguments and pass them around templated interfaces without
requiring variadic template arguments. It also correctly hands return
arguments.
Use this mechanism in the dynamic array handle to skip over trying
invalid array handle types (and thereby incurring a compiler error even
though we never intended to use these classes).
The dynamic array handle holds a reference to an array handle of an
unknown type. It contains the ability to try to cast it to an instance
of array handle or to try lists of types and containers.
There is currently an issue that is causing the test code not to
compile. It is the case that some combinations of types and containers
are not compatible. For example, an implict container is bound to a
certain type, and the container is undefined if they do not agree. There
needs to be a mechanism to detect these invalid combinations and skip
over them in the MTP for each.
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.
