Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-09-16 17:22:55 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
80d2948300
vtk-m/vtkm/ListTag.h

235 lines
7.5 KiB
C
Raw Normal View History

Add tag-based type list templates Provies a list of types in a template like boost::mpl::vector and a method to call a functor on each type. However, rather than explicitly list each type, uses tags to identify the list. This provides the following main advantages: 1. Can use these type lists without creating horrendously long class names based on them, making compiler errors easier to read. For example, you would have a typename like MyClass<TypeListTagVectors> instead of MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic templates are not supported). This is the main motivation for this implementation. 2. Do not require variadic templates and usually few constructions. That should speed compile times. There is one main disadvantage to this approach: It is difficult to get a printed list of items in a list during an error. If necessary, it probably would not be too hard to make a template to convert a tag to a boost mpl vector.
2014-03-31 21:28:09 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
conslidate the license statement
2019-04-15 23:24:21 +00:00
//
Add tag-based type list templates Provies a list of types in a template like boost::mpl::vector and a method to call a functor on each type. However, rather than explicitly list each type, uses tags to identify the list. This provides the following main advantages: 1. Can use these type lists without creating horrendously long class names based on them, making compiler errors easier to read. For example, you would have a typename like MyClass<TypeListTagVectors> instead of MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic templates are not supported). This is the main motivation for this implementation. 2. Do not require variadic templates and usually few constructions. That should speed compile times. There is one main disadvantage to this approach: It is difficult to get a printed list of items in a list during an error. If necessary, it probably would not be too hard to make a template to convert a tag to a boost mpl vector.
2014-03-31 21:28:09 +00:00
// 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.
//============================================================================
#ifndef vtk_m_ListTag_h
#define vtk_m_ListTag_h
Add vtkm::List `vtkm::List` is meant to replace `vtkm::ListTag`. Rather than subclassing a base class with a variadic template, all lists expose the list of types. `vtkm::ListTag` was originally created before we required C++11 so supporting variadic templates was problematic. To hide the issue we had, we made list tags subclass other lists rather than be the list themselves. It makes for nicer types in the compiler, but hides important details about what is actually in the type. It also creates lots of unnecessary new types. The new `vtkm::List` is in some ways simpler. All lists have to be a `vtkm::List`. Subclasses are not supported (or rather, they will not work as expected). All manipulations (such as `vtkm::ListAppend`) resolve directly back to a `vtkm::List`. Although the types reported by the compiler will be longer, they will be more specific to the types being used. Also, the new implimentation should ultimately use fewer types.
2019-12-04 14:30:47 +00:00
#include <vtkm/List.h>
Allow longer base lists Previously we just hand coded base lists up to 4 entries, which was fine for what we were using it for. However, now that we want to support base types of different sizes, we are going to need much longer lists.
2014-10-08 18:53:01 +00:00
#include <vtkm/internal/ListTagDetail.h>
Declare new VTKM_STATIC_ASSERT This is to be used in place of BOOST_STATIC_ASSERT so that we can control its implementation. The implementation is designed to fix the issue where the latest XCode clang compiler gives a warning about a unused typedefs when the boost static assert is used within a function. (This warning also happens when using the C++11 static_assert keyword.) You can suppress this warning with _Pragma commands, but _Pragma commands inside a block is not supported in GCC. The implementation of VTKM_STATIC_ASSERT handles all current cases.
2015-09-17 19:45:35 +00:00
#include <vtkm/StaticAssert.h>
Add tag-based type list templates Provies a list of types in a template like boost::mpl::vector and a method to call a functor on each type. However, rather than explicitly list each type, uses tags to identify the list. This provides the following main advantages: 1. Can use these type lists without creating horrendously long class names based on them, making compiler errors easier to read. For example, you would have a typename like MyClass<TypeListTagVectors> instead of MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic templates are not supported). This is the main motivation for this implementation. 2. Do not require variadic templates and usually few constructions. That should speed compile times. There is one main disadvantage to this approach: It is difficult to get a printed list of items in a list during an error. If necessary, it probably would not be too hard to make a template to convert a tag to a boost mpl vector.
2014-03-31 21:28:09 +00:00
#include <vtkm/internal/ExportMacros.h>
Switch over to c++11 type_traits.
2016-08-29 15:13:00 +00:00
#include <type_traits>
Add VTKM_IS_LIST_TAG macro As part of this is a ListTagCheck class that can be used for other template magic.
2014-10-22 13:24:04 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace vtkm
{
Add tag-based type list templates Provies a list of types in a template like boost::mpl::vector and a method to call a functor on each type. However, rather than explicitly list each type, uses tags to identify the list. This provides the following main advantages: 1. Can use these type lists without creating horrendously long class names based on them, making compiler errors easier to read. For example, you would have a typename like MyClass<TypeListTagVectors> instead of MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic templates are not supported). This is the main motivation for this implementation. 2. Do not require variadic templates and usually few constructions. That should speed compile times. There is one main disadvantage to this approach: It is difficult to get a printed list of items in a list during an error. If necessary, it probably would not be too hard to make a template to convert a tag to a boost mpl vector.
2014-03-31 21:28:09 +00:00
Add vtkm::List `vtkm::List` is meant to replace `vtkm::ListTag`. Rather than subclassing a base class with a variadic template, all lists expose the list of types. `vtkm::ListTag` was originally created before we required C++11 so supporting variadic templates was problematic. To hide the issue we had, we made list tags subclass other lists rather than be the list themselves. It makes for nicer types in the compiler, but hides important details about what is actually in the type. It also creates lots of unnecessary new types. The new `vtkm::List` is in some ways simpler. All lists have to be a `vtkm::List`. Subclasses are not supported (or rather, they will not work as expected). All manipulations (such as `vtkm::ListAppend`) resolve directly back to a `vtkm::List`. Although the types reported by the compiler will be longer, they will be more specific to the types being used. Also, the new implimentation should ultimately use fewer types.
2019-12-04 14:30:47 +00:00
/// A special tag for a list that represents holding all potential values
///
/// Note: Can not be used with ForEach for obvious reasons.
struct ListTagUniversal : detail::ListRoot
{
using list = vtkm::detail::ListBase<vtkm::detail::UniversalTag>;
};
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace internal
{
Add VTKM_IS_LIST_TAG macro As part of this is a ListTagCheck class that can be used for other template magic.
2014-10-22 13:24:04 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ListTag>
struct ListTagCheck : std::is_base_of<vtkm::detail::ListRoot, ListTag>
Add VTKM_IS_LIST_TAG macro As part of this is a ListTagCheck class that can be used for other template magic.
2014-10-22 13:24:04 +00:00
{
Remove VS2013 workarounds from VTK-m.
2018-02-22 16:34:08 +00:00
static constexpr bool Valid = std::is_base_of<vtkm::detail::ListRoot, ListTag>::value;
Add VTKM_IS_LIST_TAG macro As part of this is a ListTagCheck class that can be used for other template magic.
2014-10-22 13:24:04 +00:00
};
} // namespace internal
/// Checks that the argument is a proper list tag. This is a handy concept
/// check for functions and classes to make sure that a template argument is
/// actually a device adapter tag. (You can get weird errors elsewhere in the
/// code when a mistake is made.)
///
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
#define VTKM_IS_LIST_TAG(tag) \
VTKM_STATIC_ASSERT_MSG((::vtkm::internal::ListTagCheck<tag>::value), \
"Provided type is not a valid VTK-m list tag.")
Add a template that tests whether a type is in a list. Also reduced the maximum list size to 15 (which is the current longest single list we have). Trying to reduce the size of the generated code a bit, which is getting a little long.
2014-10-22 16:35:56 +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
namespace internal
{
namespace detail
{
template <typename ListTag>
struct ListTagAsBrigandListImpl
{
VTKM_IS_LIST_TAG(ListTag);
using type = typename ListTag::list;
};
} // namespace detail
/// Converts a ListTag to a brigand::list.
///
template <typename ListTag>
using ListTagAsBrigandList = typename detail::ListTagAsBrigandListImpl<ListTag>::type;
Add vtkm::List `vtkm::List` is meant to replace `vtkm::ListTag`. Rather than subclassing a base class with a variadic template, all lists expose the list of types. `vtkm::ListTag` was originally created before we required C++11 so supporting variadic templates was problematic. To hide the issue we had, we made list tags subclass other lists rather than be the list themselves. It makes for nicer types in the compiler, but hides important details about what is actually in the type. It also creates lots of unnecessary new types. The new `vtkm::List` is in some ways simpler. All lists have to be a `vtkm::List`. Subclasses are not supported (or rather, they will not work as expected). All manipulations (such as `vtkm::ListAppend`) resolve directly back to a `vtkm::List`. Although the types reported by the compiler will be longer, they will be more specific to the types being used. Also, the new implimentation should ultimately use fewer types.
2019-12-04 14:30:47 +00:00
template <typename List>
using ListAsListTag = brigand::wrap<List, vtkm::ListTagBase>;
// This allows the new `List` operations work on `ListTag`s.
template <typename T>
struct AsListImpl
{
VTKM_STATIC_ASSERT_MSG(ListTagCheck<T>::value,
"Attempted to use something that is not a List with a List operation.");
using type = brigand::wrap<ListTagAsBrigandList<T>, vtkm::List>;
};
template <>
struct AsListImpl<vtkm::ListTagUniversal>
{
using type = vtkm::ListUniversal;
};
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
} // namespace internal
namespace detail
{
template <typename BrigandList, template <typename...> class Target>
struct ListTagApplyImpl;
template <typename... Ts, template <typename...> class Target>
struct ListTagApplyImpl<brigand::list<Ts...>, Target>
{
using type = Target<Ts...>;
};
} // namespace detail
/// \brief Applies the list of types to a template.
///
/// Given a ListTag and a templated class, returns the class instantiated with the types
/// represented by the ListTag.
///
template <typename ListTag, template <typename...> class Target>
using ListTagApply =
Update comparison for virtual and multiplexer arrays Previously the "dynamic" array was taken from a VariantArrayHandle. However, the VariantArrayHandle will actually cast to a basic array, so the comparison is not particularly fair. Change that to an ArrayHandleVirtual so that it is actually calling through a virtual method. Also make 2 versions of the multiplexer test. The first version has an array that is at the 1st index and the second is at the last index. This tests whether the compiled code has to do lots of actual comparisons to get to the last index.
2019-07-20 04:23:54 +00:00
typename detail::ListTagApplyImpl<internal::ListTagAsBrigandList<ListTag>, Target>::type;
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
Add classes to manage point coordinates. Each type of point coordinates has its own class with the name PointCoordinates*. Currently there is a PointCoordiantesArray that contains an ArrayHandle holding the point coordinates and a PointCoordinatesUniform that takes the standard extent, origin, and spacing for a uniform rectilinear grid and defines point coordiantes for that. Creating new PointCoordinates arrays is pretty easy, and we will almost definitely add more. For example, we should have an elevation version that takes uniform coordinates for a 2D grid and then an elevation in the third dimension. We can probably also use a basic composite point coordinates that can build them from other coordinates. There is also a DynamicPointCoordinates class that polymorphically stores an instance of a PointCoordinates class. It has a CastAndCall method that behaves like DynamicArrayHandle; it can call a functor with an array handle (possible implicit) that holds the point coordinates.
2014-05-14 21:05:38 +00:00
/// A special tag for an empty list.
///
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
struct ListTagEmpty : detail::ListRoot
{
Use c++11 variadic templates as storage of ListTags.
2016-03-03 20:58:09 +00:00
using list = vtkm::detail::ListBase<>;
Add tag-based type list templates Provies a list of types in a template like boost::mpl::vector and a method to call a functor on each type. However, rather than explicitly list each type, uses tags to identify the list. This provides the following main advantages: 1. Can use these type lists without creating horrendously long class names based on them, making compiler errors easier to read. For example, you would have a typename like MyClass<TypeListTagVectors> instead of MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic templates are not supported). This is the main motivation for this implementation. 2. Do not require variadic templates and usually few constructions. That should speed compile times. There is one main disadvantage to this approach: It is difficult to get a printed list of items in a list during an error. If necessary, it probably would not be too hard to make a template to convert a tag to a boost mpl vector.
2014-03-31 21:28:09 +00:00
};
/// A tag that is a construction of two other tags joined together. This struct
/// can be subclassed and still behave like a list tag.
Add ability to get an array from a Field for a particular type This is done through a new version of ApplyPolicy. This version takes a type of the array as its first template argument, which must be specified. This requires having a list of potential storage to try. It will use that to construct an ArrayHandleMultiplexer containing all potential types. This list of storages comes from the policy. A StorageList item was added to the policy. Types are automatically converted. So if you ask for a vtkm::Float64 and field contains a vtkm::Float32, it will the array wrapped in an ArrayHandleCast to give the expected type.
2019-09-05 16:41:52 +00:00
template <typename... ListTags>
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
struct ListTagJoin : detail::ListRoot
{
Add ability to get an array from a Field for a particular type This is done through a new version of ApplyPolicy. This version takes a type of the array as its first template argument, which must be specified. This requires having a list of potential storage to try. It will use that to construct an ArrayHandleMultiplexer containing all potential types. This list of storages comes from the policy. A StorageList item was added to the policy. Types are automatically converted. So if you ask for a vtkm::Float64 and field contains a vtkm::Float32, it will the array wrapped in an ArrayHandleCast to give the expected type.
2019-09-05 16:41:52 +00:00
using list = typename detail::ListJoin<internal::ListTagAsBrigandList<ListTags>...>::type;
Add tag-based type list templates Provies a list of types in a template like boost::mpl::vector and a method to call a functor on each type. However, rather than explicitly list each type, uses tags to identify the list. This provides the following main advantages: 1. Can use these type lists without creating horrendously long class names based on them, making compiler errors easier to read. For example, you would have a typename like MyClass<TypeListTagVectors> instead of MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic templates are not supported). This is the main motivation for this implementation. 2. Do not require variadic templates and usually few constructions. That should speed compile times. There is one main disadvantage to this approach: It is difficult to get a printed list of items in a list during an error. If necessary, it probably would not be too hard to make a template to convert a tag to a boost mpl vector.
2014-03-31 21:28:09 +00:00
};
Add ListTagAppend and ListTagAppendUnique
2018-06-21 17:35:57 +00:00
/// A tag that is constructed by appending \c Type to \c ListTag.
template <typename ListTag, typename Type>
struct ListTagAppend : detail::ListRoot
{
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
VTKM_IS_LIST_TAG(ListTag);
using list = typename detail::ListJoin<internal::ListTagAsBrigandList<ListTag>,
detail::ListBase<Type>>::type;
Add ListTagAppend and ListTagAppendUnique
2018-06-21 17:35:57 +00:00
};
/// Append \c Type to \c ListTag only if \c ListTag does not already contain \c Type.
Misc. typos Found via `codespell -q 3`
2018-08-07 21:50:41 +00:00
/// No checks are performed to see if \c ListTag itself has only unique elements.
Add ListTagAppend and ListTagAppendUnique
2018-06-21 17:35:57 +00:00
template <typename ListTag, typename Type>
struct ListTagAppendUnique : detail::ListRoot
{
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
VTKM_IS_LIST_TAG(ListTag);
using list =
typename detail::ListAppendUniqueImpl<internal::ListTagAsBrigandList<ListTag>, Type>::type;
Add ListTagAppend and ListTagAppendUnique
2018-06-21 17:35:57 +00:00
};
Refactor DynamicArrayHandle CastAndCall This is the first step in making a more efficient CastAndCall for DynamicArrayHandle.
2017-11-06 15:12:49 +00:00
/// A tag that consists of elements that are found in both tags. This struct
vtkm can now find the intersection of two ListTags. This is the first step in having filters which obey both the filters field policy and the users applied policy in field what fields they can run on.
2016-12-29 21:00:52 +00:00
/// can be subclassed and still behave like a list tag.
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ListTag1, typename ListTag2>
struct ListTagIntersect : detail::ListRoot
{
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
VTKM_IS_LIST_TAG(ListTag1);
VTKM_IS_LIST_TAG(ListTag2);
using list = typename detail::ListIntersect<internal::ListTagAsBrigandList<ListTag1>,
internal::ListTagAsBrigandList<ListTag2>>::type;
vtkm can now find the intersection of two ListTags. This is the first step in having filters which obey both the filters field policy and the users applied policy in field what fields they can run on.
2016-12-29 21:00:52 +00:00
};
Create ArrayHandleMultiplexer
2019-07-15 04:51:28 +00:00
/// A list tag that consists of each item in another list tag fed into a template that takes
/// a single parameter.
template <typename ListTag, template <typename> class Transform>
struct ListTagTransform : detail::ListRoot
{
VTKM_IS_LIST_TAG(ListTag);
using list = brigand::transform<internal::ListTagAsBrigandList<ListTag>,
brigand::bind<Transform, brigand::_1>>;
};
Add ListTagRemoveIf Provides the ability to remove items from a list.
2019-10-31 20:32:17 +00:00
/// A list tag that takes an existing ListTag and a predicate template that is applied to
/// each type in the ListTag. Any type in the ListTag that has a value element equal to true
/// (the equivalent of std::true_type), that item will be removed from the list. For example
/// the following type
///
/// ```cpp
/// vtkm::ListTagRemoveIf<vtkm::ListTagBase<int, float, long long, double>, std::is_integral>
/// ```
///
/// resolves to a ListTag that is equivalent to `vtkm::ListTag<float, double>` because
/// `std::is_integral<int>` and `std::is_integral<long long>` resolve to `std::true_type`
/// whereas `std::is_integral<float>` and `std::is_integral<double>` resolve to
/// `std::false_type`.
template <typename ListTag, template <typename> class Predicate>
struct ListTagRemoveIf : detail::ListRoot
{
VTKM_IS_LIST_TAG(ListTag);
using list = brigand::remove_if<internal::ListTagAsBrigandList<ListTag>,
brigand::bind<Predicate, brigand::_1>>;
};
Refactor DynamicArrayHandle CastAndCall This is the first step in making a more efficient CastAndCall for DynamicArrayHandle.
2017-11-06 15:12:49 +00:00
/// Generate a tag that is the cross product of two other tags. The resulting
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
/// tag has the form of Tag< brigand::list<A1,B1>, brigand::list<A1,B2> .... >
Refactor DynamicArrayHandle CastAndCall This is the first step in making a more efficient CastAndCall for DynamicArrayHandle.
2017-11-06 15:12:49 +00:00
///
template <typename ListTag1, typename ListTag2>
struct ListCrossProduct : detail::ListRoot
{
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
VTKM_IS_LIST_TAG(ListTag1);
VTKM_IS_LIST_TAG(ListTag2);
Refactor DynamicArrayHandle CastAndCall This is the first step in making a more efficient CastAndCall for DynamicArrayHandle.
2017-11-06 15:12:49 +00:00
using list =
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
typename detail::ListCrossProductImpl<internal::ListTagAsBrigandList<ListTag1>,
internal::ListTagAsBrigandList<ListTag2>>::type;
Refactor DynamicArrayHandle CastAndCall This is the first step in making a more efficient CastAndCall for DynamicArrayHandle.
2017-11-06 15:12:49 +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
/// \brief Checks to see if the given \c Type is in the list pointed to by \c ListTag.
///
Add a template that tests whether a type is in a list. Also reduced the maximum list size to 15 (which is the current longest single list we have). Trying to reduce the size of the generated code a bit, which is getting a little long.
2014-10-22 16:35:56 +00:00
/// There is a static boolean named \c value that is set to true if the type is
/// contained in the list and false otherwise.
///
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ListTag, typename Type>
Add a template that tests whether a type is in a list. Also reduced the maximum list size to 15 (which is the current longest single list we have). Trying to reduce the size of the generated code a bit, which is getting a little long.
2014-10-22 16:35:56 +00:00
struct ListContains
{
VTKM_IS_LIST_TAG(ListTag);
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
static constexpr bool value =
detail::ListContainsImpl<Type, internal::ListTagAsBrigandList<ListTag>>::value;
Add a template that tests whether a type is in a list. Also reduced the maximum list size to 15 (which is the current longest single list we have). Trying to reduce the size of the generated code a bit, which is getting a little long.
2014-10-22 16:35:56 +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
/// \brief Finds the type at the given index.
///
/// This struct contains subtype \c type that resolves to the type at the given index.
///
template <typename ListTag, vtkm::IdComponent Index>
struct ListTypeAt
{
VTKM_IS_LIST_TAG(ListTag);
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
using type = brigand::at<internal::ListTagAsBrigandList<ListTag>,
std::integral_constant<vtkm::IdComponent, 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
};
Add tag-based type list templates Provies a list of types in a template like boost::mpl::vector and a method to call a functor on each type. However, rather than explicitly list each type, uses tags to identify the list. This provides the following main advantages: 1. Can use these type lists without creating horrendously long class names based on them, making compiler errors easier to read. For example, you would have a typename like MyClass<TypeListTagVectors> instead of MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic templates are not supported). This is the main motivation for this implementation. 2. Do not require variadic templates and usually few constructions. That should speed compile times. There is one main disadvantage to this approach: It is difficult to get a printed list of items in a list during an error. If necessary, it probably would not be too hard to make a template to convert a tag to a boost mpl vector.
2014-03-31 21:28:09 +00:00
} // namespace vtkm
#endif //vtk_m_ListTag_h
Reference in New Issue Copy Permalink