Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-10-05 09:59:12 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
1ebcde1d30
vtk-m/vtkm/internal/VariantImpl.h

514 lines
17 KiB
C
Raw Normal View History

Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
//
// This software is distributed WITHOUT ANY WARRANTY; without even
// the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
// PURPOSE. See the above copyright notice for more information.
//============================================================================
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
#if !defined(VTK_M_DEVICE) || !defined(VTK_M_NAMESPACE)
#error VariantImpl.h must be included from Variant.h
// Some defines to make my IDE happy.
#define VTK_M_DEVICE
#define VTK_M_NAMESPACE tmp
#endif
#include <vtkm/internal/VariantImplDetail.h>
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
Deprecate ListTag operations The newer List operations should still work on the old ListTags, so make those changes first to ensure that everything still works as expected if given an old ListTag. Next step is to deprecate ListTagBase itself and move all the lists to the new types.
2019-12-05 02:17:19 +00:00
#include <vtkm/Deprecated.h>
#include <vtkm/List.h>
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
Add porting layer for future std features Currently, VTK-m is using C++11. However, it is often useful to use features in the `std` namespace that are defined for C++14 or later. We can provide our own versions (sometimes), but it is preferable to use the version provided by the compiler if available. There were already some examples of defining portable versions of C++14 and C++17 classes in a `vtkmstd` namespace, but these were sprinkled around the source code. There is now a top level `vtkmstd` directory and in it are header files that provide portable versions of these future C++ classes. In each case, preprocessor macros are used to select which version of the class to use.
2020-02-25 23:45:03 +00:00
#include <vtkmstd/aligned_union.h>
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
#include <vtkmstd/is_trivial.h>
Do not use std::is_trivially_copyable on GCC 4.X Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few C++11 features they do not support. One of these features is std::is_trivially_copyable. So on these platforms, do not attempt to use it. Instead, treat nothing as trivially copyable.
2019-10-30 21:53:20 +00:00
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
namespace vtkm
{
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
namespace VTK_M_NAMESPACE
{
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
namespace internal
{
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
// Forward declaration
template <typename... Ts>
class Variant;
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
namespace detail
{
struct VariantCopyFunctor
{
template <typename T>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE void operator()(const T& src, void* destPointer) const noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
new (destPointer) T(src);
}
};
struct VariantDestroyFunctor
{
template <typename T>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE void operator()(T& src) const noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
src.~T();
}
};
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
template <typename... Ts>
struct AllTriviallyCopyable;
template <>
struct AllTriviallyCopyable<> : std::true_type
{
};
template <typename T0>
struct AllTriviallyCopyable<T0>
Do not use std::is_trivially_copyable on GCC 4.X Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few C++11 features they do not support. One of these features is std::is_trivially_copyable. So on these platforms, do not attempt to use it. Instead, treat nothing as trivially copyable.
2019-10-30 21:53:20 +00:00
: std::integral_constant<bool, (vtkmstd::is_trivially_copyable<T0>::value)>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
};
template <typename T0, typename T1>
struct AllTriviallyCopyable<T0, T1>
: std::integral_constant<bool,
Do not use std::is_trivially_copyable on GCC 4.X Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few C++11 features they do not support. One of these features is std::is_trivially_copyable. So on these platforms, do not attempt to use it. Instead, treat nothing as trivially copyable.
2019-10-30 21:53:20 +00:00
(vtkmstd::is_trivially_copyable<T0>::value &&
vtkmstd::is_trivially_copyable<T1>::value)>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
};
template <typename T0, typename T1, typename T2>
struct AllTriviallyCopyable<T0, T1, T2>
: std::integral_constant<bool,
Do not use std::is_trivially_copyable on GCC 4.X Although GCC 4.8 and 4.9 claim to be C++11 compliant, there are a few C++11 features they do not support. One of these features is std::is_trivially_copyable. So on these platforms, do not attempt to use it. Instead, treat nothing as trivially copyable.
2019-10-30 21:53:20 +00:00
(vtkmstd::is_trivially_copyable<T0>::value &&
vtkmstd::is_trivially_copyable<T1>::value &&
vtkmstd::is_trivially_copyable<T2>::value)>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
};
template <typename T0, typename T1, typename T2, typename T3>
struct AllTriviallyCopyable<T0, T1, T2, T3>
clang-format: reformat the repository with clang-format-9
2020-08-17 14:18:24 +00:00
: std::integral_constant<
bool,
(vtkmstd::is_trivially_copyable<T0>::value && vtkmstd::is_trivially_copyable<T1>::value &&
vtkmstd::is_trivially_copyable<T2>::value && vtkmstd::is_trivially_copyable<T3>::value)>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
};
template <typename T0, typename T1, typename T2, typename T3, typename T4, typename... Ts>
struct AllTriviallyCopyable<T0, T1, T2, T3, T4, Ts...>
clang-format: reformat the repository with clang-format-9
2020-08-17 14:18:24 +00:00
: std::integral_constant<
bool,
(vtkmstd::is_trivially_copyable<T0>::value && vtkmstd::is_trivially_copyable<T1>::value &&
vtkmstd::is_trivially_copyable<T2>::value && vtkmstd::is_trivially_copyable<T3>::value &&
vtkmstd::is_trivially_copyable<T4>::value && AllTriviallyCopyable<Ts...>::value)>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
};
template <typename VariantType>
struct VariantTriviallyCopyable;
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
template <typename... Ts>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
struct VariantTriviallyCopyable<vtkm::VTK_M_NAMESPACE::internal::Variant<Ts...>>
: AllTriviallyCopyable<Ts...>
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
};
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
template <typename... Ts>
struct AllTriviallyConstructible;
template <>
struct AllTriviallyConstructible<> : std::true_type
{
};
template <typename T0>
struct AllTriviallyConstructible<T0>
: std::integral_constant<bool, (vtkmstd::is_trivially_constructible<T0>::value)>
{
};
template <typename T0, typename T1>
struct AllTriviallyConstructible<T0, T1>
: std::integral_constant<bool,
(vtkmstd::is_trivially_constructible<T0>::value &&
vtkmstd::is_trivially_constructible<T1>::value)>
{
};
template <typename T0, typename T1, typename T2>
struct AllTriviallyConstructible<T0, T1, T2>
: std::integral_constant<bool,
(vtkmstd::is_trivially_constructible<T0>::value &&
vtkmstd::is_trivially_constructible<T1>::value &&
vtkmstd::is_trivially_constructible<T2>::value)>
{
};
template <typename T0, typename T1, typename T2, typename T3>
struct AllTriviallyConstructible<T0, T1, T2, T3>
: std::integral_constant<bool,
(vtkmstd::is_trivially_constructible<T0>::value &&
vtkmstd::is_trivially_constructible<T1>::value &&
vtkmstd::is_trivially_constructible<T2>::value &&
vtkmstd::is_trivially_constructible<T3>::value)>
{
};
template <typename T0, typename T1, typename T2, typename T3, typename T4, typename... Ts>
struct AllTriviallyConstructible<T0, T1, T2, T3, T4, Ts...>
: std::integral_constant<bool,
(vtkmstd::is_trivially_constructible<T0>::value &&
vtkmstd::is_trivially_constructible<T1>::value &&
vtkmstd::is_trivially_constructible<T2>::value &&
vtkmstd::is_trivially_constructible<T3>::value &&
vtkmstd::is_trivially_constructible<T4>::value &&
AllTriviallyConstructible<Ts...>::value)>
{
};
template <typename VariantType>
struct VariantTriviallyConstructible;
template <typename... Ts>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
struct VariantTriviallyConstructible<vtkm::VTK_M_NAMESPACE::internal::Variant<Ts...>>
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
: AllTriviallyConstructible<Ts...>
{
};
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
template <typename... Ts>
struct VariantStorageImpl
{
Provide implementation of aligned_union Although it is mostly C++11 compliant, GCC 4.8 does not have an implementation of std::aligned_union. We cannot drop this compiler, so provide our own implementation in that case.
2019-07-29 18:57:21 +00:00
typename vtkmstd::aligned_union<0, Ts...>::type Storage;
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
vtkm::IdComponent Index;
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
template <vtkm::IdComponent Index>
Deprecate ListTag operations The newer List operations should still work on the old ListTags, so make those changes first to ensure that everything still works as expected if given an old ListTag. Next step is to deprecate ListTagBase itself and move all the lists to the new types.
2019-12-05 02:17:19 +00:00
using TypeAt = typename vtkm::ListAt<vtkm::List<Ts...>, Index>;
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE void* GetPointer() { return reinterpret_cast<void*>(&this->Storage); }
VTK_M_DEVICE const void* GetPointer() const
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
return reinterpret_cast<const void*>(&this->Storage);
}
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE vtkm::IdComponent GetIndex() const noexcept { return this->Index; }
VTK_M_DEVICE bool IsValid() const noexcept
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
{
return (this->Index >= 0) && (this->Index < static_cast<vtkm::IdComponent>(sizeof...(Ts)));
}
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE void Reset() noexcept
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
if (this->IsValid())
{
this->CastAndCall(detail::VariantDestroyFunctor{});
this->Index = -1;
}
}
template <typename Functor, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE auto CastAndCall(Functor&& f, Args&&... args) const
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
noexcept(noexcept(f(std::declval<const TypeAt<0>&>(), args...)))
-> decltype(f(std::declval<const TypeAt<0>&>(), args...))
{
VTKM_ASSERT(this->IsValid());
return detail::VariantCastAndCallImpl<decltype(f(std::declval<const TypeAt<0>&>(), args...))>(
brigand::list<Ts...>{},
this->GetIndex(),
std::forward<Functor>(f),
this->GetPointer(),
std::forward<Args>(args)...);
}
template <typename Functor, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE auto CastAndCall(Functor&& f, Args&&... args) noexcept(
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
noexcept(f(std::declval<const TypeAt<0>&>(), args...)))
-> decltype(f(std::declval<TypeAt<0>&>(), args...))
{
VTKM_ASSERT(this->IsValid());
return detail::VariantCastAndCallImpl<decltype(f(std::declval<TypeAt<0>&>(), args...))>(
brigand::list<Ts...>{},
this->GetIndex(),
std::forward<Functor>(f),
this->GetPointer(),
std::forward<Args>(args)...);
}
};
template <typename VariantType,
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
typename TriviallyConstructible =
typename VariantTriviallyConstructible<VariantType>::type,
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
typename TriviallyCopyable = typename VariantTriviallyCopyable<VariantType>::type>
struct VariantConstructorImpl;
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
// Can trivially construct, deconstruct, and copy all data. (Probably all trivial classes.)
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
template <typename... Ts>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
struct VariantConstructorImpl<vtkm::VTK_M_NAMESPACE::internal::Variant<Ts...>,
std::true_type,
std::true_type> : VariantStorageImpl<Ts...>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
VariantConstructorImpl() = default;
~VariantConstructorImpl() = default;
VariantConstructorImpl(const VariantConstructorImpl&) = default;
VariantConstructorImpl(VariantConstructorImpl&&) = default;
VariantConstructorImpl& operator=(const VariantConstructorImpl&) = default;
VariantConstructorImpl& operator=(VariantConstructorImpl&&) = default;
};
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
// Can trivially copy, but cannot trivially construct. Common if a class is simple but
// initializes itself.
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
template <typename... Ts>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
struct VariantConstructorImpl<vtkm::VTK_M_NAMESPACE::internal::Variant<Ts...>,
std::false_type,
std::true_type> : VariantStorageImpl<Ts...>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE VariantConstructorImpl() { this->Index = -1; }
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
// Any trivially copyable class is trivially destructable.
~VariantConstructorImpl() = default;
VariantConstructorImpl(const VariantConstructorImpl&) = default;
VariantConstructorImpl(VariantConstructorImpl&&) = default;
VariantConstructorImpl& operator=(const VariantConstructorImpl&) = default;
VariantConstructorImpl& operator=(VariantConstructorImpl&&) = default;
};
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
// Cannot trivially copy. We assume we cannot trivially construct/destruct.
template <typename construct_type, typename... Ts>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
struct VariantConstructorImpl<vtkm::VTK_M_NAMESPACE::internal::Variant<Ts...>,
construct_type,
std::false_type> : VariantStorageImpl<Ts...>
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
{
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE VariantConstructorImpl() { this->Index = -1; }
VTK_M_DEVICE ~VariantConstructorImpl() { this->Reset(); }
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE VariantConstructorImpl(const VariantConstructorImpl& src) noexcept
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
src.CastAndCall(VariantCopyFunctor{}, this->GetPointer());
this->Index = src.Index;
}
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE VariantConstructorImpl& operator=(const VariantConstructorImpl& src) noexcept
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
{
this->Reset();
src.CastAndCall(detail::VariantCopyFunctor{}, this->GetPointer());
this->Index = src.Index;
return *this;
}
};
} // namespace detail
template <typename... Ts>
class Variant : detail::VariantConstructorImpl<Variant<Ts...>>
{
using Superclass = detail::VariantConstructorImpl<Variant<Ts...>>;
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
public:
/// Returns the index of the type of object this variant is storing. If no object is currently
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
/// stored (i.e. the `Variant` is invalid), an invalid is returned.
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
///
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE vtkm::IdComponent GetIndex() const noexcept { return this->Superclass::GetIndex(); }
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
/// Returns true if this `Variant` is storing an object from one of the types in the template
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
/// list, false otherwise.
///
Allow Variant to be trivial Although `vtkm::internal::Variant` respected the trivially copyable attribute of the types it contains, it was never totally trivial (i.e. `std::is_trivial<Variant<...>>` was never true). The reason was that `Variant` was initializing its `Index` parameter to signify that it was not initialized. However, the fact that `Index` was initialized meant that it was not trivially constructed. Now, `Variant` type checks its types to see if they are all trivially constructible. If so, it makes itself trivially constructible. This means that `Index` may or may not be valid if `Variant` is constructed without an argument. This in turn means that the result of `Variant::IsValid` becomes undefined. That should be OK in practice. `Index` will "point" to an uninitialized object, but that object is trivially constructed anyway. However, that could cause problems if developers used `IsValid` to determine if something is selected.
2020-09-22 22:00:26 +00:00
/// Note that if this `Variant` was not initialized with an object, the result of `IsValid`
/// is undefined. The `Variant` could report itself as validly containing an object that
/// is trivially constructed.
///
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE bool IsValid() const noexcept { return this->Superclass::IsValid(); }
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
/// Type that converts to a std::integral_constant containing the index of the given type (or
/// -1 if that type is not in the list).
template <typename T>
More testing of long lists We encountered some issues with `ListIndexOf` for longer lists with repeated elements. Add some tests for that.
2020-01-09 15:19:47 +00:00
using IndexOf = vtkm::ListIndexOf<vtkm::List<Ts...>, T>;
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
/// Returns the index for the given type (or -1 if that type is not in the list).
///
template <typename T>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE static constexpr vtkm::IdComponent GetIndexOf()
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
return IndexOf<T>::value;
}
/// Type that converts to the type at the given index.
///
template <vtkm::IdComponent Index>
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
using TypeAt = typename Superclass::template TypeAt<Index>;
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
/// The number of types representable by this Variant.
///
static constexpr vtkm::IdComponent NumberOfTypes = vtkm::IdComponent{ sizeof...(Ts) };
Fixes for CUDA
2019-07-16 21:41:27 +00:00
Variant() = default;
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
~Variant() = default;
Variant(const Variant&) = default;
Variant(Variant&&) = default;
Variant& operator=(const Variant&) = default;
Variant& operator=(Variant&&) = default;
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
template <typename T>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE Variant(const T& src) noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
Create ArrayHandleMultiplexer
2019-07-15 04:51:28 +00:00
constexpr vtkm::IdComponent index = GetIndexOf<T>();
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
// Might be a way to use an enable_if to enforce a proper type.
VTKM_STATIC_ASSERT_MSG(index >= 0, "Attempting to put invalid type into a Variant");
new (this->GetPointer()) T(src);
this->Index = index;
}
template <typename T>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE Variant(const T&& src) noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
constexpr vtkm::IdComponent index = IndexOf<T>::value;
// Might be a way to use an enable_if to enforce a proper type.
VTKM_STATIC_ASSERT_MSG(index >= 0, "Attempting to put invalid type into a Variant");
new (this->GetPointer()) T(std::move(src));
this->Index = index;
}
template <typename T, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE T& Emplace(Args&&... args)
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
constexpr vtkm::IdComponent I = GetIndexOf<T>();
VTKM_STATIC_ASSERT_MSG(I >= 0, "Variant::Emplace called with invalid type.");
return this->EmplaceImpl<T, I>(std::forward<Args>(args)...);
}
template <typename T, typename U, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE T& Emplace(std::initializer_list<U> il, Args&&... args)
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
constexpr vtkm::IdComponent I = GetIndexOf<T>();
VTKM_STATIC_ASSERT_MSG(I >= 0, "Variant::Emplace called with invalid type.");
return this->EmplaceImpl<T, I>(il, std::forward<Args>(args)...);
}
template <vtkm::IdComponent I, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE TypeAt<I>& Emplace(Args&&... args)
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
VTKM_STATIC_ASSERT_MSG((I >= 0) && (I < NumberOfTypes),
"Variant::Emplace called with invalid index");
return this->EmplaceImpl<TypeAt<I>, I>(std::forward<Args>(args)...);
}
template <vtkm::IdComponent I, typename U, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE TypeAt<I>& Emplace(std::initializer_list<U> il, Args&&... args)
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
VTKM_STATIC_ASSERT_MSG((I >= 0) && (I < NumberOfTypes),
"Variant::Emplace called with invalid index");
return this->EmplaceImpl<TypeAt<I>, I>(il, std::forward<Args>(args)...);
}
private:
template <typename T, vtkm::IdComponent I, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE T& EmplaceImpl(Args&&... args)
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
this->Reset();
T* value = new (this->GetPointer()) T{ args... };
this->Index = I;
return *value;
}
template <typename T, vtkm::IdComponent I, typename U, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE T& EmplaceImpl(std::initializer_list<U> il, Args&&... args)
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
this->Reset();
T* value = new (this->GetPointer()) T(il, args...);
this->Index = I;
return *value;
}
public:
//@{
/// Returns the value as the type at the given index. The behavior is undefined if the
/// variant does not contain the value at the given index.
///
Fixes for CUDA
2019-07-16 21:41:27 +00:00
template <vtkm::IdComponent I>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE TypeAt<I>& Get() noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
Fixes for CUDA
2019-07-16 21:41:27 +00:00
VTKM_ASSERT(I == this->GetIndex());
return *reinterpret_cast<TypeAt<I>*>(this->GetPointer());
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
}
Fixes for CUDA
2019-07-16 21:41:27 +00:00
template <vtkm::IdComponent I>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE const TypeAt<I>& Get() const noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
Fixes for CUDA
2019-07-16 21:41:27 +00:00
VTKM_ASSERT(I == this->GetIndex());
return *reinterpret_cast<const TypeAt<I>*>(this->GetPointer());
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
}
//@}
//@{
/// Returns the value as the given type. The behavior is undefined if the variant does not
/// contain a value of the given type.
///
template <typename T>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE T& Get() noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
VTKM_ASSERT(this->GetIndexOf<T>() == this->GetIndex());
return *reinterpret_cast<T*>(this->GetPointer());
}
template <typename T>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE const T& Get() const noexcept
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
VTKM_ASSERT(this->GetIndexOf<T>() == this->GetIndex());
return *reinterpret_cast<const T*>(this->GetPointer());
}
//@}
//@{
/// Given a functor object, calls the functor with the contained object cast to the appropriate
/// type. If extra \c args are given, then those are also passed to the functor after the cast
/// object. If the functor returns a value, that value is returned from \c CastAndCall.
///
/// The results are undefined if the Variant is not valid.
///
template <typename Functor, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE auto CastAndCall(Functor&& f, Args&&... args) const
Sprinkle noexcept goodness on Variant and ArrayPortalMultiplexer Allow Variant copy constructor/operators and its CastAndCall to operate in noexcept methods. This can help the compiler make optimizations.
2019-07-25 21:25:29 +00:00
noexcept(noexcept(f(std::declval<const TypeAt<0>&>(), args...)))
-> decltype(f(std::declval<const TypeAt<0>&>(), args...))
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
{
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
return this->Superclass::CastAndCall(std::forward<Functor>(f), std::forward<Args>(args)...);
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
}
template <typename Functor, typename... Args>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE auto CastAndCall(Functor&& f, Args&&... args) noexcept(
Sprinkle noexcept goodness on Variant and ArrayPortalMultiplexer Allow Variant copy constructor/operators and its CastAndCall to operate in noexcept methods. This can help the compiler make optimizations.
2019-07-25 21:25:29 +00:00
noexcept(f(std::declval<const TypeAt<0>&>(), args...)))
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
-> decltype(f(std::declval<TypeAt<0>&>(), args...))
{
Register Variant as trivially copyable if possible The Variant template can hold any type. If it is holding a type that is non-copyable, then it has to make sure that appropriate constructors, copiers, movers, and destructors are called. Previously, these were called even the Variant was holding a trivially copyable class because no harm no foul. If you were holding a trivially copyable class and did a memcpy, that work work, which should make it possible to copy between host and device, right? In theory yes, but in practice no. The problem is that Cuda is outsmarting the code. It is checking that Variant is not trivially- copyable by C++ semantics and refusing to push it. So, change Variant to check to see if all its supported classes are trivially copyable. If they are, then it use the default constructors, destructors, movers, and copiers so that C++ recognizes it as trivially copyable.
2019-10-26 03:43:22 +00:00
return this->Superclass::CastAndCall(std::forward<Functor>(f), std::forward<Args>(args)...);
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
}
/// Destroys any object the Variant is holding and sets the Variant to an invalid state. This
/// method is not thread safe.
///
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
VTK_M_DEVICE void Reset() noexcept { this->Superclass::Reset(); }
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
};
Avoid touching ListTag internals 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.
2019-07-15 03:35:45 +00:00
/// \brief Convert a ListTag to a Variant.
///
Deprecate ListTag operations The newer List operations should still work on the old ListTags, so make those changes first to ensure that everything still works as expected if given an old ListTag. Next step is to deprecate ListTagBase itself and move all the lists to the new types.
2019-12-05 02:17:19 +00:00
/// Depricated. Use ListAsVariant instead.
///
Avoid touching ListTag internals 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.
2019-07-15 03:35:45 +00:00
template <typename ListTag>
Deprecate ListTag operations The newer List operations should still work on the old ListTags, so make those changes first to ensure that everything still works as expected if given an old ListTag. Next step is to deprecate ListTagBase itself and move all the lists to the new types.
2019-12-05 02:17:19 +00:00
using ListTagAsVariant VTKM_DEPRECATED(
1.6,
"vtkm::ListTag is no longer supported. Use vtkm::List instead.") =
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
vtkm::ListApply<ListTag, vtkm::VTK_M_NAMESPACE::internal::Variant>;
Deprecate ListTag operations The newer List operations should still work on the old ListTags, so make those changes first to ensure that everything still works as expected if given an old ListTag. Next step is to deprecate ListTagBase itself and move all the lists to the new types.
2019-12-05 02:17:19 +00:00
/// \brief Convert a `List` to a `Variant`.
///
template <typename List>
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
using ListAsVariant = vtkm::ListApply<List, vtkm::VTK_M_NAMESPACE::internal::Variant>;
}
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
}
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
} // namespace vtkm::VTK_M_NAMESPACE::internal
Add Variant vtkm::internal::Variant is a simplified version of C++17's std::variant or boost's variant. It is a template that takes a list of types. The Variant may be set to any one of those types. A CastAndCall allows you to call a functor with the appropriately cast type.
2019-07-14 23:38:30 +00:00
Make separate exec and cont versions of Variant The `Variant` class is templated to hold objects of other types. Depending on whether those objects of are meant to be used in the control or execution side, the methods on `Variant` might need to be declared with (or without) special modifiers. We can sometimes try to compile the `Variant` methods for both host and device and ask the device compiler to ignore incompatibilities, but that does not always work. To get around that, create two different implementations of `Variant`. Their API and implementation is exactly the same except one declares its methods with `VTKM_CONT` and the other its methods `VTKM_EXEC`.
2020-10-06 21:57:04 +00:00
#undef VTK_M_DEVICE
#undef VTK_M_NAMESPACE
Reference in New Issue Copy Permalink