<>我使用C ++并计划一个包含大约100个模板参数的类的库。当然,我担心有n个模板参数,如果用户需要每个组合,我们有2 ^ n个不同的类,这是一种代码爆炸。但是,用户需要为此进行2 ^ n个实例化。
我的问题是:有这么多模板参数的主要技术问题是什么?
注意:
代码示例:
// here we have 2, but I have 100 template parameters
template<typename T1, typename T2>
class Class
{
T1 x;
T2 y;
int add(T1 _x, T2 _y) { return _x+_y; } // 4 instanciations possible?
Class<T2, T1>* swap() { return new Class<T2, T1>(); } // always 2 instanciations?
};
答案 0 :(得分:4)
实际上,模板化的类类型是在编译时确定的。这并不意味着你有2 ^ n个不同的类,而是你只有n个类。在编译时,替换适当的类型,类成员/函数只是您使用它们的类型。
E.g。
template <class Type1, class Type2>
class A
{
private:
Type1 member_x;
public:
Type2 GetTypeValue(Type1, Type2);
};
当像这样实例化时:
A<int, string> *x = new A<int, string>();
仅作为具有整数类型成员和字符串类型成员的类进行编译。同样代表功能等。
<强>更新强>
通过下面的更新示例,您仍然只有一个函数实例,它将是一个string
返回函数,它使用参数int
和string
。
答案 1 :(得分:3)
主要考虑因素是代码大小,这会对性能产生影响。每个不同的模板实例化都需要生成所有使用的成员函数(或者如果用户进行手动模板实例化,则需要生成所有成员函数)。不同的模板实例之间不会有代码重用。
除此之外,您提供大量参数的任何元素都很难处理。从维护的角度来看,一个包含10个参数的声明已经很难阅读了。它将延伸多条线或者在线上延伸得非常宽,并且很难通过检查确定所有参数都在正确的位置。 X是第7或第8个参数吗?是的,你可以算一下,但它会变得很痛苦。如果参数的数量是100,那么问题就会加剧。
为什么你想要所有这些都是模板参数?如果没有更多信息,您将无法获得其他建议,但很可能其他设计针对同一问题不需要那么复杂的程度。也许参数不需要在编译时知道(它们可以以数组/向量的形式传递给非类型参数的函数/构造函数),或者它们可以被分组(一个类型模板参数包含一组相关的typedef) )...
答案 2 :(得分:1)
这样做是有原因的。自动代码生成器 序列化,解析,文档,Intellisense。所有标头都将能够被解析,然后自动编写为第二个类,该第二个类具有所解析类的每个成员函数的模板成员。由于自动代码系统可以编写代码,因此可读性并不重要,但是您可以访问任何类成员,而无需考虑分支代码的大小或间接性,这些分支代码基于每个模板成员是每个自动生成的基类的类型模板类。
然后,使用该类时,您可以具有通过查看类型为每种“类型”写出的函数,或者可以将每种模板类型的值显示为解析器或IDE显示的输出。粗略地讲,智能将被完全预编译以进行快速搜索。只需有一个并行项目,该项目根据头文件中的更改进行编译,然后无论其类型是什么类,它都可以查找各种特征。
从技术上讲,它从解析,记录,输出或显示类中的项的整个问题中消除了类型,并在查看某些文件的某些程序的编译时进行处理。因为每个成员都有一种查看类型的方式(类似于为什么使用static_cast而不是c样式转换时,编译器更喜欢它的原因)
代码大小将与每个类1-1解析的文件大小相同,优点是任何程序存储空间,都可以转换为与其匹配的自动写入类型,然后使用具有类型感知功能的函数进行访问以显示操纵或输出值。想象一下,如果仅在某个文件中找到一个“类”,使其能够访问该类中的所有信息而无需进行任何解析,而只需要将其转换为模板形式的预创建类,那么智能感知将非常方便,其中自动生成类的基类有一些方法可以处理现在可检测的类型上的数据。
大概他在用100个模板参数做些什么