huaxiazhihuo

 

stl的缺陷抽象不足

总的来说,stl整个的设计还是很有水准的,抽象度非常高,采用泛型template手法,回避面向对象里面的虚函数,回避了继承,做到零惩罚,达到了非侵入式的要求(非侵入式远比侵入式要好,当然设计难度也更高出许多)。高性能、可扩展,容器提供迭代器,而算法则作用在迭代器上,容器与算法之间通过迭代器完全解耦,同一种算法可用于多种容器,只要该容器的迭代器满足其算法的要求;而同一个容器,又可被多种算法操作。更重要的是,容器与算法之间完全是开放的,或者说整个stl的体系是开放式,任何新的算法可用于已有的容器,任何新的容器又可被已有的算法所运算。然后,考虑到某些场合下容器的内存分配的高性能要求,分配器allocator也是可以替换,虽然逼格不高。此外,容器算法体系外的边角料,比如智能指针、anyiostream、复数、functio等,也都高性能、类型安全、可扩展,基本上都是c++风格量身定制,这些都无可厚非。真的,stl作为c++的基础库,已经很不错了。只是,依个人观点,当然,以下纯属一家之言,某些情况下,stl可以做得更好,或者说api的使用上,可以更加清爽。以下对stl的非议,似有鸡蛋里挑骨头之嫌,吹毛求疵,强挑毛病。

 

软件框架或者说库的设计,是由需求决定的。脱离需求的设计,不管多精致,代码多漂亮,一切都是废物,都是空谈。程序库所能提供的功能,当然是越强大越好,可扩展,高性能,零惩罚,这些明面上的概念自然重要。殊不知,程序库不能做的事情,或者说,其限制条件,或者说程序库对外界的依赖条件,也很重要。一个基础库,如果它敢什么都做,那就意味着它什么都做不好。事情是这样子的,如果只专注于某件目的,某些条件下的运用,往往可以获得更大的灵活性或者独立性。首先,代码必须很好地完成基本需求,在此基础上,才有资格谈论点什么别的更高层次的概念。

 

上文提到stl由于对动态类型的排斥,所导致的功能残缺以及二进制复用上的尴尬,如果stl愿意正面在动态类型做完善的考虑,相信stl的格局将会大很多,动态类型的话题,本文就不再过多重复了。当然,动态类型的引入必须满足零惩罚的必要条件,c++的程序库,所有不符合零惩罚的概念,最后都将被抛弃。所谓的零惩罚,就是不为用不到的任何特性付出一点点代价。请注意,这里的零惩罚必须是一步都不能妥协。

 

比如说,字符串实现的引用计数、短字符串优化这些奇技淫巧,就不是零惩罚,短字符串优化的惩罚度虽然很轻微,每次访问字符串内容时,都要通过字符串长度来确定其数据的地址,长度小,字符串就放在对象本身上,从而避免动态内存分配。长度大,字符串就放在对象外的堆内存上。短字符串优化空间上的惩罚,字符串对象的占用内存变大了,到了长字符串的时候,字符串对象里因为短字符串的内存空间就没有任何价值。在32位机上,字符串对象可以只包含内存分配器地址,字符缓冲起始地址,字符长度,缓冲的大小,满打满算,也就16个字节。而短字符串优化,就可能要用到32个字节。其实,如果有一个高性能的内存分配器,短字符串优化完全就可以没有任何必要。算了,扯远了,我们还是回到stl的设计思路上吧。

 

大家都知道,stl的字符串其实顶多就是一个字符缓冲管理对象。都98年的标准库了,完全就没有考虑字符编码的需求,真是奇怪之极,令人发指的完全偷工减料。是啊,字符编码不好搞,但是既然有这个需求,就必须支持啊,鸵鸟政策是行不通的。虽然说框架上设计可以既然做不好,那就完全都不做。但是,作为字符串组件,不鸟编码,你真的好意思以字符串自居。撇开编码,string居然有一百多个函数,更让人惊喜的是,这一百多个函数用于日常的开发,还远远不能满足需求。仔细看,这一坨函数大多数仅仅是为了性能需要上的重载,为了避开临时string对象搞出来的累赘。所以,stl里面必须要有一个只读的字符串,不涉及任何动态内存分配,也即是c++17string_viewstring_view里面有一个很良好的性质,string_view的任何一部分还是string_view(不同于c语言字符串的以零结束,必须带零的右部分才是字符串),然后string_view就可以做只读字符串上的运算,比如比较,查找,替换,截取等,分摊string里面大部分的函数。很奇怪的是,string_view这么有用的概念,居然要到c++17里面才有,都不知道stl委员会的人才在想什么。由此可见,如果class里面的成员函数如果过多,好比一百多个,那么其设计思路就一定大有问题,甭管它的出处来自何方。

 

