【调查】关于 STL

[Jinhao]

各位 兄弟，麻烦就下面的问题，讨论一下

1、你们在平时的开发中 STL 用得多吗？

2、你们是学习STL 远远超过 使用STL 吗？

3、你们觉得 STL 有哪些不足 或 在实际的开发中它不能满足当前的需要？

4、想过对 STL 进行扩展吗？或做过哪些扩展？

5、欢迎说出其他的想法

欢迎参与~~

[step_by_step]

对于2，我再补充一句，希望能够有B+树实现的容器。因为很多时候，我们的程序需要对磁盘政列上的海量数据进行操作，我发现这时候STL就顶不住了。没有什么容器能够有效的管理我存放的磁盘政列上的文件索引。只好自己开发了一套B+树类，希望能够和STL整合起来，可以在我们项目中用。

[step_by_step]

to Jinhao:

项目需要我已经写过好几个容器，感觉迭代子的感念很不错。一种很不错的粘合剂
可以让我的容器轻松的和STL里的算法相融合。

[step_by_step]

to Jinhao

对于具体的代码，因为公司版权问题，实在抱歉不能贴上来。但是我可以谈一下当时我为什么要设计这个容器，以及怎么样去设计这个容器的一些想法，这些想法可能会有偏颇，我就当抛砖了。对于你所说的出书，呵呵，我是个懒散的人，恐怕没有希望了。

首先我想声明这一点，所有的代码都源于客户的需求和我自己对以后的可维护性可扩展性的需求，以及一些考虑到性能的设计。如果下面看到一些不能明白的话，那么请往我的这几个出发点上靠拢。

开发平台：hpux
开发工具: aCC(hpux自己的c++开发工具，用的感觉还可以)

我设计（姑且称作设计吧）过一个话单（可以理解成数据库表中的一行record）容器类,说明白点，就是此容器存放我们业务系统中从数据库中所取出的的话单，用来给后继模块进行处理。


看到此处，也许各位看官会弹出一个idea，为什么不直接用vector存放了？
嗯，为什么我不选择vector？因为我受不了vector的大数据量时内存的大量移动，看过vector代码的看官，应该会明白这点。



那为什么不用list了？
因为list的内部实现在内存上不是连续的，所有又被我舍弃了。


那为什么要在内存上连续了？
呵，问到点子上了。因为我的本意是在一个内存池上构造我自己的话单容器，我希望这个话单容器简单并且能够满足我的一些基本要求，比如能够向前迭代，顺序取出我所要的字段等等。这个容器无需多强大，只要能够


那为什么要在内存池上构造了？这个内存池又是怎么来的？又用来存放什么的？
因为这个内存池是用来存放我通过oci(oracle call interface)从oracle中取出的数据。这个内存池里面是连续的存放一次操作所取出来的结果集。因为我厌倦了用c中的两个指针遍历内存池（或者是一个指针加偏移遍历内存池）来取出话单,而且在取出话单和写话单这一块代码上，如果用c分格写的话，如果以后话单格式变化的话会出现switch...case结构，这是吾等oo之辈最不喜欢看到的吧？违背了ocp法则。所以我想在这个内存池上构造一个话单容器类，把变化封装到对象中。以后就可以根据不通的话单格式派生出不通的话单容器。而根据stl里面的concept，一个东西它像迭代子那么就是迭代子，因为我可以把一个raw指针认为它就是迭代子，而vector中的确raw指针就是它的迭代子。

一口气写了这么多，累了，喝口水先。

大家看看有什么疑问，和有什么想法，尽管发表，我很久很久没有在csdn发技术贴了，呵，感觉不错，又像回到了大学年代，那时候csdn上都是牛人。。。。怀念。

[Jinhao]

to step_by_step
呵呵，的确很不错。不妨开个帖子把你的容器供我们学习学习。

在为某些容器写iterator时，为了满足一些特殊的要求，而这样的iterator会变得很臃肿。
打个比方，例如 一个由std::list构建起来的容器。为了个真个容器实现一个可随机访问的iterator，而且还可以检测是否越界。那么这个iterator必将会很臃肿(因为要保存begin/end的位置，从而每次操作++或--时检测是否越界)。

对于这个问题，不知道你们是如何舍取的。是否需要这样的iterator， 或者这样的iterator是否与std::list本身的原则相背离。

还有一个问题。例如上面的iterator被实现出来了，在进行越界检测时，如果发生越界。你是选择抛出异常吗？还是选择把iterator的值设为end？
麻烦各位献智，讨论一下。

[Jinhao]

废人一句话打击得我无力，说道：在没有实际需求的情况下，设计原则都是空谈。
此话不错，step_by_step 麻烦请你说说在写容器的时候，对一些取舍细节是如何控制的。这样方便你以后出书，嘿嘿 :-P

[Jinhao]

good，虽然vector也可以在初始化时指定出容量大小，这样就避免了因容量不足而导致的数据移动。但是它总要调用元素的构造函数来构造出一个新对象，并拷贝构造填充到这片内存上。
vector<int> a(10);
cout<<a.size()<<endl; //10个元素
a.resize(0); //可以清空，但始终避免不了再次调用元素的构造函数，虽然这里不需要调用

这样的代码可能会潜伏一个BUG，例如，计算一个类对象被默认构造了多少次
struct A //为了图方便，所以用struct
{
static size_t count_;
A(){
cout<< ++count_ <<endl;
}
};
size_t A::count_=0;

int main()
{
vector<A> a(10);
cout<<a.size()<<endl;
a.resize(0);
//自己并没有构造A的实例，却发现A被默认构造了2次
}

[step_by_step]

