C++编译期类型检查：Can_copy模板编译期评估与函数指针作用问询

嘿，这个问题问到点子上了！这段代码是C++模板元编程早期用来做编译期约束的经典技巧，咱们一步步拆解它的工作原理：

先把代码摆出来方便对照：

template<class T1, class T2> 
struct Can_copy { 
    static void constraints(T1 a, T2 b) { 
        T2 c = a; 
        b = a; 
    } 
    Can_copy() { 
        void(*p)(T1, T2) = constraints; 
    } 
};

1. constraints静态函数：编译检查的“触发器” #

这个静态函数里的两行代码T2 c = a;和b = a;是整个约束的核心：

• T2 c = a;检查T1是否可以拷贝构造T2
• b = a;检查T1是否可以赋值给T2

编译器在实例化constraints函数时，会严格检查这两行代码的合法性。如果T1和T2不满足拷贝/赋值的要求（比如T2没有接受T1的拷贝构造函数，或者赋值运算符不匹配），编译器会直接抛出编译错误，这就实现了编译期的约束检查。

2. 函数指针赋值：强制编译器实例化constraints #

你可能会好奇：既然constraints里的代码已经能触发错误，为什么还要多此一举把它赋值给函数指针？

答案是：如果一个函数只被定义但从未被使用，编译器有权跳过它的实例化。如果不做这个赋值，编译器可能会把constraints当成“无用代码”忽略掉，那我们的编译检查就完全失效了。

而在构造函数里把constraints的地址赋值给函数指针p，相当于给编译器递了个话：“这个函数是有用的，你必须帮我把它实例化出来”。因为函数指针的签名和constraints完全匹配，编译器必须确保constraints能被正确实例化，这就强制触发了函数内部的编译检查。

3. 怎么实际用这个约束？ #

通常我们不会直接创建Can_copy的对象，而是通过实例化这个模板来触发检查，比如：

// 检查int能不能拷贝构造并赋值给std::string
typedef Can_copy<int, std::string> CopyCheck;
// 或者用sizeof触发实例化（不需要创建对象）
sizeof(Can_copy<int, std::string>);

只要编译器需要处理Can_copy<T1,T2>的实例化，就会触发构造函数的代码分析，进而触发constraints的实例化和检查。

题外话：现代C++的替代方案 #

这段代码是C++11之前的“复古技巧”，现在我们有更优雅的方式做编译期约束：

• C++11开始可以用std::is_copy_constructible、std::is_assignable结合static_assert直接检查
• C++20的**概念（Concepts）**可以更直观地定义和使用类型约束，比如std::copyable

但在没有这些现代特性的年代，这种“利用函数实例化触发编译检查”的技巧是模板元编程里的常用手段。

内容的提问来源于stack exchange，提问作者Eladian