65,210
社区成员
发帖
与我相关
我的任务
分享用什么来替代模板？
我们的项目中，用到了模板类。在我看来，这些模板类的使用，的确提高了工作效率。没有什么问题。
可是，我的一个工作经验比较多的同事说，这些模板不应该用。
我不理解他的观点，你能给我讲讲，什么时候会放弃模板类？什么时候有更高的方法代替模板类？
谢谢。
可是，我的一个工作经验比较多的同事说，这些模板不应该用。
我不理解他的观点，你能给我讲讲，什么时候会放弃模板类？什么时候有更高的方法代替模板类？
谢谢。
...全文
请发表友善的回复…
发表回复
BluntBlade 2005-10-23
- 打赏
- 举报
在Template面前，我只有闭嘴的份儿。
pongba 2005-10-23
- 打赏
- 举报
代码膨胀不是指源代码，而是说生成的二进制代码的大小。
模板的主要问题并不在于代码膨胀，而是错误信息的可读性以及编译时间问题。前者对于使用过stl的人来说应当不陌生，后者对于使用过boost的人来说不陌生。
至于代码膨胀，呵呵，如果用得好反而能缩减代码体积。因为模板的理念包含一条：没用到的模板函数是不会编译为二进制代码的。
模板的代码膨胀主要来源于模板名字的长度而不是生成的二进制代码。你用16进制编辑器查看一下一个重度使用了boost库设施（像boost.lambda之类）的短小程序的目标代码，会发现里面大多数都是长得不得了的复杂的模板名字。这些符号(symbol)占用了.exe文件的大量空间。不过以后的编译器在这方面应当具有越来越强的优化能力，通过某些高级的压缩算法来缩减名字长度。;)
错误信息的可读性问题有望在C++0x中得到解决。方案是Bjarne Stroustrup提倡的一个称作concept的语言特性。参考C++ Standard Commitee Website上的相关proposal。
编译时间问题只有指望编译器厂商加把油了，呵呵;)
还有一个小问题就是目前的高级模板库的源代码仍然属于天书级的东西，非常难读，但读懂了则获益不小。
--
C++的罗浮宫
http://blog.csdn.net/pongba
模板的主要问题并不在于代码膨胀，而是错误信息的可读性以及编译时间问题。前者对于使用过stl的人来说应当不陌生，后者对于使用过boost的人来说不陌生。
至于代码膨胀，呵呵，如果用得好反而能缩减代码体积。因为模板的理念包含一条：没用到的模板函数是不会编译为二进制代码的。
模板的代码膨胀主要来源于模板名字的长度而不是生成的二进制代码。你用16进制编辑器查看一下一个重度使用了boost库设施（像boost.lambda之类）的短小程序的目标代码，会发现里面大多数都是长得不得了的复杂的模板名字。这些符号(symbol)占用了.exe文件的大量空间。不过以后的编译器在这方面应当具有越来越强的优化能力，通过某些高级的压缩算法来缩减名字长度。;)
错误信息的可读性问题有望在C++0x中得到解决。方案是Bjarne Stroustrup提倡的一个称作concept的语言特性。参考C++ Standard Commitee Website上的相关proposal。
编译时间问题只有指望编译器厂商加把油了，呵呵;)
还有一个小问题就是目前的高级模板库的源代码仍然属于天书级的东西，非常难读，但读懂了则获益不小。
--
C++的罗浮宫
http://blog.csdn.net/pongba
xlsue 2005-10-23
- 打赏
- 举报
回复人： pongba(刘未鹏《Imperfect C++》&&《Boost源码剖析》) ( ) 信誉：100 2005-10-23 00:34:00 得分: 0
代码膨胀不是指源代码，而是说生成的二进制代码的大小。
模板的主要问题并不在于代码膨胀，而是错误信息的可读性以及编译时间问题。前者对于使用过stl的人来说应当不陌生，后者对于使用过boost的人来说不陌生。
至于代码膨胀，呵呵，如果用得好反而能缩减代码体积。因为模板的理念包含一条：没用到的模板函数是不会编译为二进制代码的。
模板的代码膨胀主要来源于模板名字的长度而不是生成的二进制代码。你用16进制编辑器查看一下一个重度使用了boost库设施（像boost.lambda之类）的短小程序的目标代码，会发现里面大多数都是长得不得了的复杂的模板名字。这些符号(symbol)占用了.exe文件的大量空间。不过以后的编译器在这方面应当具有越来越强的优化能力，通过某些高级的压缩算法来缩减名字长度。;)
错误信息的可读性问题有望在C++0x中得到解决。方案是Bjarne Stroustrup提倡的一个称作concept的语言特性。参考C++ Standard Commitee Website上的相关proposal。
编译时间问题只有指望编译器厂商加把油了，呵呵;)
还有一个小问题就是目前的高级模板库的源代码仍然属于天书级的东西，非常难读，但读懂了则获益不小。
--
C++的罗浮宫
http://blog.csdn.net/pongba
-----------------------------------------------------------------------------
严重的苟同:)
代码膨胀不是指源代码，而是说生成的二进制代码的大小。
模板的主要问题并不在于代码膨胀，而是错误信息的可读性以及编译时间问题。前者对于使用过stl的人来说应当不陌生，后者对于使用过boost的人来说不陌生。
至于代码膨胀，呵呵，如果用得好反而能缩减代码体积。因为模板的理念包含一条：没用到的模板函数是不会编译为二进制代码的。
模板的代码膨胀主要来源于模板名字的长度而不是生成的二进制代码。你用16进制编辑器查看一下一个重度使用了boost库设施（像boost.lambda之类）的短小程序的目标代码，会发现里面大多数都是长得不得了的复杂的模板名字。这些符号(symbol)占用了.exe文件的大量空间。不过以后的编译器在这方面应当具有越来越强的优化能力，通过某些高级的压缩算法来缩减名字长度。;)
错误信息的可读性问题有望在C++0x中得到解决。方案是Bjarne Stroustrup提倡的一个称作concept的语言特性。参考C++ Standard Commitee Website上的相关proposal。
编译时间问题只有指望编译器厂商加把油了，呵呵;)
还有一个小问题就是目前的高级模板库的源代码仍然属于天书级的东西，非常难读，但读懂了则获益不小。
--
C++的罗浮宫
http://blog.csdn.net/pongba
-----------------------------------------------------------------------------
严重的苟同:)
xlsue 2005-10-22
- 打赏
- 举报
叫他不用标准库得了，它几乎是用模板写的。同意 wzjall() 已经复制上来的那个。。。
wzjall 2005-10-22
- 打赏
- 举报
条款41: 区分继承和模板
考虑下面两个设计问题：
· 作为一位立志献身计算机科学的学生，你想设计一个类来表示对象的堆栈。这将需要多个不同的类，因为每个堆栈中的元素必须是同类的，即，它里面包含的必须只是同种类型的对象。例如，会有一个类来表示int的堆栈，第二个类来表示string的堆栈，第三个类来表示string的堆栈的堆栈，等等。你也许对设计一个最小的类接口（参见条款18）很感兴趣，所以会将对堆栈的操作限制在：创建堆栈，销毁堆栈，将对象压入堆栈，将对象弹出堆栈，以及检查堆栈是否为空。设计中，你不会借助标准库中的类（包括stack ---- 参见条款49），因为你渴望亲手写这些代码。重用（Reuse）是一件美事，但当你的目标是探究事情的工作原理时，那就只有挖地三尺了。
· 作为一位爱猫的宠物迷，你想设计一个类来表示猫。这也将需要多个不同的类，因为每个品种的猫都会有点不同。和所有对象一样，猫可以被创建和销毁，但，正如所有猫迷所知道的，猫所做的其它事不外乎吃和睡。然而，每一种猫吃和睡都有各自惹人喜爱的方式。
这两个问题的说明听起来很相似，但却导致完全不同的两种设计。为什么？
答案涉及到"类的行为" 和 "类所操作的对象的类型"之间的关系。对于堆栈和猫来说，要处理的都是各种不同的类型（堆栈包含类型为T的对象，猫则为品种T），但你必须问自己这样一个问题：类型T影响类的行为吗？如果T不影响行为，你可以使用模板。如果T影响行为，你就需要虚函数，从而要使用继承。
下面的代码通过定义一个链表来实现Stack类，假设堆栈的对象类型为T：
class Stack {
public:
Stack();
~Stack();
void push(const T& object);
T pop();
bool empty() const; // 堆栈为空?
private:
struct StackNode { // 链表节点
T data; // 此节点数据
StackNode *next; // 链表中下一节点
// StackNode构造函数，初始化两个域
StackNode(const T& newData, StackNode *nextNode)
: data(newData), next(nextNode) {}
};
StackNode *top; // 堆栈顶部
Stack(const Stack& rhs); // 防止拷贝和
Stack& operator=(const Stack& rhs); // 赋值(见条款27)
};
于是，Stack对象将构造如下所示的数据结构：
Stack对象 top--> data+next--> data+next--> data+next--> data+next
------------------------------------------------------------------------------------
StackNode对象
链表本身是由StackNode对象构成的，但那只是Stack类的一个实现细节，所以StackNode被声明为Stack的私有类型。注意StackNode有一个构造函数，用来确保它所有的域都被正确初始化。即使你闭着眼睛都可以写出一个链表，但也不要忽视了C++的一些新特性，如struct中的构造函数。
下面看看你对Stack成员函数的实现。和许多原型（prototype）的实现（离制作成软件产品相差太远）一样，这里没有错误检查，因为在原型世界里，没有东西会出错。
Stack::Stack(): top(0) {} // 顶部初始化为null
void Stack::push(const T& object)
{
top = new StackNode(object, top); // 新节点放在
} // 链表头部
T Stack::pop()
{
StackNode *topOfStack = top; // 记住头节点
top = top->next;
T data = topOfStack->data; // 记住节点数据
delete topOfStack;
return data;
}
Stack::~Stack() // 删除堆栈中所有对象
{
while (top) {
StackNode *toDie = top; // 得到头节点指针
top = top->next; // 移向下一节点
delete toDie; // 删除前面的头节点
}
}
bool Stack::empty() const
{ return top == 0; }
这些代码毫无吸引人之处。实际上，唯一有趣的一点在于：即使对T一无所知，你还是能够写出每个成员函数。（上面的代码中实际上有个假设，即，假设可以调用T的拷贝构造函数；但正如条款45所说明的，这是一个绝对合理的假设）不管T是什么，对构造，销毁，压栈，出栈，确定栈是否为空等操作所写的代码不会变。除了 "可以调用T的拷贝构造函数" 这一假设外，stack的行为在任何地方都不依赖于T。这就是模板类的特点：行为不依赖于类型。
将stack类转化成一个模板就很简单了，即使是Dilbert的老板都会写：
template<class T> class Stack {
... // 完全和上面相同
};
但是，猫呢？为什么猫不适合模板？
重读上面的说明，注意这一条："每一种猫吃和睡都有各自惹人喜爱的方式"。这意味着必须为每种不同的猫实现不同的行为。不可能写一个函数来处理所有的猫，所能做的只能是制定一个函数接口，所有种类的猫都必须实现它。啊哈！衍生一个函数接口的方法只能是去声明一个纯虚函数（参见条款36）：
class Cat {
public:
virtual ~Cat(); // 参见条款14
virtual void eat() = 0; // 所有的猫吃食
virtual void sleep() = 0; // 所有的猫睡觉
};
Cat的子类 ---- 比如，Siamese和BritishShortHairedTabby ---- 当然得重新定义继承而来的eat和sleep函数接口：
class Siamese: public Cat {
public:
void eat();
void sleep();
...
};
class BritishShortHairedTabby: public Cat {
public:
void eat();
void sleep();
...
};
好了，现在知道了为什么模板适合Stack类而不适合Cat类，也知道了为什么继承适合Cat类。唯一剩下的问题是，为什么继承不适合Stack类。想知道为什么，不妨试着去声明一个Stack层次结构的根类 ---- 所有其它的堆栈类都从这个唯一的类继承：
class Stack { // a stack of anything
public:
virtual void push(const ??? object) = 0;
virtual ??? pop() = 0;
...
};
现在问题很明显了。该为纯虚函数push和pop声明什么类型呢？记住，每一个子类必须重新声明继承而来的虚函数，而且参数类型和返回类型都要和基类的声明完全相同。不幸的是，一个int堆栈只能压入和弹出int对象，而一个Cat堆栈只能压入和弹出Cat对象。Stack类要怎样声明它的纯虚函数才能使用户既可以创建出int堆栈又可以创建出Cat堆栈呢？冷酷而严峻的事实是，做不到。这就是为什么说继承不适合创建堆栈。
但也许你做事喜欢偷偷摸摸。或许你认为自己可以通过使用通用(void*)指针来骗过编译器。但事实证明，现在这种情况下，通用指针也帮不上忙。因为你无法避开这一条件：派生类虚函数的声明永远不能和它在基类中的声明相抵触。但是，通用指针可以帮助解决另外一个不同的问题，它和模板所生成的类的效率有关。详细介绍参见条款42。
讲完了堆栈和猫，下面将本条款得到的结论总结如下：
· 当对象的类型不影响类中函数的行为时，就要使用模板来生成这样一组类。
· 当对象的类型影响类中函数的行为时，就要使用继承来得到这样一组类。
真正消化了以上两点的含义，你就可以在设计中游刃于继承或模板之间。
考虑下面两个设计问题：
· 作为一位立志献身计算机科学的学生，你想设计一个类来表示对象的堆栈。这将需要多个不同的类，因为每个堆栈中的元素必须是同类的，即，它里面包含的必须只是同种类型的对象。例如，会有一个类来表示int的堆栈，第二个类来表示string的堆栈，第三个类来表示string的堆栈的堆栈，等等。你也许对设计一个最小的类接口（参见条款18）很感兴趣，所以会将对堆栈的操作限制在：创建堆栈，销毁堆栈，将对象压入堆栈，将对象弹出堆栈，以及检查堆栈是否为空。设计中，你不会借助标准库中的类（包括stack ---- 参见条款49），因为你渴望亲手写这些代码。重用（Reuse）是一件美事，但当你的目标是探究事情的工作原理时，那就只有挖地三尺了。
· 作为一位爱猫的宠物迷，你想设计一个类来表示猫。这也将需要多个不同的类，因为每个品种的猫都会有点不同。和所有对象一样，猫可以被创建和销毁，但，正如所有猫迷所知道的，猫所做的其它事不外乎吃和睡。然而，每一种猫吃和睡都有各自惹人喜爱的方式。
这两个问题的说明听起来很相似，但却导致完全不同的两种设计。为什么？
答案涉及到"类的行为" 和 "类所操作的对象的类型"之间的关系。对于堆栈和猫来说，要处理的都是各种不同的类型（堆栈包含类型为T的对象，猫则为品种T），但你必须问自己这样一个问题：类型T影响类的行为吗？如果T不影响行为，你可以使用模板。如果T影响行为，你就需要虚函数，从而要使用继承。
下面的代码通过定义一个链表来实现Stack类，假设堆栈的对象类型为T：
class Stack {
public:
Stack();
~Stack();
void push(const T& object);
T pop();
bool empty() const; // 堆栈为空?
private:
struct StackNode { // 链表节点
T data; // 此节点数据
StackNode *next; // 链表中下一节点
// StackNode构造函数，初始化两个域
StackNode(const T& newData, StackNode *nextNode)
: data(newData), next(nextNode) {}
};
StackNode *top; // 堆栈顶部
Stack(const Stack& rhs); // 防止拷贝和
Stack& operator=(const Stack& rhs); // 赋值(见条款27)
};
于是，Stack对象将构造如下所示的数据结构：
Stack对象 top--> data+next--> data+next--> data+next--> data+next
------------------------------------------------------------------------------------
StackNode对象
链表本身是由StackNode对象构成的，但那只是Stack类的一个实现细节，所以StackNode被声明为Stack的私有类型。注意StackNode有一个构造函数，用来确保它所有的域都被正确初始化。即使你闭着眼睛都可以写出一个链表，但也不要忽视了C++的一些新特性，如struct中的构造函数。
下面看看你对Stack成员函数的实现。和许多原型（prototype）的实现（离制作成软件产品相差太远）一样，这里没有错误检查，因为在原型世界里，没有东西会出错。
Stack::Stack(): top(0) {} // 顶部初始化为null
void Stack::push(const T& object)
{
top = new StackNode(object, top); // 新节点放在
} // 链表头部
T Stack::pop()
{
StackNode *topOfStack = top; // 记住头节点
top = top->next;
T data = topOfStack->data; // 记住节点数据
delete topOfStack;
return data;
}
Stack::~Stack() // 删除堆栈中所有对象
{
while (top) {
StackNode *toDie = top; // 得到头节点指针
top = top->next; // 移向下一节点
delete toDie; // 删除前面的头节点
}
}
bool Stack::empty() const
{ return top == 0; }
这些代码毫无吸引人之处。实际上，唯一有趣的一点在于：即使对T一无所知，你还是能够写出每个成员函数。（上面的代码中实际上有个假设，即，假设可以调用T的拷贝构造函数；但正如条款45所说明的，这是一个绝对合理的假设）不管T是什么，对构造，销毁，压栈，出栈，确定栈是否为空等操作所写的代码不会变。除了 "可以调用T的拷贝构造函数" 这一假设外，stack的行为在任何地方都不依赖于T。这就是模板类的特点：行为不依赖于类型。
将stack类转化成一个模板就很简单了，即使是Dilbert的老板都会写：
template<class T> class Stack {
... // 完全和上面相同
};
但是，猫呢？为什么猫不适合模板？
重读上面的说明，注意这一条："每一种猫吃和睡都有各自惹人喜爱的方式"。这意味着必须为每种不同的猫实现不同的行为。不可能写一个函数来处理所有的猫，所能做的只能是制定一个函数接口，所有种类的猫都必须实现它。啊哈！衍生一个函数接口的方法只能是去声明一个纯虚函数（参见条款36）：
class Cat {
public:
virtual ~Cat(); // 参见条款14
virtual void eat() = 0; // 所有的猫吃食
virtual void sleep() = 0; // 所有的猫睡觉
};
Cat的子类 ---- 比如，Siamese和BritishShortHairedTabby ---- 当然得重新定义继承而来的eat和sleep函数接口：
class Siamese: public Cat {
public:
void eat();
void sleep();
...
};
class BritishShortHairedTabby: public Cat {
public:
void eat();
void sleep();
...
};
好了，现在知道了为什么模板适合Stack类而不适合Cat类，也知道了为什么继承适合Cat类。唯一剩下的问题是，为什么继承不适合Stack类。想知道为什么，不妨试着去声明一个Stack层次结构的根类 ---- 所有其它的堆栈类都从这个唯一的类继承：
class Stack { // a stack of anything
public:
virtual void push(const ??? object) = 0;
virtual ??? pop() = 0;
...
};
现在问题很明显了。该为纯虚函数push和pop声明什么类型呢？记住，每一个子类必须重新声明继承而来的虚函数，而且参数类型和返回类型都要和基类的声明完全相同。不幸的是，一个int堆栈只能压入和弹出int对象，而一个Cat堆栈只能压入和弹出Cat对象。Stack类要怎样声明它的纯虚函数才能使用户既可以创建出int堆栈又可以创建出Cat堆栈呢？冷酷而严峻的事实是，做不到。这就是为什么说继承不适合创建堆栈。
但也许你做事喜欢偷偷摸摸。或许你认为自己可以通过使用通用(void*)指针来骗过编译器。但事实证明，现在这种情况下，通用指针也帮不上忙。因为你无法避开这一条件：派生类虚函数的声明永远不能和它在基类中的声明相抵触。但是，通用指针可以帮助解决另外一个不同的问题，它和模板所生成的类的效率有关。详细介绍参见条款42。
讲完了堆栈和猫，下面将本条款得到的结论总结如下：
· 当对象的类型不影响类中函数的行为时，就要使用模板来生成这样一组类。
· 当对象的类型影响类中函数的行为时，就要使用继承来得到这样一组类。
真正消化了以上两点的含义，你就可以在设计中游刃于继承或模板之间。
i_noname 2005-10-22
- 打赏
- 举报
"我的一个工作经验比较多的同事说，这些模板不应该用"
是指这些模板写得不好，还是指这个项目不应该用，或者是指他本人不支持使用模板呢？
是指这些模板写得不好，还是指这个项目不应该用，或者是指他本人不支持使用模板呢？
nanhaochen 2005-10-22
- 打赏
- 举报
dui ya
yhbttfile 2005-10-18
- 打赏
- 举报
正确的使用模板！坚持使用模板！
不要为使用模板而模板！
模板的确是个好东西。目前JAVA和C#正在考虑加入模板，JAVA马上出的新版本将提供模板功能。
不要为使用模板而模板！
模板的确是个好东西。目前JAVA和C#正在考虑加入模板，JAVA马上出的新版本将提供模板功能。
ywchen2000 2005-10-18
- 打赏
- 举报
摸班是个好东西，
OMA_yudy 2005-10-17
- 打赏
- 举报
copy 错了，应该是这家楼上的
OMA_yudy 2005-10-17
- 打赏
- 举报
回复人：qhfu(崩溃) ( 一星(中级)) 信誉：105 2005-10-11 20:03:03 得分:0
?
具体问题具体分析，他的观点不一定是对的，模板也不是什么地方都使用， 要看楼主具体问题是什么咯？ 在什么地方用的模板？
effective c++ 的 41条就是关于模板和继承的选择的，楼主可以看一下。而且模板的设计是比较复杂和麻烦的， 其实在具体的项目中 用得还是很少的。
在一些大的项目里才能看出代码膨胀带来的危害。
?
具体问题具体分析，他的观点不一定是对的，模板也不是什么地方都使用， 要看楼主具体问题是什么咯？ 在什么地方用的模板？
effective c++ 的 41条就是关于模板和继承的选择的，楼主可以看一下。而且模板的设计是比较复杂和麻烦的， 其实在具体的项目中 用得还是很少的。
在一些大的项目里才能看出代码膨胀带来的危害。
OMA_yudy 2005-10-17
- 打赏
- 举报
不觉的模板类好用，一旦程序有问题时，首先想的就是肯定时模板类出了问题。
而且很多时候,模板类的重用总是跟实际情况要用到的功能有些出入。
而且很多时候,模板类的重用总是跟实际情况要用到的功能有些出入。
healer_kx 2005-10-17
- 打赏
- 举报
我喜欢模板，特别是写了两天C后，发现模板真是一个宝啊。
CsdnPlayer 2005-10-17
- 打赏
- 举报
effective c++ 的 41条?
从哪里可以看到啊？
从哪里可以看到啊？
CloudOfFly 2005-10-11
- 打赏
- 举报
楼上说的很对
qhfu 2005-10-11
- 打赏
- 举报
具体问题具体分析，他的观点不一定是对的，模板也不是什么地方都使用， 要看楼主具体问题是什么咯？ 在什么地方用的模板？
effective c++ 的 41条就是关于模板和继承的选择的，楼主可以看一下。而且模板的设计是比较复杂和麻烦的， 其实在具体的项目中 用得还是很少的。
effective c++ 的 41条就是关于模板和继承的选择的，楼主可以看一下。而且模板的设计是比较复杂和麻烦的， 其实在具体的项目中 用得还是很少的。
jhLin 2005-10-11
- 打赏
- 举报
模板造成的代码膨胀????
同样一个库，摸板写出来的和非模板写出来的相比小得很多。。。例如一个简单的win32 GUI程序，用WTL编的DEBUG版才一百多KB啊。。。怎么会造成代码膨胀？
同样一个库，摸板写出来的和非模板写出来的相比小得很多。。。例如一个简单的win32 GUI程序，用WTL编的DEBUG版才一百多KB啊。。。怎么会造成代码膨胀？
MoriyaLB 2005-10-11
- 打赏
- 举报
硬件资源不足时不要用，模板造成的代码膨胀比宏和内联恐怖的多
grayloach1 2005-10-11
- 打赏
- 举报
我觉得应该是推荐使用模板类吧？
是不是那个工作经验比较多的同事不习惯使用模板类啊？
我知道有很多“老”程序员没有使用模板类的习惯。
是不是那个工作经验比较多的同事不习惯使用模板类啊？
我知道有很多“老”程序员没有使用模板类的习惯。
jeng 2005-10-11
- 打赏
- 举报
用模板也只是为了提高重用率 你当然可以不用,
可能还会有新的技术代替
可能还会有新的技术代替
加载更多回复（3）