同理可得,只读数组array_view也是很有用的概念,它是内存块的抽象。array_view的任何一部分都是array_view,不同于string_viewarray_view仅仅是长度不能变,但是其元素可修改,可以把array_view看成其他语言的数组,但是array_view不能创建,只能从vector或者c++数组获得,或者又可以看成是切片,array_view本身可以有排序和二分查找的成员函数。Array_view可以取代大多数vector下的使用场合。很奇怪的是,这么强有力地概念,c++17上居然就可以没有。差评!另外,我想说的是,对于排序二分查找,就仅仅用于连续内存块上就好了,其他地方则可免就免,搞那么多飞机干什么,stl在排序二分查找的处理上显然就是过度抽象。

 

或者有人反对,array_viewstring_view不就是两个新的容器,把它们加进stl里,不就行了,stl体系设计完备,绝对对外开放。不是这样的,array_viewstring_view的出现,严重影响现有的stringvector的设计,这两者必须基于array_viewstring_view的存在整个重新设计。

 

Stl就是对良好性质的基础数据结构缺乏抽象,容器的设计只到迭代器为止,提供迭代器之后,就高高兴兴对外宣称完成任务,不再深入地挖掘,可谓固步自封,浅尝辄止。在stl的世界观里面,就只有迭代器,什么都搞成迭代器,什么都只做到迭代器就止步不前,可悲可恨可叹!在其他基础容器的设计上,缺乏深入的考虑,罔顾需求,罔顾用户体验。对于链表的定位,就足以体现其眼光的狭隘。

 

众所周知,单向链表的尾部也是单向链表,可类比haskell或者lisp的列表,这么强有力的好概念,stl里居然完全没有单向链表,更别说凸显此概念。当然,单向链表里面只有一个节点指针,不能包含内存分配器的,也不能有元素计数器,而且生命周期也要由用户控制,但是,用户控制就用户控制,这一点都不要紧,特别是存在arena allocator的情况下,拼命的new单向链表,最后由arena allocator来统一释放内存好了。总之,stl太中规中矩,对于离经叛道的idea,完全就是逃避就是无视,对于动态类型的处理,也是这种态度。Stlallocator的处置,太过简单粗暴,一步错,步步错。

 

而双向链表,在付出O(n)的访问代价后,在为每个元素都要付出前后节点的内存占用后,应该得到咋样的回报呢?显然,stllistO(1)插入,O(n)通过迭代器删除元素,无论如何,完全不能接受,回报太少。首先,O(1)删除元素,不能妥协。为达此目的,我们先开发一个隐式侵入式要求的循环链表,它不关心元素的生命周期,任何插入此链表的元素,其首地址之前必须存在前后节点的指针。然后,链表本身的首两个字段是头节点和尾节点,内存布局上看,循环链表自身就是一个链表节点,一开始,链表为空,其首尾字段都指向自身。这种内存布局下的循环链表和其节点的关系非常松散,节点的插入和删除,只需要修改其前后节点的前后指针的值,完全不需要经过链表本身来完成操作。要删除元素时,只要往前爬两个指针的位置,就得到包含此元素的节点,进而时间O(1)上删除节点,何其方便。显然,循环链表不能包含节点数量,否则每次删除插入节点,都要加11链表的计数器,节点和链表就不能彻底的解耦。这种内存布局上的循环链表,就可支持多态了,比如,比如,xlist<Base> objects,可把Derived1类型的对象d1Derived2类型的对象d2,插入到循环链表xlist里,只要d1d2的前面保留前后节点指针的内存空间。

 

然后,封装这个裸循环链表,用allocator管理其节点元素的生命周期,好像stllist那样,创建删除节点元素。封装过得链表,节点和链表的关系就不再松散,因为节点必须通过链表的allocator来分配内存回收内存。但是,O(1)时间的删除节点,完全是没有任何问题。并且也能支持多态,可插入子类对象。相比之下,可见stllist有多弱鸡,简直不知所谓。

 

