C++模板参数推导 构造函数自动推导规则

C++17引入类模板参数推导（CTAD），允许编译器根据构造函数参数自动推导模板类型，如std::pair p(1, 2.0);可自动推导为std::pair，无需显式指定类型，简化了模板实例化过程。该特性适用于标准库容器（如vector、tuple）和自定义类模板，结合自定义推导指南可实现更灵活的类型推导，提升代码可读性与编写效率。

C++17之后，编译器能够根据你构造类模板对象时提供的参数，自动推导出模板的类型参数，省去了手动指定

<...>

解决方案

C++17引入了一个非常实用的特性，叫做类模板参数推导 (Class Template Argument Deduction, CTAD)。简单来说，就是当你创建一个类模板的实例时，如果你在构造函数中提供了足够的信息，编译器就能自己“猜”出模板参数的类型，而你就不必显式地写出来。

举个例子，以前我们要创建一个

std::pair

std::pair p(1, 2.0);

std::make_pair

auto p = std::make_pair(1, 2.0);

但在C++17之后，有了CTAD，你可以直接这样写：

std::pair p(1, 2.0);

1

int

2.0

double

p

std::pair

std::vector

std::vector v = {1, 2, 3};

std::tuple t(1, "hello", 3.14);

这种自动推导机制主要作用于类模板的构造函数调用，它让模板的使用体验一下子变得“平易近人”了许多。

构造函数自动推导解决了哪些实际问题？

说实话，在C++17之前，模板编程虽然强大，但有时也挺让人头疼的。最直接的痛点就是冗余的类型声明。比如，当你实例化一个像

std::map>

>

立即学习“C++免费学习笔记（深入）”；

在我看来，CTAD的出现，恰恰解决了这种“明明参数都摆在那了，为什么还要我重复一遍”的尴尬。它让模板类的实例化变得更像普通类的实例化，比如

MyClass obj(arg1, arg2);

CTAD的推导机制和常见使用场景

CTAD的推导机制，其实可以理解为编译器在幕后进行了一系列的“匹配”工作。当它看到你构造一个类模板对象但没有显式指定模板参数时，它会：

1. 查找所有可用的构造函数： 包括用户定义的构造函数、默认构造函数、拷贝/移动构造函数，以及聚合体初始化。
2. 尝试根据构造函数参数推导： 编译器会尝试用你传入的参数类型，去匹配这些构造函数的参数，并从中推导出模板参数。这个过程有点像函数模板参数推导，但作用于类模板。
3. 应用推导指南 (Deduction Guides)： 这是CTAD的一个核心部分。除了编译器自带的一些隐式推导规则（比如从构造函数参数推导），我们还可以为自己的类模板编写显式的“推导指南”。这些指南就像是给编译器提供额外的“说明书”，告诉它在特定情况下，应该如何推导模板参数。

常见使用场景：

• 标准库容器和工具类：

  std::vector v = {1, 2, 3};

  、

  std::pair p(1, 2.0);

  、

  std::tuple t(1, 'a', 3.14);

  、

  std::optional opt(42);

  、

  std::variant var(true);

  等等，这些都是CTAD的典型受益者。
• 自定义类模板： 只要你的类模板有构造函数，并且构造函数的参数能够明确地指示出模板参数的类型，CTAD就能派上用场。

不过，这里也有点小小的细节需要注意：如果推导过程存在歧义，或者没有明确的推导路径，编译器是会报错的。此外，对于聚合体（Aggregate）类型，CTAD也可以从初始化列表推导，这在某些情况下也非常方便。

自定义推导指南：让CTAD更智能

有时候，CTAD的默认行为可能不完全符合我们的预期，或者我们希望提供更灵活的构造方式。这时候，自定义推导指南 (Custom Deduction Guides) 就派上用场了。它们允许我们明确地告诉编译器，当遇到某种构造模式时，应该如何推导类模板的参数。这玩意儿有点意思，它不是构造函数，而是一种“推导规则”。

简单CMS

简单CMS购物分享平台是一套基于LAMP架构和ThinkPHP框架为基础的、免费的、开源系统，为广大站长建站提供简单创建一个属于自己的电子商务导购平台及图片信息分享平台。 简单CMS的主要特点： 1模板均来自目前最流行的平台。如：美丽说，蘑菇街，下一件等。 2数据可根据站长的需求进行自动有效推送。 3数据均为用户分享。 4广告精准定位。 5注重用户体验。 6运行高效。简单CMS(jdcms)发布

下载

语法结构：

template ClassName(ConstructorArgs...) -> ClassName;

举个例子，假设我们有一个简单的

Wrapper

template
struct Wrapper {
    T data;
    // 构造函数：接受一个T类型的值
    Wrapper(T d) : data(d) {}
};

如果我们这样使用：

Wrapper w(123);

Wrapper

const char*

Wrapper

Wrapper

const char*

std::string

这时候，我们可以添加一个自定义推导指南：

// 告诉编译器：如果Wrapper的构造函数接收一个const char*，
// 那么请把模板参数T推导成std::string
Wrapper(const char*) -> Wrapper;

现在，当我们这样使用时：

Wrapper w_int(123);      // 推导为 Wrapper
Wrapper w_string("hello world"); // 推导为 Wrapper

是不是感觉一下子灵活了很多？

再来一个更复杂的例子，比如你有一个容器类，它可以通过两个迭代器来构造：

#include 
#include 
#include  // For std::iterator_traits

template
struct MyVector {
    std::vector vec;
    template
    MyVector(Iter begin, Iter end) : vec(begin, end) {}
};

// 推导指南：如果MyVector的构造函数接收两个迭代器，
// 那么模板参数T应该推导为迭代器指向的值类型
template
MyVector(Iter, Iter) -> MyVector::value_type>;

// 使用：
std::vector source_int = {1, 2, 3};
MyVector mv_int(source_int.begin(), source_int.end()); // 推导为 MyVector

std::vector source_str = {"a", "b"};
MyVector mv_str(source_str.begin(), source_str.end()); // 推导为 MyVector

编写自定义推导指南时，需要注意保持其清晰性和目的性，避免编写过于宽泛的指南，这可能会导致推导歧义。它们是给编译器提供额外的“线索”，而不是替代构造函数本身。理解它们与构造函数的协同工作方式，能让你在设计更灵活、更易用的模板类时如虎添翼。