C++如何在提供模板显式实例化的同时支持隐式实例化自定义类型

我有一个基本全为模板实现的项目，已知99%的用户仅需使用特定子集的模板实例，例如Camera类的以下实例：

Camera<float,Mono>
Camera<float,RGB>
Camera<double,Mono>
Camera<double,RGB>

但部分小众用户需要使用类似Camera<float, Spectrum<N>>的实例，其中N仅在用户特定程序中可知。

过去我会针对已知的实例子集使用显式实例化，这能大幅加快编译速度，并将实现与头文件分离（我偏好仅含声明的头文件以提升可读性）。但为了保留灵活性，目前项目采用仅头文件模板的形式。

请问是否可以为已知实例提供显式实例化以加快编译，同时仍允许用户按需进行隐式实例化？

我还考虑过另一种方案：完全采用显式实例化（将所有定义移至.cpp文件），并显式实例化：

Camera<float, Spectrum<SPECTRAL_BIN_COUNT>>

其中SPECTRAL_BIN_COUNT可通过#define设置（未设置时使用默认值）。但我担心该方案会限制未来的灵活性，希望模板实例化能完全灵活。

完全可以实现显式实例化与隐式实例化共存，核心是让头文件同时支持两种使用模式，以下是两种可行方案：

方案一：头文件拆分+条件暴露实现 #

1. 结构拆分：
   • 将Camera类的纯声明放在camera.h中，只保留接口，不含任何实现代码。
   • 把模板的所有成员函数定义放在camera_impl.h（头文件格式）中。
   • 在项目内部的camera.cpp中，包含camera_impl.h并显式实例化常用版本：

     #include "camera_impl.h"
     // 显式实例化高频使用的模板版本
     template class Camera<float, Mono>;
     template class Camera<float, RGB>;
     template class Camera<double, Mono>;
     template class Camera<double, RGB>;
     

2. 用户侧适配：
   • 普通用户只需包含camera.h，链接时会直接使用camera.cpp中预实例化的版本，编译速度快且头文件简洁。
   • 需要自定义实例的小众用户，在包含camera.h后额外引入camera_impl.h，编译器会自动根据用户代码隐式实例化所需的自定义版本（比如Camera<float, Spectrum<N>>）。

方案二：利用inline关键字简化实现 #

如果不想拆分多个头文件，可借助C++inline函数模板的特性：

• 在camera.h中，将模板成员函数的定义标记为inline，同时用extern template声明常用实例：

  // camera.h
  template <typename T, typename Format>
  class Camera {
      // 成员函数声明
      void capture();
  };
  
  // 成员函数实现并标记为inline
  template <typename T, typename Format>
  inline void Camera<T, Format>::capture() {
      // 具体实现代码
  }
  
  // 声明已预实例化的常用版本，引导编译器优先使用
  extern template class Camera<float, Mono>;
  extern template class Camera<float, RGB>;
  extern template class Camera<double, Mono>;
  extern template class Camera<double, RGB>;
  

• 在项目的camera.cpp中，显式实例化这些常用版本（去掉extern）：

  #include "camera.h"
  template class Camera<float, Mono>;
  template class Camera<float, RGB>;
  template class Camera<double, Mono>;
  template class Camera<double, RGB>;
  

这种模式下，普通用户使用时会优先链接预实例化版本；当用户需要自定义实例时，inline的定义允许编译器在需要时隐式实例化新模板，不会出现链接错误。

关于#define方案的弊端 #

你考虑的通过宏定义指定光谱箱数量的方案，确实会限制灵活性：用户无法同时使用多个不同N值的Spectrum实例，且修改N后需要重新编译整个项目，对需要多种光谱配置的用户不友好，不建议采用。

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