不管怎么说都好,stl里面对字符串的支持很薄弱,要有多不方便就有多不方便,虽然比C要好多了,这个必须的。当然,有人会辩解,很多操作很容易就可以添加进去的,但是,如果标准库支持的话,毕竟情况会好很多,不一定要做成成员函数,之所以迟迟未添加这些常用的字符串函数,怀疑是因为找不到合适的方式添加这些操作。字符串的操作可分为两大类,1、生成字符串;2、解析字符串。这两大类,都是格式化大显身手的地方,也即是sprintfscanfc++下的格式化函数,可以是类型安全,缓冲不会溢出,支持容器,支持成员变量名字。这样子,通过格式化,可以吸收大部分的字符串操作。可惜,stl对于反射的排斥,功能强大的格式化处理是不会出现的,而字符串操作,也将永远是stl的永远之痛。堂堂c++唯一的官方标准库,居然对最常用(可以说没有之一)的编程任务字符串操作支持如此灰头土脸,真是要笑死人了。为什么这么说,因为本座的库早就实现了这些想法(包括string_viewarray_view,不带allocator类型参数的各种容器),字符串的处理,简直不要太方便,比之stl的破烂,不可同日而语。比如,在c++中,完全就可以做如下的字符串操作。
vector<byte> buf = {…};
u8string codes;
Fmt(codes, “{ 
~%.2x}”, buf);//codes就是buf的16进制显示,小写,即是”xx xx … xx”。符号~表示前面的部分(这里是一个空格)作为元素之间的分隔符。
vector<byte> copied;
Scanf(codes, “{ 
~%.2x}”, &copied);//这样就把文本codes解析到copied里面去
assert(Equals(buf, copied));

不用格式化,在stl下,用iostream要实现这样的效果,不知道要写多少恶心的代码,反正很多人都已经想吐了。有了格式化之后,日子美好了好多。对了,上面的vector<byte>可换成list<byte>,代码完全都可以成立。Fmt的第一个参数表示格式化结果的目标输出对象,可以是文件,标准输出stdoutgui的文本框等。同时,Scanf的第一个参数表示格式化的输入源,可以是stdin,文件等。总之,FmtScanf这两个函数就可以概括所有的格式化操作,这两个函数,基本上可以解决满足日常上大多数关于字符串的操作。其实格式化的实现,离不开运行时类型信息的支持,本座要有多大的怨念,才会一而再地抱怨stl在反射上的无所作为。

至于iostreamlocale本座就不想批评太多,免得伤心难过,因为iostream竟然出自c++老父bs之手,必须是精品,某种意义上,确实是!


啰里啰嗦一大堆不满,还没有写完。后一篇的文章,主角是迭代器,整个stl的大亮点,同时也是大败笔。既造就了stl框架的灵活性,同时也导致stl函数使用上的不方便,特别是stl算法函数的冗余,非正交,不可组合。你看看,findfind_ifremove, remove_copy, remove_copy_if, remove_if,……,难道就不觉得面目可憎,低逼格,心里难受,堂堂大c++标准库算法的正儿八经的函数,标准会要有多扭曲的审美观,才会这样设计如此丑陋的接口,难道就没有一点点的羞耻心理!这种接口怎么可以拿出来见人见证,丢人现眼。

posted on 2017-07-09 11:35 华夏之火 阅读(393) 评论(5)  编辑 收藏 引用 所属分类: c++技术探讨

评论

# re: stl的缺陷抽象不足 2017-07-10 11:49 天下

写的很好,学习了,既从宏观入手俯瞰,也在细节处分析的透彻.
呵呵,
,搞C++的都有点完美主义.

我现在是自己用MFC封装轮子,凑合着用
界面用xtreme toolkit pro搞.
有机会打算玩下kotlin做android开发.

  回复  更多评论   

# re: stl的缺陷抽象不足 2017-07-10 11:55 天下

做linux开发就用QT,都搞过....QT还不错
  回复  更多评论   

# re: stl的缺陷抽象不足 2017-07-10 14:08 华夏之火

@天下
mfc,xtream,qt都是垃圾,都不值得花时间。c++的gui开发,除了qt,似乎也没有更好的选择  回复  更多评论   

# re: stl的缺陷抽象不足 2017-07-10 15:29 冬瓜

@华夏之火
相对来说,C++搞UI的开发,还是C++Builder最好。  回复  更多评论   

# re: stl的缺陷抽象不足 2017-07-10 15:34 冬瓜

贴主讲到的很多问题,都是历史问题。那个时候电脑的性能还是非常差的,不像现在。那个时候,能跑一个win95,才8M或16M内存,CPU才100mhz,所以那个时候包括MFC,STL设计的都让现代人不理解。  回复  更多评论   


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿(3)

随笔分类

随笔档案

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