我对vector对大数据量操作的效率，向来不看好。一般只用vector存放一些小数据，比如配置文件的参数，环境变量的参数而已。

[xiangzhengyan]

学习时用的多,真正写程序时用得少,比如 VC里有CString,谁还会用std::string

[BluntBlade]

搬凳子听课中。

[Jinhao]

在对性能要求比较高时，vector确实不爽，而list也不爽。这主要是STL的内存管理原则决定，因为你不能直接操纵底层的内存分配。折中的就是deque这个通用容器可以满足了。
STL并没有终止任何人进行发明创造，只要你创造的东西符合 它提出的策略和概念，这必定会让你拣到不少便宜，当然这点少不了它所具备framework的模型

一般我们用STL最多的是容器。其实后面的adapter一样很实用。

to 刀子：
如果你都是听课了，那我只有去上幼儿园了，向老师致敬，嘿嘿

[BluntBlade]

to 鸡丁
其实我很懒的，平时都是玩游戏多。认真搞C++的时间并不太多……
只有在遇到问题时才会去动脑筋的。

[palm99]

刚刚听说。来学习一下。

[nscboy]

正在研究boosts,文档英文的居多,真费劲.

[step_by_step]

大家继续。砖头出来了，玉了？

[shenyiwen]

对于类似vector，又需要快速插入删除的可考虑rope，不过不是标准，只在SGI的扩展里，gcc也有

[step_by_step]

to fangrk:

你在苏州？

我想很多时候设计的产生都是因为有需求存在。我之所以想设计如我上面所说的容器是因为效率和复用的方便。

我当初曾考虑过重载Allocator，让STL的容器产生于我的那块内存池上，但是发现工作量比我写一个轻型的，能够工作的容器类，大多了。为了时间，只有先写自己的容器类。写完后测试一下，发现效率还是可以的。

标准容器是经过千锤百炼，但是不一定他就是所有的应用容器场景里最适合最优秀的那个。
标准容器里有太多我不需要的copy和operator=,所以我想设计最适合我的那个内存池格式的容器，因为我的那个内存上是先有数据(数据从oracle里通过oci接口导入到内存池中)，然后我再在这个内存池上建立我自己的话单容器类，这样就封装了对这个内存池数据的操作，效率也不错，如果我此时硬是要建立list<T *>的话，则会引入多余的拷贝和赋值，权衡效率，只有设计STL container,自己建立了。

[aixuer]

今年上大二，我要开始学stl了。手头上有一本《C++标准库》 jj侯翻译的那一本。
楼上各位发言，觉得自己懂得的东西太少了。

step_by_step(脚印)说“我很久很久没有在csdn发技术贴了，呵，感觉不错，又像回到了大学年代，那时候csdn上都是牛人。。。。怀念。”。

我想牛人总归是由菜鸟转变而来的，我想有一天我辈也将成为牛人。但是您和“您”们的支持是我辈成长最好的肥料，不是吗？盼望您以后能有超级精彩的技术贴。

[dnnupt]

鸡丁兄的帖子总能把高手吸引来，所以来学习啦

1、你们在平时的开发中 STL 用得多吗？----能用的地方，最先想到它

2、你们是学习STL 远远超过 使用STL 吗？----可以这么说吧，因为现在几乎没有机会用：）

3、你们觉得 STL 有哪些不足 或 在实际的开发中它不能满足当前的需要？

用的不多，水平还不够，所以对STL还是人云我亦云------STL好！ ：）

4、想过对 STL 进行扩展吗？或做过哪些扩展？

想，为什么不想，但是能力有限，所以还是仅仅处于“想”的阶段！

5、欢迎说出其他的想法

希望我的回复，大家不要认为我是在捣乱 ：），虽然我的态度不够“严肃”，但是所言却是真心的！

[step_by_step]

看不到好贴，结了吧

[fangrk]

STL很好，现在不用STL都写不出程序了。

在大多数情况，我觉得没必要自己去写容器，除非标准的容器中不能满足你的要求，但是，标准中的容器都是经过工业强度设计被广泛应用的，自己设计的容器有那么可靠吗？当我遇到单一容器无法满足我的要求的时候，通常会采用容器的组合(并不只是嵌套)。比如:

typedef map<string,pair<double,int> > CountInfo;
typedef list<CountInfo> CountInfoContainer;
//不能使用比如vector或者deque之类的在push_back的时候会导致底层移动的容器，可以使用slist
typedef map<string,CountInfo*> Location;

Location中的CountInfo*指向CountInfoContainer中的元素，这样不必自己动态分配，也避免了频繁的内存移动。

vector虽然在调整的时候需要大规模移动底层数据，list虽然不能随机访问，但你可以设计一个容器既能随机访问又能很少的底层移动吗？何况自己写容器最好还要能与标准算法配合工作，个人觉得这是比较有挑战性的工作。在需要随机访问，或者元素数量比较小的情况下我直接使用vector，遇到大规模的需要随机访问的可以先预留空间；大规模数据/随机访问/不能预测容量我使用list，全部加载到list后可以用vector<T*>来指向list中的元素达到间接随机访问，哪怕你需要对list中的元素排序也可用通过vector<T*>来间接排序(六月份开发高手有一篇《C++中的直接排序和间接排序》)。标准容器都是千锤百炼的，我宁愿花点时间考虑如何使用标准容器的组合拳来达到目的也不想通过自己设计容器来实现。

声明一下，我不是职业程序员，只是C++爱好者，所从事的工作只与编程有点沾的上边。

我单位旁边开28th世界遗产大会，中午早半小时吃饭，所以有时间胡乱写点东西。