跟我学C++中级篇—编译期检查-优快云博客

一、代码检查

在前面的文章中，已经对代码的管理从开始编写到最后提交甚至部署都有了较为详细的说明分析。特别对代码在编译期的检查进行过多个角度的分析说明。为了让大家对编译期检查有一个全面的理解，本文将对编译期时的检查进行一个综合的分析说明。

二、分析

正如人们理解疾病以预防为主一样，代码开发也要从最初级的源头来进行控制。代码的安全检查，虽然可以辅以人工和各种工具，但在编译期的检查仍然是最主要的一环。在编译期对代码进行控制，可以显示的处理下面的各类问题：

数据类型问题
这是编译器对代码检查的基础控制，C++是一种强类型的语言，如果数据本身都无法通过检查，其它也没有意义了。它包括类型大小、对齐、转换以及模板参数的属性等检查。另外，在继承中的多态类型处理检查也是重要的一种情况
语法问题
这也是基础的检查，对一些基础的语法的应用是否正确，是否缺少分号、括号是否匹配、关键字是否错误等等进行基础的检查。还包括对常量和边界的控制检查等等
逻辑问题
随着编译期功能的愈发强大，新的C++标准提供了各种编译器处理的逻辑方式如if constexpr等，包括早期的SFINAE技术等，编译期都需要对其进行检查
条件验证问题
这种就更多了，比如值的正确性检查、结果验证等等。常见的如static_assert以及原来一些各平台自带的类似的判断宏等
接口问题
接口问题之所以单独拿出来，主要原因在于接口更强调的是约束。所以语法的约束是一个强检查，当然也包括前面的语法和数据类型等检查。最典型的是C++20推出的Concepts检查
环境与依赖问题
这个就属于经典的编译期检查处理，当然也包括了链接时的检查。相当常见，如各种库的路径、版本以及机器位数等的显式的检查

编译期的检查作用非常大，它可以将问题及时暴露出来，防止把错误引入到运行时，造成严重的破坏。一般来说，编译期检查的作用主要有：

保证类型的安全性：这是强类型语言的基础要求
对语法规则的检查和相关约束机制的控制：比如基础的语法的逻辑判断、转换控制以及各种约束条件和分支管理等等
预防大于治疗：把错误尽量消灭在编译期，而不引入运行时导致各种异常甚至崩溃，降低调试和维护成本
无运行时成本：相关的错误检查都在编译期完成，不会造成运行时的效率的降低

三、编译期检查的分类

在编译期进行检查，一般可以分为以下几类：

预处理
这个是贯穿早期和现代C++编程的重要基础检查机制。主要针对头文件依赖、编译器特性及平台检测以及错误处理和辅助支持等。它的优点在于编译的早期检查和环境依赖处理；缺点是功能很基础，类型检测不太可靠且有可能穿越命名空间导致污染
静态处理
这里包括早期的通过宏和模板等实现的检查机制，也包括C++11标准后的静态断言static_assert()以及constexpr与consteval等新关键字处理。主要用于编译期验证条件和强制编译期运行。
它的优点在于计算前移提升了性能，但缺点是会要求常量表达式处理、降低了编译效率并可能占用更多的内存
类型萃取和元编程
这在模板编程和元编程中应用非常多，通过Type Traits进行类型推导和逻辑判断。它的优点在于非常灵活、功能强大而且C++标准和库都有相当完全的支持。缺点也非常明显，学习成本太高，另外也增加了编译的时间
SFINAE处理
SFINAE技术是模板元编程中的一个重要的技术点，通过和std::enable_if配合使用，可以实现模板的逻辑处理及相关错误处理。优点是灵活、可扩展；缺点是代码可维护性差、错误信息不容易理解，出现问题也难于调试
编译分支处理
这是C++17后引入的编译条件分支处理，它对未实例化分支不作检查。优点是代码可维护程度高、逻辑清晰。由于未实现分支不处理一定程度上减少了代码膨胀；缺点是标准要求必须在C++17以上，而且需要配合Type Traits一起使用。无法在函数外使用并要求条件必须是常量表达式
概念约束
Concepts其实主是一种精简版的SFINAE，加强了对模板使用的约束性检查。其优点在于语法简洁、错误明确、代码易维护。缺点是标准要求更高C++20以上，同时学习成本仍然存在

编译期检查其实可以理解为由开发者替机器来考虑如何对代码进行控制。所以就需要开发者对机器的运行有一定的了解，这样才能更好的对编译期进行的各种分支判断、逻辑处理和类型检查、转换等有较强的理解，从而开发中更高效、简单可维护的代码。

四、例子

其实编译期检查的相关的例程在前面写了很多，下面综合一下再给出一个，供参考：

//SFINAE例子--MUDUO中的例子
#include <iostream>
namespace detail
{
template<typename T>
struct has_no_destroy
{
  template <typename C> static char test(decltype(&C::no_destroy));
  template <typename C> static int32_t test(...);
  const static bool value = sizeof(test<T>(0)) == 1;
};
}  // namespace detail
template <typename T>
 static void init(T t)
  {
    T* value_ = new T();
    if (!detail::has_no_destroy<T>::value)
    {
            std::cout<<"is ok"<<t<<std::endl;
      //::atexit(destroy);
    }
  }

int main()
{
    int num = 200;
    init<int>(num);
    return 0;
}

//C++11后
template<typename T>
auto len (T const&& t) -> decltype((void)(t.size()) , T::size_type)//也可以使用std::enable_if，修改一下表达式即可
{
    return t.size();
}
//C++20
template<typename T>
concept func_ask = requires(T t)
{
    t.no_destroy();
};

通过对比很容易可以发现相关的技术演进导致的代码编写的安全性和可维护性的提高。其它如静态检查和萃取等在前面都有专门描述，不再一一的给出具体的例程，有兴趣可以搜索前面的相关文章即可。

五、总结

编译期检查是一种重要的代码安全机制。但正如反复说过的一句话”任何事物都具有两面性“。不能把所有的解决问题的思路都放到编译期，一是其能力无法满足检查只有在运行期才会出现的问题，另外一个就是过多的编译期检查，对于大的项目来说，编译期成本也是相当高的。所以，还是要根据实际情况来确定如何正确的使用编译期检查机制。推荐的原则是：高频的计算较少的使用编译期检查，而低频计算量较大的使用运行时检查。