Define METHOD_TRAIT¶
Defined in File TypeTraits.hpp
Define Documentation¶
-
METHOD_TRAIT
(trait_name, method_name)¶ These helpers allow writing checks.
The missing piece is something that you can put into these. This is the point where this turns into type checking.
Op
from above can be anything. For instance, we can write an expression, and have the compiler try to calculate that expression’s resulting type, like so:decltype(std::declval<T>().member_a)
std::declval<T>()
constructs a pseudo-value of typeT
which works even ifT
is not actually constructible like this. Then we access a member calledmember_a
inside and instruct the compiler to calculate the resulting type usingdecltype
. This will only work if the expression is valid. If not, this would normally cause a compilation error. If we wrap it into the detection idiom, however, we can turn that compilation error into a simple constexpr false!To do that, we need to put that expression above into a metafunction. If we simply wrote
whereis_detected<decltype(std::declval<T>().member_a)>
decltype(std::declval<T>().member_a)
isOp
, andArgs
is empty, we still get a compilation error. This is because the compiler evaluates the first argument before even passing it intois_detected
, and that means outside the overload resolution context. This is why we need to pass a metafunction around the expression asOp
, and the concrete typeT
asArgs
so that the actual evaluation of the expression happens inside the overload resolution context. Luckily, writing a metafunction around the expression is as easy asand we can then use it liketemplate <typename T> using member_a_t = decltype(std::declval<T>().member_a>);
is_detected<member_a_t, T>
.Basically, what you have to do to write type assertions using this pattern is metafunctions like the one described above. Those can be member checks, like shown before, nested type checks like
and checks for contained templates liketemplate <typename T> using nested_a_t = typename T::NestedA;
but also arbitrary expressions, like operators, or even operators between types. For instance, say we have two typestemplate <typename T> using meta_t = typename T::template meta<void, void>;
U
andV
. We can then write a metafunction that attempts to instantiate a binary operation between the two:and simply takes bothtemplate <typename U, typename V> using binary_op_t = decltype(std::declval<U>() + std::declval<V>());
U
andV
as meta-arguments. Invoked likeis_detected<binary_op_t, TypeA, TypeB>
on some typesTypeA
andTypeB
, this will tell you whether you can call that binary operation on values of those types.Implementing method checks is a little more involved. A simple method check can be written like
// foo_method_t is the name of the struct generated by this macro, // foo is the name of the method you want to check for. METHOD_TRAIT(foo_method_t, foo);template <typename T> using foo_method_t = decltype(std::declval<T>().foo(double, int)>); ```. This only checks if the given expression is valid. That means this will evaluate to true even if the actual arguments of that function are references, as the compiler will figure that out behind the scenes and still allow you to call it. That can be fine, if you're really only interested if that specific call is allowed. Remember that `decltype` calculates the type of the expression. In this context, it will evaluate to **the return type** of the called function. Using `identical_to` you can therefore assert the return type to be a given value. You might, however, want to constrain the *exact* types of the arguments, and the method's const qualifier. This is less straightforward. To achieve this, a macro is provided below, which will generate the required code for a trait predicate. You *cannot* use the result of this macro directly with the helpers defined above. What the macro provides is a metafunction, which still takes the type, the return type and the arguments as metaarguments. So the result of the macro only encodes the name of the method, not the rest of its signature. That means you can use the same method trait to check for any signature involving the same method name. Say you generated
has_method<T, R, foo_method_t, bool, const int&>An additional helper `has_method` is provided, which wraps a little boilerplate to check a specific signature. You can then write
R T::foo(bool, const int&)to check for a signature of the form
has_method<const T, R, foo_method_t, bool, const int&> ```. Note that both will only evaluate to true if the const qualifier matches what you gave exactly. If you want to check for a method of a given specifier and you don’t care if the method is const or not, you have to write out both variants explicitly, and combine them withIf you want to check for a const method you can modify this to
either
. This macro generates some boilerplate code that is necessary to correctly implement a method type trait that evaluates to constexpr bools correctly- Parameters
trait_name
: The resulting name of the trait.method_name
: The name of the method the trait shall check.