The Microsoft compiler has this annoying and stupid behavior where if
you have a generic templated method/function and that method is
instantiated with a deprecated class, then the compiler will issue a
C4996 warning even if the calling code is suppressing that warning
(because, for example, you are implementing other deprecated code and
the use is correct). There is no way around this other than suppressing
the warnings for all uses of the templated method.
Yet more ways that we can reduce the complexity of `FunctionInterface`.
This is another step in figuring out what set of features the replacement
for `FunctionInterface` needs to have.
The invocation parameters need to be non const as we want to
be able to call non-const methods like `PrepareForOutput` on them
from a transport function.
The original implementation abused the fact that everything
could be copied by value and have that work properly. But
when we start introducing virtual classes copying by value of
a base type can cause type slicing.
There are still some warnings left:
* Some text in markdown files are incorrectly picked up as
doxygen commands
* ArrayPortalTransform weirdly inherits from a specialized
version of itself. It's technically correct C++ code, but
gives doxygen fits.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
For some reason when VTK-m was being compiled as an accelerator in VTK,
Visual Studio 2013 gave a bunch of warnings about not being able to generate
assignment operators for many classes. This happened for classes with a
const ivar that could not be automatically set. (Automatic copy constructors
are fine on this count.) I'm not sure why these warnings did not happen
when just compiling VTK-m, nor am I sure why they were generated at all as
no code actually used the copy constructors.
This commit fixes the problems by adding a private declaration for assignment
operators that cannot be automatically created. No implementation is
provided, nor should any be needed.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
On one of my compile platforms, GCC was giving conversion warnings from
any boost include that was not wrapped in pragmas to disable conversion
warnings. To make things easier and more robust, I created a pair of
macros, VTKM_BOOST_PRE_INCLUDE and VTKM_BOOST_POST_INCLUDE, that should
be wrapped around any #include of a boost header file.
Using enable_if/disable_if as a return type has a negative impact on
binary size compared to use a boost::true/false_type as a method parameter.
For comparison the WorkletTests_TBB sees a 6-7% reduction in binary size when
compiled with O3.
Origin WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2363392 49152 0 4297793536 4300206080 1004ff000
Updated WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2215936 49152 0 4297568256 4299833344 1004a4000
They were declared as in both control and execution, but this would
cause problems when the FunctionInterface contained objects that could
only be copied in the control environment. Using these methods probably
only makes sense in the control environment anyway. (They are a bit
heavyweight to use in an inner loop of the execution environment.)
The functors in the ForEach, StaticTransform, and DynamicTransform
methods sometimes can use the index of the parameter that they are
operating on. This can be a helpful diagnostic in compile and run-time
errors. It is also helpful when linking parameters from one
FunctionInterface with those of another.
This new features are now replacing implementations using the Zip
functionality that was removed earlier. The implementation is actually
simplified a bit.
The Zip function does not work when compiling with CUDA because it
forces the parameters to be in both the control and execution (host and
device) environments.
A couple of tests were failing with the Intel compiler due to
imprecision in comparing floating point values.
Also snuck in some minor documentation fixes in a comment for
FunctionInterface.
These changes support the implementation of DispatcherBase. This class
provides the basic functionality for calling an Invoke method in the
control environment, transferring data to the execution environment,
scheduling threads in the execution environment, pulling data for each
calling of the worklet method, and actually calling the worklet.
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.
The Fetch class is responsible for moving data in and out of some
collection in the execution environment. The Fetch class is templated
with a pair of tags (the type of fetch and the aspect) that control the
mechanism used for the fetch.
In preparation for supporting base types with more widths, add typedefs
for the base types with explicit widths (number of bits).
Also added a IdComponent type that should be used for indices for
components into tuples and vectors. There now should be no reason to use
"int" inside of VTK-m code (especially for indexing). This change cleans
up many of the int types that were used throughout.
This commit removes the usage of the boost preprocessor library to
iteratively generate templates with a variable number of parameters. It
is replaced with a template that is expanded by running it through the
pyexpander macro processing tool (http://pyexpander.sourceforge.net).
One reason for this change is to make the code easier to read. In
particular, it is difficult to understand compiler errors when they
occur deep within an iterating macro. Another reason for this change is
that the Intel compiler currently has a bug that breaks with the boost
preprocessor library.
One issue with this approach is that the macro expansion is not part of
the build process. Although open, pyexpander is not a tool most
developers will have readily installed on their system. Thus, if you
want to make changes to any of the macro code, you have to make sure
pyexpander is installed, then make changes to the input files, then
manually run pyexpander from the command line.
