Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-10-08 11:29:02 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
5fd3a18de0
vtk-m/vtkm/exec/testing/UnitTestVariant.cxx

625 lines
26 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.
//============================================================================
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
#include <vtkm/exec/Variant.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
#include <vtkm/testing/Testing.h>
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
#include <cstdlib>
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
#include <vector>
Try to fix uninitialized anonymous variable warning The code from the previous commit was causing one of the dashboards, which is using gcc-7, to produce the following warning: In file included from ../testing/UnitTestVariant.cxx:11:0: ../Variant.h: In function 'void {anonymous}::TestCopyDestroy()': ../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized] this->Storage = std::move(rhs.Storage); ^~~~ At best, this warning is not helpful as it does not seem to point to anything that could be used uninitialized. At worst, it might be a compiler bug. A Google search finds a few similar bugs although none I can assert with any confidence of this issue. However, many reported bugs and issues point to the use of anonymous namespaces. So, I'm going to attempt to fix the problem by removing anonymous namespaces. Hopefully it will fix the warning or at least point me to something concrete that I can fix.
2019-10-27 13:33:45 +00:00
namespace test_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
{
template <vtkm::IdComponent Index>
struct TypePlaceholder
{
Fix issue with Variant::CastAndCall with non-const reference There was a typo in the declaration of the `CastAndCall` for a non-const `Variant`. When determining the `noexcept` status of the function being called, it was passing in a const reference instead of a regular reference, which is what is actually passed to the function. This potentially causes the function call to not match and fail to compile.
2022-07-25 16:07:22 +00:00
vtkm::IdComponent Value = 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
};
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
// A class that is trivially copiable but not totally trivial.
struct TrivialCopy
{
vtkm::Id Value = 0;
};
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
static vtkm::Id g_NonTrivialCount;
// A class that must is not trivial to copy nor construct.
struct NonTrivial
{
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
vtkm::Id Value;
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
NonTrivial* Self;
void CheckState() const
{
VTKM_TEST_ASSERT(this->Value == 12345);
VTKM_TEST_ASSERT(this->Self == this);
}
NonTrivial()
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
: Value(12345)
, Self(this)
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
{
this->CheckState();
++g_NonTrivialCount;
}
NonTrivial(const NonTrivial& src)
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
: Value(src.Value)
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
{
src.CheckState();
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
this->Self = this;
this->CheckState();
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
++g_NonTrivialCount;
}
NonTrivial& operator=(const NonTrivial& src)
{
this->CheckState();
src.CheckState();
return *this;
}
~NonTrivial()
{
if ((this->Value == 12345) && (this->Self == this))
{
// Normal destruction
this->Value = -1;
this->Self = nullptr;
--g_NonTrivialCount;
}
else
{
// Normally we would use VTKM_TEST_ASSERT or VTKM_TEST_FAIL, but it's not good to throw
// exceptions from destructors (especially since Variant marks these calls as noexcept).
// Instead, just check and terminate the program.
std::cout << "ERROR at " << __FILE__ << ":" << __LINE__ << ":\n";
std::cout << "Destroying a class that was not properly constructed." << std::endl;
std::exit(1);
}
}
};
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
void TestSize()
{
std::cout << "Test size" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<float, double, char, short, int, long>;
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 size_t variantSize = sizeof(VariantType);
VTKM_TEST_ASSERT(variantSize <= 16,
"Size of variant should not be larger than biggest type plus and index. ",
variantSize);
}
void TestIndexing()
{
std::cout << "Test indexing" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<TypePlaceholder<0>,
TypePlaceholder<1>,
TypePlaceholder<2>,
TypePlaceholder<3>,
TypePlaceholder<4>,
TypePlaceholder<5>,
TypePlaceholder<6>,
TypePlaceholder<7>,
TypePlaceholder<8>,
TypePlaceholder<9>,
TypePlaceholder<10>,
TypePlaceholder<11>,
TypePlaceholder<12>,
TypePlaceholder<13>,
TypePlaceholder<14>,
TypePlaceholder<15>,
TypePlaceholder<16>,
TypePlaceholder<17>,
TypePlaceholder<18>,
TypePlaceholder<19>,
TypePlaceholder<20>,
TypePlaceholder<21>,
TypePlaceholder<22>,
TypePlaceholder<23>,
TypePlaceholder<24>,
TypePlaceholder<25>,
TypePlaceholder<26>,
TypePlaceholder<27>,
TypePlaceholder<28>,
TypePlaceholder<29>>;
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
VariantType variant;
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<0>>::value == 0);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<1>>::value == 1);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<2>>::value == 2);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<3>>::value == 3);
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
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<4>>::value == 4);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<5>>::value == 5);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<6>>::value == 6);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<7>>::value == 7);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<8>>::value == 8);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<9>>::value == 9);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<10>>::value == 10);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<11>>::value == 11);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<12>>::value == 12);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<13>>::value == 13);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<14>>::value == 14);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<15>>::value == 15);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<16>>::value == 16);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<17>>::value == 17);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<18>>::value == 18);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<19>>::value == 19);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<20>>::value == 20);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<21>>::value == 21);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<22>>::value == 22);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<23>>::value == 23);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<24>>::value == 24);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<25>>::value == 25);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<26>>::value == 26);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<27>>::value == 27);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<28>>::value == 28);
VTKM_TEST_ASSERT(VariantType::IndexOf<TypePlaceholder<29>>::value == 29);
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_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<0>>() == 0);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<1>>() == 1);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<2>>() == 2);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<3>>() == 3);
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
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<4>>() == 4);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<5>>() == 5);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<6>>() == 6);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<7>>() == 7);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<8>>() == 8);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<9>>() == 9);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<10>>() == 10);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<11>>() == 11);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<12>>() == 12);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<13>>() == 13);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<14>>() == 14);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<15>>() == 15);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<16>>() == 16);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<17>>() == 17);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<18>>() == 18);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<19>>() == 19);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<20>>() == 20);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<21>>() == 21);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<22>>() == 22);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<23>>() == 23);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<24>>() == 24);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<25>>() == 25);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<26>>() == 26);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<27>>() == 27);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<28>>() == 28);
VTKM_TEST_ASSERT(variant.GetIndexOf<TypePlaceholder<29>>() == 29);
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((std::is_same<VariantType::TypeAt<0>, TypePlaceholder<0>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<1>, TypePlaceholder<1>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<2>, TypePlaceholder<2>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<3>, TypePlaceholder<3>>::value));
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
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<4>, TypePlaceholder<4>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<5>, TypePlaceholder<5>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<6>, TypePlaceholder<6>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<7>, TypePlaceholder<7>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<8>, TypePlaceholder<8>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<9>, TypePlaceholder<9>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<10>, TypePlaceholder<10>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<11>, TypePlaceholder<11>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<12>, TypePlaceholder<12>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<13>, TypePlaceholder<13>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<14>, TypePlaceholder<14>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<15>, TypePlaceholder<15>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<16>, TypePlaceholder<16>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<17>, TypePlaceholder<17>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<18>, TypePlaceholder<18>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<19>, TypePlaceholder<19>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<20>, TypePlaceholder<20>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<21>, TypePlaceholder<21>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<22>, TypePlaceholder<22>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<23>, TypePlaceholder<23>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<24>, TypePlaceholder<24>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<25>, TypePlaceholder<25>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<26>, TypePlaceholder<26>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<27>, TypePlaceholder<27>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<28>, TypePlaceholder<28>>::value));
VTKM_STATIC_ASSERT((std::is_same<VariantType::TypeAt<29>, TypePlaceholder<29>>::value));
Handle `Variant::Get` for types not supported by the `Variant` Previously, if you called `Get` on a `Variant` with a type that is not in the list of types supported by the `Variant`, that would attempt to look up the type at index `-1` and could spin the compiler into an endless loop. Instead, check for the case where you are attempting to get a type from the `Variant` not listed in its templat arguments. In this case, instead of producing a compiler error, produce a runtime error. Although this increases the possibility that a bad compile path is being generated, it simplifies creating templated code that produces cases we don't care about.
2021-10-04 16:19:25 +00:00
VTKM_TEST_ASSERT(VariantType::CanStore<TypePlaceholder<2>>::value);
VTKM_TEST_ASSERT(!VariantType::CanStore<TypePlaceholder<100>>::value);
VTKM_TEST_ASSERT(variant.GetCanStore<TypePlaceholder<3>>());
VTKM_TEST_ASSERT(!variant.GetCanStore<TypePlaceholder<101>>());
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
void TestTriviallyCopyable()
{
Be more conservative about is_trivial support `std::is_trivial` is part of the C++14 specification. However, we have encountered multiple compilers that purport to implement C++14 but do not implement `std::is_trivial` and the like checks correctly. To avoid such issues, only use `std::is_trivial` on compilers that we have tested to support it.
2021-03-01 22:10:10 +00:00
#ifdef VTKM_USE_STD_IS_TRIVIAL
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 sure base types are behaving as expected
Minor style changes in UnitTestVariant
2021-04-01 20:47:51 +00:00
VTKM_STATIC_ASSERT(vtkmstd::is_trivially_constructible<float>::value);
VTKM_STATIC_ASSERT(vtkmstd::is_trivially_copyable<float>::value);
VTKM_STATIC_ASSERT(vtkmstd::is_trivial<float>::value);
VTKM_STATIC_ASSERT(vtkmstd::is_trivially_constructible<int>::value);
VTKM_STATIC_ASSERT(vtkmstd::is_trivially_copyable<int>::value);
VTKM_STATIC_ASSERT(vtkmstd::is_trivial<int>::value);
VTKM_STATIC_ASSERT(!vtkmstd::is_trivially_constructible<NonTrivial>::value);
VTKM_STATIC_ASSERT(!vtkmstd::is_trivially_copyable<NonTrivial>::value);
VTKM_STATIC_ASSERT(!vtkmstd::is_trivial<NonTrivial>::value);
VTKM_STATIC_ASSERT(!vtkmstd::is_trivially_constructible<TrivialCopy>::value);
VTKM_STATIC_ASSERT(vtkmstd::is_trivially_copyable<TrivialCopy>::value);
VTKM_STATIC_ASSERT(!vtkmstd::is_trivial<TrivialCopy>::value);
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
// A variant of trivially constructable things should be trivially constructable
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_STATIC_ASSERT(
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
(vtkmstd::is_trivially_constructible<vtkm::exec::detail::VariantUnion<float, int>>::value));
VTKM_STATIC_ASSERT((vtkmstd::is_trivially_constructible<vtkm::exec::Variant<float, int>>::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
// A variant of trivially copyable things should be trivially copyable
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
VTKM_STATIC_ASSERT((vtkmstd::is_trivially_copyable<
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
vtkm::exec::detail::VariantUnion<float, int, TrivialCopy>>::value));
VTKM_STATIC_ASSERT(
(vtkmstd::is_trivially_copyable<vtkm::exec::Variant<float, int, TrivialCopy>>::value));
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
// A variant of any non-trivially constructable things is not trivially copyable
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
VTKM_STATIC_ASSERT((!vtkmstd::is_trivially_constructible<
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
vtkm::exec::detail::VariantUnion<NonTrivial, float, int>>::value));
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
VTKM_STATIC_ASSERT((!vtkmstd::is_trivially_constructible<
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
vtkm::exec::detail::VariantUnion<float, NonTrivial, int>>::value));
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
VTKM_STATIC_ASSERT((!vtkmstd::is_trivially_constructible<
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
vtkm::exec::detail::VariantUnion<float, int, NonTrivial>>::value));
VTKM_STATIC_ASSERT(
(!vtkmstd::is_trivially_constructible<vtkm::exec::Variant<NonTrivial, float, int>>::value));
VTKM_STATIC_ASSERT(
(!vtkmstd::is_trivially_constructible<vtkm::exec::Variant<float, NonTrivial, int>>::value));
VTKM_STATIC_ASSERT(
(!vtkmstd::is_trivially_constructible<vtkm::exec::Variant<float, int, NonTrivial>>::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
// A variant of any non-trivially copyable things is not trivially copyable
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
VTKM_STATIC_ASSERT((!vtkmstd::is_trivially_copyable<
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
vtkm::exec::detail::VariantUnion<NonTrivial, float, int>>::value));
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
VTKM_STATIC_ASSERT((!vtkmstd::is_trivially_copyable<
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
vtkm::exec::detail::VariantUnion<float, NonTrivial, int>>::value));
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
VTKM_STATIC_ASSERT((!vtkmstd::is_trivially_copyable<
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
vtkm::exec::detail::VariantUnion<float, int, NonTrivial>>::value));
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_STATIC_ASSERT(
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
(!vtkmstd::is_trivially_copyable<vtkm::exec::Variant<NonTrivial, float, int>>::value));
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_STATIC_ASSERT(
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
(!vtkmstd::is_trivially_copyable<vtkm::exec::Variant<float, NonTrivial, int>>::value));
VTKM_STATIC_ASSERT(
(!vtkmstd::is_trivially_copyable<vtkm::exec::Variant<float, int, NonTrivial>>::value));
// A variant of trivial things should be trivial
VTKM_STATIC_ASSERT((vtkmstd::is_trivial<vtkm::exec::Variant<float, int>>::value));
VTKM_STATIC_ASSERT((!vtkmstd::is_trivial<vtkm::exec::Variant<float, int, TrivialCopy>>::value));
VTKM_STATIC_ASSERT((!vtkmstd::is_trivial<vtkm::exec::Variant<float, int, NonTrivial>>::value));
Minor style changes in UnitTestVariant
2021-04-01 20:47:51 +00:00
#endif // VTKM_USE_STD_IS_TRIVIAL
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
struct TestFunctor
{
template <vtkm::IdComponent Index>
vtkm::FloatDefault operator()(TypePlaceholder<Index>, vtkm::Id expectedValue)
{
VTKM_TEST_ASSERT(Index == expectedValue, "Index = ", Index, ", expected = ", expectedValue);
return TestValue(expectedValue, vtkm::FloatDefault{});
}
};
Fix issue with Variant::CastAndCall with non-const reference There was a typo in the declaration of the `CastAndCall` for a non-const `Variant`. When determining the `noexcept` status of the function being called, it was passing in a const reference instead of a regular reference, which is what is actually passed to the function. This potentially causes the function call to not match and fail to compile.
2022-07-25 16:07:22 +00:00
struct TestFunctorModify
{
template <vtkm::IdComponent Index>
void operator()(TypePlaceholder<Index>& object, vtkm::Id expectedValue)
{
VTKM_TEST_ASSERT(Index == expectedValue, "Index = ", Index, ", expected = ", expectedValue);
VTKM_TEST_ASSERT(object.Value == expectedValue);
++object.Value;
}
};
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
void TestGet()
{
std::cout << "Test Get" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<TypePlaceholder<0>,
TypePlaceholder<1>,
vtkm::Id,
TypePlaceholder<3>,
TypePlaceholder<4>,
TypePlaceholder<5>,
TypePlaceholder<6>,
TypePlaceholder<7>,
TypePlaceholder<8>,
TypePlaceholder<9>,
TypePlaceholder<10>,
TypePlaceholder<11>,
TypePlaceholder<12>,
TypePlaceholder<13>,
TypePlaceholder<14>,
TypePlaceholder<15>,
TypePlaceholder<16>,
TypePlaceholder<17>,
TypePlaceholder<18>,
TypePlaceholder<19>,
TypePlaceholder<20>,
TypePlaceholder<21>,
TypePlaceholder<22>,
TypePlaceholder<23>,
TypePlaceholder<24>,
TypePlaceholder<25>,
TypePlaceholder<26>,
vtkm::Float32,
TypePlaceholder<28>,
TypePlaceholder<29>>;
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
{
const vtkm::Id expectedValue = TestValue(3, vtkm::Id{});
VariantType variant = expectedValue;
VTKM_TEST_ASSERT(variant.GetIndex() == 2);
Add Variant::IsType The `Variant` class was missing a way to check the type. You could do it indirectly using `variant.GetIndex() == variant.GetIndexOf<T>()`, but having this convenience function is more clear.
2022-08-05 18:35:57 +00:00
VTKM_TEST_ASSERT(variant.IsType<vtkm::Id>());
VTKM_TEST_ASSERT(!variant.IsType<vtkm::Float32>());
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
VTKM_TEST_ASSERT(variant.Get<2>() == expectedValue);
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
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
VTKM_TEST_ASSERT(variant.Get<vtkm::Id>() == expectedValue);
Handle `Variant::Get` for types not supported by the `Variant` Previously, if you called `Get` on a `Variant` with a type that is not in the list of types supported by the `Variant`, that would attempt to look up the type at index `-1` and could spin the compiler into an endless loop. Instead, check for the case where you are attempting to get a type from the `Variant` not listed in its templat arguments. In this case, instead of producing a compiler error, produce a runtime error. Although this increases the possibility that a bad compile path is being generated, it simplifies creating templated code that produces cases we don't care about.
2021-10-04 16:19:25 +00:00
// This line should compile, but will assert if you actually try to run it.
//variant.Get<TypePlaceholder<100>>();
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
}
{
const vtkm::Float32 expectedValue = TestValue(4, vtkm::Float32{});
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
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
VariantType variant = expectedValue;
VTKM_TEST_ASSERT(variant.GetIndex() == 27);
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
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
VTKM_TEST_ASSERT(variant.Get<27>() == expectedValue);
VTKM_TEST_ASSERT(variant.Get<vtkm::Float32>() == expectedValue);
}
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
}
void TestCastAndCall()
{
std::cout << "Test CastAndCall" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<TypePlaceholder<0>,
TypePlaceholder<1>,
TypePlaceholder<2>,
TypePlaceholder<3>,
TypePlaceholder<4>,
TypePlaceholder<5>,
TypePlaceholder<6>,
TypePlaceholder<7>,
TypePlaceholder<8>,
TypePlaceholder<9>,
TypePlaceholder<10>,
TypePlaceholder<11>,
TypePlaceholder<12>,
TypePlaceholder<13>,
TypePlaceholder<14>,
TypePlaceholder<15>,
TypePlaceholder<16>,
TypePlaceholder<17>,
TypePlaceholder<18>,
TypePlaceholder<19>,
TypePlaceholder<20>,
TypePlaceholder<21>,
TypePlaceholder<22>,
TypePlaceholder<23>,
TypePlaceholder<24>,
TypePlaceholder<25>,
TypePlaceholder<26>,
TypePlaceholder<27>,
TypePlaceholder<28>,
TypePlaceholder<29>>;
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::FloatDefault result;
VariantType variant0{ TypePlaceholder<0>{} };
result = variant0.CastAndCall(TestFunctor(), 0);
VTKM_TEST_ASSERT(test_equal(result, TestValue(0, vtkm::FloatDefault{})));
VariantType variant1{ TypePlaceholder<1>{} };
result = variant1.CastAndCall(TestFunctor(), 1);
VTKM_TEST_ASSERT(test_equal(result, TestValue(1, vtkm::FloatDefault{})));
const VariantType variant2{ TypePlaceholder<2>{} };
result = variant2.CastAndCall(TestFunctor(), 2);
VTKM_TEST_ASSERT(test_equal(result, TestValue(2, vtkm::FloatDefault{})));
VariantType variant3{ TypePlaceholder<3>{} };
result = variant3.CastAndCall(TestFunctor(), 3);
VTKM_TEST_ASSERT(test_equal(result, TestValue(3, vtkm::FloatDefault{})));
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
VariantType variant26{ TypePlaceholder<26>{} };
result = variant26.CastAndCall(TestFunctor(), 26);
VTKM_TEST_ASSERT(test_equal(result, TestValue(26, vtkm::FloatDefault{})));
Fix issue with Variant::CastAndCall with non-const reference There was a typo in the declaration of the `CastAndCall` for a non-const `Variant`. When determining the `noexcept` status of the function being called, it was passing in a const reference instead of a regular reference, which is what is actually passed to the function. This potentially causes the function call to not match and fail to compile.
2022-07-25 16:07:22 +00:00
variant1.CastAndCall(TestFunctorModify{}, 1);
VTKM_TEST_ASSERT(variant1.Get<1>().Value == 2, "Variant object not updated.");
Fix Variant::CastAndCall SFINAE for auto return type functors `Variant::CastAndCall` was using the C++11 style for an `auto` return where the return type was specified with a `->` that got the `decltype` of the return value of the functor. This was used as part of SFINAE to pick whether you needed the const or non-const version. However, this was causing a problem with functions that got an error when deducing the return type for that. This was particularly problematic for lambda functions. For example, say you have the following simple `CastAndCall`. ```cpp variant.CastAndCall([](auto& x){ ++x; }); ``` To determine the return type of the lambda (`void`), the function has to be compiled. But when it is compiled with a const type, which happens when deducing the const version of `CastAndCall`, you get a compile error. This error is not considered a substitution error (hence SFINAE), it is an outright error. So you get a compile error just trying to deduce the type. The solution was to move to the C++14 version of an auto return type. In this case, the return type is no longer important for SFINAE and is delayed until the function is actually compiled with the specific template parameters. This would be a problem if the const version of `CastAndCall` was used when the non-const version was needed. But now both versions will pass SFINAE and thus the non-const version will be chosen as long as the `Variant` object itself is non-const. If the `Variant` object itself is const, then that is in fact a legitimate error, so a compile error is OK. One thing I find wierd is that `CastAndCall` still has a `noexcept` expression that will likewise cause a compile error in this case. However, it is still working. I _think_ the difference is that `noexcept` is not used to determine template substitution/overloaded, so is therefore ignored until the function is actually compiled.
2022-07-29 12:50:34 +00:00
variant1.CastAndCall([](auto& object) { ++object.Value; });
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
}
Enable copying invalid variants There was a bug where if you attempted to copy a variant that was not valid (i.e. did not hold an object), a seg fault could happen. This has been changed to set the target variant to also be invalid.
2022-06-29 18:34:02 +00:00
void TestCopyInvalid()
{
std::cout << "Test copy invalid variant" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<TypePlaceholder<0>, NonTrivial>;
Enable copying invalid variants There was a bug where if you attempted to copy a variant that was not valid (i.e. did not hold an object), a seg fault could happen. This has been changed to set the target variant to also be invalid.
2022-06-29 18:34:02 +00:00
VariantType source;
source.Reset();
VariantType destination1(source);
VTKM_TEST_ASSERT(!destination1.IsValid());
VariantType destination2(TypePlaceholder<0>{});
destination2 = source;
VTKM_TEST_ASSERT(!destination2.IsValid());
}
Try to fix uninitialized anonymous variable warning The code from the previous commit was causing one of the dashboards, which is using gcc-7, to produce the following warning: In file included from ../testing/UnitTestVariant.cxx:11:0: ../Variant.h: In function 'void {anonymous}::TestCopyDestroy()': ../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized] this->Storage = std::move(rhs.Storage); ^~~~ At best, this warning is not helpful as it does not seem to point to anything that could be used uninitialized. At worst, it might be a compiler bug. A Google search finds a few similar bugs although none I can assert with any confidence of this issue. However, many reported bugs and issues point to the use of anonymous namespaces. So, I'm going to attempt to fix the problem by removing anonymous namespaces. Hopefully it will fix the warning or at least point me to something concrete that I can fix.
2019-10-27 13:33:45 +00:00
struct CountConstructDestruct
{
vtkm::Id* Count;
CountConstructDestruct(vtkm::Id* count)
: Count(count)
{
++(*this->Count);
}
CountConstructDestruct(const CountConstructDestruct& src)
: Count(src.Count)
{
++(*this->Count);
}
~CountConstructDestruct() { --(*this->Count); }
Use a union in Variant for safe type punning Create a `VaraintUnion` that is an actual C++ `union` to store the data in a `Variant`. You may be asking yourself, why not just use an `std::aligned_union` rather than a real union type? That was our first implementation, but the problem is that the `std::aligned_union` reference needs to be recast to the actual type. Typically you would do that with `reinterpret_cast`. However, doing that leads to undefined behavior. The C++ compiler assumes that 2 pointers of different types point to different memory (even if it is clear that they are set to the same address). That means optimizers can remove code because it "knows" that data in one type cannot affect data in another type. To safely change the type of an `std::aligned_union`, you really have to do an `std::memcpy`. This is problematic for types that cannot be trivially copied. Another problem is that we found that device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
2021-03-17 20:38:33 +00:00
CountConstructDestruct& operator=(const CountConstructDestruct&) = delete;
Try to fix uninitialized anonymous variable warning The code from the previous commit was causing one of the dashboards, which is using gcc-7, to produce the following warning: In file included from ../testing/UnitTestVariant.cxx:11:0: ../Variant.h: In function 'void {anonymous}::TestCopyDestroy()': ../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized] this->Storage = std::move(rhs.Storage); ^~~~ At best, this warning is not helpful as it does not seem to point to anything that could be used uninitialized. At worst, it might be a compiler bug. A Google search finds a few similar bugs although none I can assert with any confidence of this issue. However, many reported bugs and issues point to the use of anonymous namespaces. So, I'm going to attempt to fix the problem by removing anonymous namespaces. Hopefully it will fix the warning or at least point me to something concrete that I can fix.
2019-10-27 13:33:45 +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
void TestCopyDestroy()
{
std::cout << "Test copy destroy" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<TypePlaceholder<0>,
TypePlaceholder<1>,
CountConstructDestruct,
TypePlaceholder<3>,
TypePlaceholder<4>>;
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
#ifdef VTKM_USE_STD_IS_TRIVIAL
Minor style changes in UnitTestVariant
2021-04-01 20:47:51 +00:00
VTKM_STATIC_ASSERT(!vtkmstd::is_trivially_copyable<VariantType>::value);
#endif // VTKM_USE_STD_IS_TRIVIAL
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::Id count = 0;
VariantType variant1 = CountConstructDestruct(&count);
VTKM_TEST_ASSERT(count == 1, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 1);
{
VariantType variant2{ variant1 };
VTKM_TEST_ASSERT(count == 2, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 2);
VTKM_TEST_ASSERT(*variant2.Get<2>().Count == 2);
}
VTKM_TEST_ASSERT(count == 1, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 1);
{
VariantType variant3{ VariantType(CountConstructDestruct(&count)) };
VTKM_TEST_ASSERT(count == 2, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 2);
VTKM_TEST_ASSERT(*variant3.Get<2>().Count == 2);
}
VTKM_TEST_ASSERT(count == 1, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 1);
{
VariantType variant4{ variant1 };
VTKM_TEST_ASSERT(count == 2, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 2);
VTKM_TEST_ASSERT(*variant4.Get<2>().Count == 2);
variant4 = TypePlaceholder<0>{};
VTKM_TEST_ASSERT(count == 1, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 1);
variant4 = VariantType{ TypePlaceholder<1>{} };
VTKM_TEST_ASSERT(count == 1, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 1);
variant4 = variant1;
VTKM_TEST_ASSERT(count == 2, count);
VTKM_TEST_ASSERT(*variant1.Get<2>().Count == 2);
VTKM_TEST_ASSERT(*variant4.Get<2>().Count == 2);
}
}
void TestEmplace()
{
std::cout << "Test Emplace" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<vtkm::Id, vtkm::Id3, std::vector<vtkm::Id>>;
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
VariantType variant;
variant.Emplace<vtkm::Id>(TestValue(0, vtkm::Id{}));
VTKM_TEST_ASSERT(variant.GetIndex() == 0);
VTKM_TEST_ASSERT(variant.Get<vtkm::Id>() == TestValue(0, vtkm::Id{}));
variant.Emplace<1>(TestValue(1, vtkm::Id{}));
VTKM_TEST_ASSERT(variant.GetIndex() == 1);
VTKM_TEST_ASSERT(variant.Get<vtkm::Id3>() == vtkm::Id3{ TestValue(1, vtkm::Id{}) });
variant.Emplace<1>(TestValue(2, vtkm::Id{}), TestValue(3, vtkm::Id{}), TestValue(4, vtkm::Id{}));
VTKM_TEST_ASSERT(variant.GetIndex() == 1);
clang-format: reformat the repository with clang-format-9
2020-08-17 14:18:24 +00:00
VTKM_TEST_ASSERT(
variant.Get<vtkm::Id3>() ==
vtkm::Id3{ TestValue(2, vtkm::Id{}), TestValue(3, vtkm::Id{}), TestValue(4, vtkm::Id{}) });
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
variant.Emplace<2>(
{ TestValue(5, vtkm::Id{}), TestValue(6, vtkm::Id{}), TestValue(7, vtkm::Id{}) });
VTKM_TEST_ASSERT(variant.GetIndex() == 2);
VTKM_TEST_ASSERT(variant.Get<std::vector<vtkm::Id>>() ==
std::vector<vtkm::Id>{ TestValue(5, vtkm::Id{}),
TestValue(6, vtkm::Id{}),
TestValue(7, vtkm::Id{}) });
}
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
void TestConstructDestruct()
{
std::cout << "Make sure constructors and destructors are called correctly" << std::endl;
g_NonTrivialCount = 0;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<NonTrivial, TrivialCopy>;
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
{
VariantType variant1 = NonTrivial{};
VariantType variant2 = variant1;
variant2 = NonTrivial{};
NonTrivial nonTrivial;
VariantType variant3 = nonTrivial;
VariantType variant4;
variant4.Emplace<NonTrivial>();
VariantType variant5(VariantType(NonTrivial{}));
}
VTKM_TEST_ASSERT(g_NonTrivialCount == 0);
}
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
void TestCopySelf()
{
std::cout << "Make sure copying a Variant to itself works" << std::endl;
Expose the Variant helper class For several versions, VTK-m has had a `Variant` templated class. This acts like a templated union where the object will store one of a list of types specified as the template arguments. (There are actually 2 versions for the control and execution environments, respectively.) Because this is a complex class that required several iterations to work through performance and compiler issues, `Variant` was placed in the `internal` namespace to avoid complications with backward compatibility. However, the class has been stable for a while, so let us expose this helpful tool for wider use.
2022-11-01 13:52:41 +00:00
using VariantType = vtkm::exec::Variant<TypePlaceholder<0>, NonTrivial, TypePlaceholder<2>>;
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
VariantType variant{ NonTrivial{} };
VariantType& variantRef = variant;
variant = variantRef;
variant = variant.Get<NonTrivial>();
}
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
void RunTest()
{
TestSize();
TestIndexing();
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
TestTriviallyCopyable();
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
TestGet();
TestCastAndCall();
Enable copying invalid variants There was a bug where if you attempted to copy a variant that was not valid (i.e. did not hold an object), a seg fault could happen. This has been changed to set the target variant to also be invalid.
2022-06-29 18:34:02 +00:00
TestCopyInvalid();
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
TestCopyDestroy();
TestEmplace();
Do not attempt to move non-trivial objects in Variant The `Variant` class has separate implementations for its move and copy constructors/assignment operators depending on whether the classes it holds can be trivially moved. If the objects are trivial, Variant is trivial as well. However, in the case where the objects are not trivial, special construction and copying needs to be done. Previously, the non-trivial `Variant` defined a move constructor that did a byte copy of the contained object and reset the right hand side object so that it did not attempt to destroy the object. That usually works because it guarantees that only one version of the `Variant` will attempt to destroy the object and its resources should be cleaned up correctly. But C++ is a funny language that lets you do weird things. Turns out there are cases where moving the location of memory for an object without calling the proper copy method can invalidate the object. For example, if the object holds a pointer to one of its own members, that pointer will become invalid. Also, if it points to something that points back, then the object will need to update those pointers when it is moved. GCC's version of `std::string` seems to be a type like this. Solve the problem by simply deleting the move constructors. The copy constructors and destructor will be called instead to properly manage the object. A test for these conditions is added to `UnitTestVariant`.
2020-10-08 18:02:27 +00:00
TestConstructDestruct();
Support copying a Variant to itself
2021-03-24 20:41:31 +00:00
TestCopySelf();
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
}
Try to fix uninitialized anonymous variable warning The code from the previous commit was causing one of the dashboards, which is using gcc-7, to produce the following warning: In file included from ../testing/UnitTestVariant.cxx:11:0: ../Variant.h: In function 'void {anonymous}::TestCopyDestroy()': ../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized] this->Storage = std::move(rhs.Storage); ^~~~ At best, this warning is not helpful as it does not seem to point to anything that could be used uninitialized. At worst, it might be a compiler bug. A Google search finds a few similar bugs although none I can assert with any confidence of this issue. However, many reported bugs and issues point to the use of anonymous namespaces. So, I'm going to attempt to fix the problem by removing anonymous namespaces. Hopefully it will fix the warning or at least point me to something concrete that I can fix.
2019-10-27 13:33:45 +00:00
} // namespace test_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
int UnitTestVariant(int argc, char* argv[])
{
Try to fix uninitialized anonymous variable warning The code from the previous commit was causing one of the dashboards, which is using gcc-7, to produce the following warning: In file included from ../testing/UnitTestVariant.cxx:11:0: ../Variant.h: In function 'void {anonymous}::TestCopyDestroy()': ../Variant.h:269:5: warning: '<anonymous>' may be used uninitialized in this function [-Wmaybe-uninitialized] this->Storage = std::move(rhs.Storage); ^~~~ At best, this warning is not helpful as it does not seem to point to anything that could be used uninitialized. At worst, it might be a compiler bug. A Google search finds a few similar bugs although none I can assert with any confidence of this issue. However, many reported bugs and issues point to the use of anonymous namespaces. So, I'm going to attempt to fix the problem by removing anonymous namespaces. Hopefully it will fix the warning or at least point me to something concrete that I can fix.
2019-10-27 13:33:45 +00:00
return vtkm::testing::Testing::Run(test_variant::RunTest, argc, argv);
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
}
Reference in New Issue Copy Permalink