- Exception classes cannot be exported due to MSVC's design decisions.
See http://stackoverflow.com/questions/24511376. We must leave these
classes as header only and silence the warnings.
- TransferResource in BufferState.h must remain a header-only class since
there is no vtkm_interop library to compile the class into.
- The VTKDataSetReader hierarchy must similarly remain header-only since
there is no vtkm_io library.
- The OptionParser Action classes are part of a header-only utility and
cannot be easily compiled into a library.
-
windows.h was only being included for MSVC, while in UnitTestTimer.cxx, the
Windows function Sleep was being called after check for _WIN32. This was
causing compilation failure in MINGW.
Fixes#122
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.
It is common practice to swallow a semicolon in a macro using a do/
while(false) loop that only executes once. However, the Visual Studio
2013 compiler was stupidly warning about having a constant expression
for the loop. Get around the problem by creating our own swallow
semicolon macros that disable this warning as necessary.
We previously included windows.h in numerous locations using different
techniques to guard against bringing in parts of the file that are bad
(min/max macros, etc). This solves the problem by consistently using
vtkm/internal/Windows.h to setup everything.
This is a fancy array handle that can group entries in another array by
arbitrary amounts. This allows us to implement input and output arrays
with a different sized Vec for each instance. This is necessary for
generating new topologies with cells of different types.
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.
In VTK-m libraries, we are typically exporting (with declspec) classes rather
than the independent methods within the class. When you are exporting to a
dll in MSVC and the class contains a field that is not similarly exported,
then you get a warning. This is generally not an issue for our use since we
are really only using classes from the standard library and distributed with
VTK-m itself. The only sane way to fix the issue is to just disable the
warning.
This is using the C++11 override keyword to make the compiler check to
ensure that we are correctly overriding virtual methods when we mean to.
Currently this will not compile without C++11. However, we are planning
on moving to C++11 very soon, and we can fix the macro if we don't.
a6609311 Silence auto_ptr deprecation warnings with older boosts ( < 1.61 )
6d38f44d Update ListTag and DispatcherBase to leverage C++11 features.
ea0d84a8 Remove VTK-m Variadic defines and replace them with a single CXX11 define
77121d18 Add support to VTK-m to build with C++11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !475
The VTKM_SUPPRESS_EXEC_WARNINGS should go before the template keyword,
but on a couple of methods in FunctionInterfaceDetailPre.h.in it was
after the template keyword.
Add pragmas to disable warnings 4244 and 4800 on Visual Studio when
compiling third party libraries. This gets around some warnings inside
the thrust library.
This is a little tricky since they don't seem to have considered that
you will have files in both the source and build directory or that the
file locations will not match exactly with the install locations.
The test is a simple CMake script that finds all files in the build
directory with certain extensions (.h, .cxx, etc.) and makes sure that
the filename is listed somewhere in the CMakeLists.txt file of the same
directory. If the filename is listed in the CMakeLists.txt file, then
there is a good chance it is being addressed by the build.
This should help catch when header files are not being installed. It also
should help verify that test builds are being done on all files. It will
also highlight dead source files.
MSVC has a warning for using "unsafe" algorithms such as fill_n that can
easily overrun the end of unchecked pointers. The problem is that there
are lots of valid uses of these algorithms, and the signal that this is
a valid use is MSVC-specific. Even less fortunate is the fact that if
another header violates the warning, it is impossible to suppress it
because it happens in a system header file (xutility), which was included
far before the actual offending code occured. Even less fortunate than
that, a boost header we (indirectly) use sets off this warning, cannot
be suppressed, and is not going to be fixed
(https://svn.boost.org/trac/boost/ticket/11426). The best solution is to
turn off this problematic warning for everybody.
