讨论：template技术就只是做类库的？
boost,stl,loki,都是大量的用到template，大家学了template，难道只是用来看那些库。谁能在企业应用中用它，比如，构造一个范型的进销存类库，或者说，范型在高端领域，根本没有用武之地？
[解决办法]
是学院派的一种代表,
不过代表了以后的语言所发展的趋势
从学院派到工程应用需要经过很长的时间
建议楼主可以看看0x标准的相关的报道就可以知道一些情况了.
[解决办法]
你要高兴，
自己写一个不也是可以的么？
没有人禁止啊 ～～～～～
[解决办法]
。。。template 的根本目的就在于 source level re-use，而 source level re-use 只是 library 的（部分）特点。应用程序强调的是 delivery the functionality to user，至于具体用什么技术什么手段，根本无足轻重。
[解决办法]
呵呵，以前和OOPhaisky(异化$渴望成功~~) 他们讨论过一摸一样的问题
后来看了
http://blog.csdn.net/jeaking/archive/2001/12/08/6420.aspx
http://topic.csdn.net/t/20010926/10/303177.html
http://dev.csdn.net/article/11/11902.shtm
汗颜了，刚才又看了一遍，现在就找个山洞苦修去
还是厚着脸皮把朋友们的讨论贴出来，希望朋友们不要介意
甲:
开个讨论，我先抛砖引玉。今天看了C++设计新思维上实现Functor那一节。感觉GP更适合类库设计而不适合系统设计。
首先说说GP的优势，个人认为GP的主要优势在于代码复用，执行效率，和类型安全，易用性。而这正是类库设计需要的特性。作为大型系统来说，代码复用就没有那么重要了。关键是降低设计的复杂性，降低维护的难度，还有就是可扩展性。
个人认为在这方面GP做得不好。就设计来说，写出优质的泛型代码很困难，过多的考虑使用GP来使代码可复用反而会增加设计的复杂性。泛型代码的可维护性也不如OO好，特别是那些比较精巧的泛型代码，看懂要好半天。
其次GP不但会增加系统设计的复杂度，就设计类库来说，用GP也要更困难一些，个人认为C++类库设计困难的原因之一不是应为C++的多范式，而是因为进行类库设计时过分热衷GP。
就可复用性来讲，说GP具有更好的复用性也是不完全的。GP的可复用性体现在对各种型别只要满足一定的要求都可以简单复用一些类库中的组件上。对那些功能上的复用并没有什么优势。比如说我需要一个FTP类进行数据传输，对FTP类的复用上，GP没有优势.
就执行效率来说，也是类库设计才更关心的，对于系统设计来说，根据二，八定理，GP所带来的效率提高也不是太重要。
乙:
作为大型系统来说，代码复用就没有那么重要了
---
这个我不同意，如果不复用，产生很多重复的，类似的代码，是很严重的问题，对开发效率，产品质量，维护难度都有很大的不利影响。
写出优质的GP代码是很难，但我觉得，任何复用，都要讲一个度，如果一说写GP代码，就要能跨平台，效率高，对各种类型都要有良好的行为，等等，这个恐怕很少人能完成。不但GP难，就算OO也一样，甚至更难。
OO和GP并没有什么冲突，还是看各自适用的地方，GP就是适合于写库的，写库本来就很难，特别是，效率和设计的优雅往往是矛盾的，GP能达到一个更好的平衡。
甲:
任何复用，都要讲一个度，如果一说写GP代码，就要能跨平台，效率高，对各种类型都要有良好的行为，等等，这个恐怕很少人能完成。不但GP难，就算OO也一样，甚至更难。
－－－－－－－－－－－－
同意，我正是想弄清GP在实际工作中的应用程度，对我自己而言感觉结合GP和OO编程有点困难。分别代表了不同的思维模式。个人认为GP是对对象和行为之间的关系的一种抽象，而OO是对对象与对象之间关系的一种抽象。感觉OO很重要一点就是将对象的数据和行为进行封装，而GP却是将类型和行为分割开来。虽然这一点并不矛盾，而且自己也并不喜欢纯OO，但感觉要将两这结合起来编程感觉很困难（这可能是自己的原因，自己编程经验严重不足：） ），当然GP中也大量用到封装，和继承，但个人认为这并不是OO和GP相结合编程。
话题扯远了:),我想问的是GP能不能降低大型系统设计的复杂度，虽然软件工程中没有 "银弹 "，但感觉OO的确在一定程度上降低了系统设计的复杂度，如果在系统设计中考虑GP，反到会增加复杂度。
GP在类库的设计上的强大功能这是有目共睹的，这一点不光体现在STL,这样比较低层应用的设计上，像WTL这样的GUI库，编译出来的程序大小远小于同样功能MFC程序，在使用上个人感觉也更容易一些。
个人感觉GP更像小型的framework,但又有点不贴切，它提供工具和生成工具的基本框架，而OO更适合在此基础上进行系统开发。
个人的一点拙见，再次抛砖引玉：）
------------------------------------------------------------------乙:
我的感觉正好和你相反：）我觉得OO会增加复杂度，GP能降低复杂度。
类的继承层次多了以后会很复杂，继承关系是一种非常强的耦合，好的设计避免滥用继承，GP对类型解耦，是比OO更高层次的抽象。这个对降低整个系统的复杂度是有很大好处的（当然，GP技术本身似乎比OO要复杂很多）。
你说GP象小型的framework，我也不太同意，我觉得GP更象是非常独立的“组件”，拿来拼装一下就能用的，灵活性非常大。不像所谓的framework那么死板。
说到实际工作，恐怕大量使用GP的机会不多，没看CSDN上讨论的吗，连STL都不让用呢，因为怕组里别人看不懂。。。虽然我不同意这个观点，但实际情况确实是，懂GP的C++程序员是少数。
你说的OO和GP思想的结合，是有一定的难度，说到底，还是个度的问题，该分开的时候分开，该封装的时候封装，std::string的设计不是有大牛说它太胖了吗？里面很多成员函数其实是可以分出来的。但还有很多人说它封的函数太少，不好用，可见这个度的把握的确是很难的。用户不同，层次不同，看法也不同。
乙:
补充一下，关于string的设计，我觉得应该尽量减少string类的成员函数，把能对类型解耦的函数都拿出来重用，然后再写一个fat_string，组合string类，加上所有方便用户使用的成员函数，内部实现使用那些独立出来的重用函数即可。这样就可以满足不同用户的需求了。
甲:
类的继承层次多了以后会很复杂，继承关系是一种非常强的耦合，好的设计避免滥用继承
--------------------------------------
同意，OO用的最多的是封装，而不是派生，过多层的继承会造成复杂度的不可管理。但适当控制继承层次，在合理的地方使用继承可以控制复杂度，如果用到了继承那很有可能是需要多态，比如说在处理异质对象的集合上，个人决定OO要做的好一些。
#include <iostream>
#include <vector>
#include <boost/shared_ptr.hpp>
using namespace std;
using namespace boost;
class IBASE
{
public:
virtual void doSomething() const = 0;
virtual ~IBASE(){};
};
class DeA: public IBASE
{
public:
void doSomething() const { cout < < "DeA " < <endl; }
};
class DeB: public IBASE
{
public:
void doSomething() const { cout < < "DeB " < <endl; }
};
int main()
{
typedef vector <shared_ptr <IBASE> > IBASEVec;
IBASEVec vec;
vec.push_back(shared_ptr <IBASE> (new DeA));
vec.push_back(shared_ptr <IBASE> (new DeB));
for(IBASEVec::iterator iter = vec.begin();
iter != vec.end();
++ iter)
{
(*iter)-> doSomething();
}
}