一、模板的显式实例化在前面的“模板的显式实例化”中对模板的显式实例化进行了总结性的分析说明。在模板的编程中为了能够实现模板的分离编译、实现模板精细化类型的实例控制并能够指定模板实例化的具体位置。模板的显式实例化可以提供这种方便快捷的实现方式。通过显式实例化可以有效的减少代码膨胀并进一步降低编译的时间。这也是显式实例化的一个重要的优点。当然其它的优点比如支持外部模板等都可以在需要的时候加以应用。特别是随着标准的演进会不会有新的技术点出现这都有可能。不过显式实例化也存在着不少的问题。不能动不动就拿起显式实例化的大棒也就是人们常说的“拿着锤子找钉子”。二、常见的问题在看到显式实例化可能就会想到是不是这种方法是普适的没有限制的。怎么可能正如武器一样每种武器都会有自己的适应场景。拿着长矛打坦克那肯定不行。而且模板在C中是一门重的技术它在不断的发展也会引入不少的新的应用领域同样也可能导致兼容性的问题。一般来说在模板的显式实例化中有以下几个问题需要注意特定模板参数模板函数中如果模板的参数是函数类型当处理的模板参数实参为Lambda表达式或auto类型时。在这种情况下其实参声明一般都是不固定的随时可能生成的所以其类型无法提前预测也就无法提前显式实例化或者在模板参数为万能引用或完美转发时一般都要谨慎处理使用显式实例化。这种情况也和第一点有些类似参数的类型需要依赖推导来确定无法提前进行确定。通过分析也可以发现灵活的处理的对象传参的模板函数一般不推荐使用显式实例化变参模板变参模板之所以不推荐使用显式实例化并不说显式实例化不可以而是变参太复杂了实例化其中的个别部分没有实际意义。新技术新标准中在C20后的概念当然也包括类似的SFINAE应用中显式实例化往往与实际的需求可能冲突。本身概念就一种约束模板类型的存在实例化一种约束的行为对象对实际应用来没有任何的意义。三、分析和说明模板的显式实例化并不会阻止默认的隐式实例化。也就是说如果模板的显式实例化后又对其进行了实例化编译器还是会生成相关的代码。至于后期的去重那是另外一回事。模板的显式实例化其实就是对非确定应用中的确定部分进行处理。所以它更适合于类型固定、应用固定以及不太复杂的场景下进行应用。当然为实现某些特定功能比如隐藏头文件中具体功能的实现、控制编译粒度的影响等就是另外一种情况了。如果在某些特定的场景下还一定要使用显式实例化时就需要引入更高层次的抽象也就是封装一层。比如前面提到的Lambda表达式就可以用std::function封装一下。auto可以使用std::any等进行封装一下。当然也可以在设计进行处理比如使用前面提到的CRTP等方式将模板的实现进行隐藏。当然最简单的方法是在设计上隔离模板与应用开法相应的抽象接口层不再使用模板对外提供接口。不过这又引入了另外一个问题即接口的相关设计问题这也算是创建一个新问题来掩盖老的问题。四、总结显式实例化在模板中应用还是很广泛的但实际上写模板的人就比较少。所以在实际的开发中也不必太纠结遇到问题再解决问题也不晚。不过对于广大的开发者来说很少接触到底层框架的开发大多也是在应用层进行开发。这种技术应用的范围应该不多。