{"id":402119,"date":"2024-06-29T16:18:05","date_gmt":"2024-06-29T16:18:05","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=402119"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-06-29T16:18:05","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=402119","title":{"rendered":"An article for those who, like me, do not understand the purpose of std::common_type<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

This article investigates why the standard library needs a way to deduce a common type, how it is implemented and how it works.<\/p>\n

<\/p>\n

\"common_type\/image1.png\"<\/p>\n

<\/a> <\/p>\n

To begin with, I’d like to thank my teammate khandeliants<\/a>. He helped me figure out some things in the C++ standard that I found ambiguous. He also helped me refine my code examples.<\/p>\n

<\/p>\n

Ways std::common_type was useful for us<\/h2>\n

<\/p>\n

It all started when the PVS-Studio team set out to sift through and majorly enhance the C++ analyzer’s core. Currently, one of the big tasks is to implement a new type system. Right now, our type system consists of strings encoded in a specific way. We want to replace this system with a hierarchical one. I won’t go into too much detail about the new type system. Loosely put, we are trying to turn this:<\/p>\n

<\/p>\n

\"common_type\/image2.png\"<\/p>\n

<\/p>\n

into this:<\/p>\n

<\/p>\n

\"common_type\/image3.png\"<\/p>\n

<\/p>\n

If you want to know more about it, check out the talk<\/a> my teammate Yuri gave at the itCppCon21<\/a> conference. There he discussed our old and new type systems in great detail \u2014 and showed funny pictures. By now, I think, he’s assembled enough material for two or three new talks. So, we can all start looking forward to them \ud83d\ude42<\/p>\n

<\/p>\n

The new type system uses analogs of type_traits<\/a><\/em>. These custom traits, same as their predecessors, help modify types and get the necessary information on types.<\/p>\n

<\/p>\n

Just recently I wrote an std::common_type<\/a><\/em> implementation for our type system. The original std::common_type trait is often used in metaprogramming to process an arbitrary number of types passed \u2014 and deduce a common type for them. We found our custom trait helpful when we needed to deduce a resulting type \u2014 for example, when we come across an arithmetic operation in a binary expression:<\/p>\n

<\/p>\n

if (operationInfo->m_type == OperatorType::Arithmetic) {   auto leftType  = TypeTraits::ExtractMemberType                    (result->GetLeftOperand().GetType());   auto rightType = TypeTraits::ExtractMemberType                    (result->GetRightOperand().GetType());   auto resType = Types::Traits::CommonType(leftType, rightType);   .... }<\/code><\/pre>\n
  <\/p>\n
Before, this operation required much more code. Now the code looks elegant.<\/p>\n
  <\/p>\n
Why C++ developers need std::common_type at all<\/h2>\n
  <\/p>\n
Suppose we want to write a naive implementation of a function template in order to calculate two vectors’ dot product. These vectors can be instantiated with various types passed to them. The dot product type must be deduced automatically. In C++14 and later, one of the ways to implement such a function template is as follows:<\/p>\n
  <\/p>\n
#include <vector>  template <typename T, typename U> auto dot_product(const std::vector<T> &a, const std::vector<U> &b) {   \/\/ some bounds checks    ??? result {};    auto a_it = a.begin();   auto b_it = b.begin();    while (a_it != a.end())   {     result += static_cast<???>(*a_it++) * static_cast<???>(*b_it++);   }    return result; }<\/code><\/pre>\n
  <\/p>\n
The scenario assumes that the function receives vectors of the same size. Otherwise, calculating the dot product is impossible and will produce an array out-of-bounds error.<\/p>\n
  <\/p>\n
So, the function does exactly what we intended it to do. The compiler deduces for us the resulting type from the return statement<\/em>. Only one problem remains \u2014 we somehow need to deduce the common type for the result<\/em> variable.<\/p>\n
  <\/p>\n
However, before writing any code, let’s study one very interesting language construct \u2014 the ternary operator. Maybe it can help us with this task.<\/p>\n
  <\/p>\n
Conditional operator<\/h2>\n
  <\/p>\n
Since the standard describes the ternary operator in great detail<\/a>, covering the operator’s every aspect here seems excessive. So, I’ll focus on the most common cases that involve type deduction.<\/p>\n
  <\/p>\n
To help you understand the scenarios and results better, I’ll use the following to help me present them:<\/p>\n
  <\/p>\n