Let's start with a more generic question, what is a trait? What does the word trait mean?
According to the Cambridge Dictionary, a trait is "a particular characteristic that can produce a particular type of behaviour". Or simply "a characteristic, especially of a personality".
It's important to start our quest with the generic meaning, as many of us are native English speakers and having a clear understanding of the word trait helps us to have a better understanding also on the programming concept.
In C++, we can think about type traits as properties of a type. The <type_traits>
header was an addition introduced by C++11. Type traits can be used in template metaprogramming to inspect or even to modify the properties of a type.
As we saw in the C++ concepts series, you'd often need the information of what kind of types are accepted by a template, what types are supported by certain operations. While concepts are much superior in terms of expressiveness or usability, with type traits you could already introduce compile-time conditions on what should be accepted as valid code and what not.
Though type traits can help with even more. With their help, you can also add or remove the const
specifier, or you can turn a pointer or a reference into a value and so on.
As already mentioned, the library is used in the context of template metaprogramming, so everything happens at compile time.
Show me a type trait!
In the concepts series, I already mentioned std::is_integral
(in fact, I used std::is_integral_v
, more on that later.) Like other type traits, std::is_integral
is after all an integral_constant
that has a static value
member and some type information.
Let's see how std::is_integral
is implemented, by looking at the GCC implementation. While it might be different for other implementations, it should give you the basic idea.
template<typename _Tp>
struct is_integral
: public __is_integral_helper<typename remove_cv<_Tp>::type>::type
{ };
At first glance, we can see that it uses a certain __is_integral_helper
that is also a template and it takes the passed in type without its const
or volatile
qualifier if any.
Now let's have a look at __is_integral_helper
.
Due to the limitations of this blog post and also due to common sense I won't enumerate all the specialisations of the template _is_integral_helper
, I'll only show here three just to give you the idea.
template<typename>
struct __is_integral_helper
: public false_type { };
template<>
struct __is_integral_helper<bool>
: public true_type { };
template<>
struct __is_integral_helper<int>
: public true_type { };
As we can observe, the default implementation of __is_integral_helper
is a false_type
. Meaning that in case you call std::is_integral
with a random type, that type will be handed over to __is_integral_helper
and it will be a false type that has the value of false
, therefore the check fails.
For any type that should return true
for the is_integral
checks, __is_integral_helper
should be specialized and it should inherit from true_type
.
In order to close this circle, let's see how true_type
and false_type
are implemented.
/// The type used as a compile-time boolean with true value.
typedef integral_constant<bool, true> true_type;
/// The type used as a compile-time boolean with false value.
typedef integral_constant<bool, false> false_type;
As we can see, they are simple aliased integral_constants
.
As the last step, let's see how std::integral_constant
is built. (I omit the #if, etc. directives on purpose)
template<typename _Tp, _Tp __v>
struct integral_constant
{
static constexpr _Tp value = __v;
typedef _Tp value_type;
typedef integral_constant<_Tp, __v> type;
constexpr operator value_type() const noexcept { return value; }
constexpr value_type operator()() const noexcept { return value; }
};
So integral_constant
takes two template parameters. It takes a type _Tp
and a value __v
of the just previously introduced type _Tp
.
__v
will be accessible as the static value
member, while the type _Tp
itself can be referred to as the value_type
nested type. With the type
typedef you can access the type itself.
So true_type
is an integral_constant
where type
is bool
and value is true
.
In case you have std::is_integral<int>
- through multiple layers - it inherits from true_type
, std::is_integral<int>::value
is true
. For any type T
, std::is_integral<T>::type
is bool.
How to make your type satisfy a type trait
We've just seen how std::is_integral
is implemented. Capitalizing on that we might think that if you have a class MyInt
then having it an integral type only means that we simply have to write such code (I omit the problem of references and cv qualifications for the sake of simplicity):
template<>
struct std::is_integral<MyInt> : public std::integral_constant<bool, true> {};
This is exactly what I proposed in the ]Write your own concepts](https://www.sandordargo.com/blog/2021/03/10/write-your-own-cpp-concepts-part-i) article.
If you read attentively, probably you pointed out that I used the auxiliary "might" and it's not incidental.
I learned that having such a specialization results in undefined behaviour according to the standard [meta.type.synop (1)]:
"The behavior of a program that adds specializations for any of the templates defined in this subclause is undefined unless otherwise specified."
What is in that subsection? Go look for a draft standard (here is one) if you don't have access to a paid version. It's a very long list, and I tell you std::is_integral
is part of it. In fact, all the primary or composite type categories are in there.
Why?
As Howard Hinnant, the father of <chrono>
explained on StackOverflow "for any given type T, exactly one of the primary type categories has a value member that evaluates to true." If a type satisfies std::is_floating_point
then we can safely assume that std::is_class
will evaluate to false. As soon as we are allowed to add specializations, we cannot rely on this.
#include <type_traits>
class MyInt {};
template<>
struct std::is_integral<MyInt> : public std::integral_constant<bool, true> {};
int main() {
static_assert(std::is_integral<MyInt>::value, "MyInt is not integral types");
static_assert(std::is_class<MyInt>::value, "MyInt is not integral types");
}
In the above example, MyInt
breaks the explained assumption and this is in fact undefined behaviour, something you should not rely on.
And the above example shows us another reason, why such specializations cannot be considered a good practice. Developers cannot be trusted that much. We either made a mistake or simply lied by making MyInt
an integral type as it doesn't behave at all like an integral.
This basically means that you cannot make your type satisfy a type trait in most cases. (As mentioned the traits that are not allowed to be specialized are listed in the standard).
Conclusion
Today, we learned what type traits are, how they are implemented and we also saw that we cannot explicitly say about a user-defined type that it belongs to a primary or composite type category. Next week, we'll see how we can use type traits.
Connect deeper
If you liked this article, please
- hit on the like button,
- subscribe to my newsletter
- and let's connect on Twitter!
Top comments (1)
could you also please explain about is_polymorphic > pretty please.
i have looked into the header but i stopped at __is_polymorphic() . i was not able to go much further than that.