huaxiazhihuo

 

非完美的stl

       C++类库开发之难,举世公认,最好的证据就是,1983年到现在,面世几十年,就没有一个正儿八经的基础类库。是啊,零惩罚,要高性能,要跨平台,要可扩展,要人性化,又没有垃圾回收的支持,又没有运行时类型信息可用,……,这些方方面面的因素纠结在一起,就好像一个巨大的意大利面线团,真的是众口难调至极。相比C#,java,php等,python等杂碎,它们面世不多久,马上就有官方的标准库,你要说这些杂碎的标准库有多好,那也未必,问题是就有大量人马心悦诚服高高兴兴地用之于开发,没有什么所谓的破心智包袱影响开发效率,甚至有人坚持认为直接用c开发,开发速度都可以快过c++。哪像c++的破事一大坨,总之就是没有一个好的基础库,能够让所有的c++开发者大爷满意。你要说这些c++大爷难侍候,也未必,因为的确就是,不管怎么呕心沥血捣鼓出来的库,确实就是是存在这样那样的问题,以至于后面的大量使用中,缺陷扩大越来越明显,难以忍受。

c++之父一直在重复强调,c++本身美过西施,美得像杨玉环,c++本身没有问题,只是欠缺好用的基础库。问题是好用的基础库千喊万喊,迟迟就是不肯露面。这种情况下,就很让人怀疑c++的存在意义了。因为很明显的事实,其他的后生语言早就有庞大严谨的标准库,就你c++诸多借口,搞不出来合格的基础库,难道不是c++语言本身就存在重大缺陷,所以才有此困境。很多c++的老残党(包括本座),都很赞同c++之父的观点,c++本身很好,就是欠缺好用的基础库。因此大力出奇迹,集整个c++界的精英,花多年的研发,终于奋斗出来stl这个“精品”,另外,还准备了一个候补的boost,以满足非正常性的需求。

平心而论,stl还是相当不错的,高性能,可扩展,零惩罚,跨平台等,基本上都满足要求了。除了二进制不能共用,除了编译速度慢,除了代码膨胀,除了出错的时候,可能铺天盖地的错误,这也是没有办法的事情,世上哪有十全十美之事。总之,在基础设施严重施缺乏的c++上面,能够做出来这么一个玩意,已经很不容易了。最显然的事实,面对着stl,除了一小撮乱党,广大劳动群众普遍都认可stl。只是,既然stl是c++里面如此官方的基础库,就有必要接受更高标准的考验。而最终,stl整个的设计,也不可避免地,也绝非完美。这由此可见,c++基础库开发的难度。

stl里面的字符串,编码,iostream,locale,allocator,algorithm里面算法函数的重复(非正交)等的问题,都只是表象。根子上考察,stl的设计思路上犯了左倾和右倾的问题。具体表现如下:
1、对动态类型的畏惧,对静态类型的过度拥抱。这个问题在c++11之后,有一定程度的改善(出现了shared_ptr, any, variant,内里用到动态类型,起码有virtual的关键字使用)。最明显的表现就是,把内存分配器allocator做成静态类型信息,由此造成的麻烦,真是罄竹难书。同一个整型的vector,因为使用不同类型的allocator,也即是,vector<int, xalloc>和vector<int, yalloc>居然分属不同的类型,然后有一个函数要处理整型数组,要么只能做成模板函数,放在头文件上,c++原本就编译速度龟慢,再这样玩,简直雪上加霜;如果函数坚持放在cpp文件里面,就只能处理专门的allocator的整型vector。基本上,用stl打造的公共代码,都要做成头文件的共享方式,然后每次小小修改,都要引起连锁的编译雪崩,大型的c++项目,对于头文件的修改,考虑到感人的编译速度,从来都是非到不得已的时候,能不动就不动。岂有此理,天理何在。c++17,标准库终于接受多态的allocator,这算是对过去左倾激进的纠正。某种程度可以上改善这个问题,因为到时候就可以只专门接受多态的allocator,只可惜,还不完备。

考虑批量分配arena类型的allocator,理想情况下,对于在此arena allocator上分配的对象,假如仅仅涉及到内存问题,其实大多数情况下,析构函数做的就只是释放内存。那么完全就可以不必苦逼的一个一个调用对象的析构函数,仅仅把arena allocator的内存归还给系统就好了,这对于运行性能的改善,意义重大,本座测过,真是快了很多。问题是,现有stl的体系下,不能保证容器的元素也使用和容器一样的allocator,或者说,容器的allocator对象无法传递给它的元素,让容器元素也使用同一个allocator对象来分配内存。比如说,vector<string>,vector和string的allocator都用polymorphic_allocator,但是,vector的allocator对象和string的allocator可能不是同一个。这样子,我们就不能仅仅简单的归还allocator对象内存,而必须像过去那样子,对vector<string>里面的每一个string都调用析构函数来归还内存了。差评!所以,一开始,allocator就不应该成为模板参数。另外,stl对allocator的粒度也考虑不周。allocator的迥异应用场合起码有几种:1、静态allocator,专门在main函数运行前的使用,用于生成元数据,这些元数据不必一一析构,主函数结束后,统一一次性释放;2、全局的allocator,考虑多线程考虑并发;3、scope,可以在一个任务下使用,任务完毕,统一释放,这里包括函数或者协程;4、gui下的allocator等;只可惜,stl的allocator就只关注全局的allocator。

既然stl对allocator都可以搞成静态类型的鬼样子,那么整个stl对运行时类型信息的忽视,逃避,就可想而知了。typeid得到的type_info,除了起到类型的唯一标识符的作用(动态库下,同一种类型的type_info可能还不一样),并得到类型的名字之外,就不知道这个type_info还有什么鬼用。即便是这么一点小功能,还是能用于很多地方的,比如,any,variant,双分派(double dispatch),由此可见运行时类型信息的重要性。

动态类型信息,也即是反射的重要性,一点都不亚于静态类型信息。意义重大,有了反射,我们就可以将类型当成变量,到处传来传去,也可以保存起来,供后面使用,这里可做的文章,可挖掘的潜力太多了。假如c++的反射信息完善的话,很多头文件上的模板代码实现就可以放到源文件里面,模板函数仅仅是提取一下静态类型的运行时对象,类型擦除,具体实现代码就可以放到cpp代码里面去。然后,虚模板函数也可以成为可能了。可以用来创建对象,析构对象,消息发送,非侵入式的接口,序列化……,甚至,连多继承也都是多余(当然,多继承还是很有用,只是这货不应该出现在正式的场合下)。最典型的例子,格式化printf,通过c++11的variadic template,提取类型的运行时类型对象再连同入参的地址,就可以实现现在c库里面的那个弱鸡sprintf,类型安全,缓冲安全,高性能的效果,不但类型可扩展,连同格式化的控制字符都可扩展,甚至还能支持变量名字。stl里面的iostream、locale的设计成这个鬼样子,也是因为运行时的缺失导致。c++里面要妥当地处理好字符编码、字符串、文件流、locale这几者的关系,绝对不是一件容易的事情,所以也难怪stl在这里的一塌糊涂。看过iostream,locale的实现源码,大家都说不好,大家都很难受,简直可以和mfc媲美,这是真的。

c++的反射可以做到零抽象,也即是,只对必要的类型必要的信息做反射,不像java或者C#,不管是什么类型,不管是信息,一些很明显就是无关紧要的临时的东西,,不管三七二十一,全部一股脑儿都反射起来。甚至,c++的反射,还能添加用户自定义的反射信息,甚至,还能运行时修改反射数据。这里,C#、java等,除了attribute或者注解,就别无他法了。反射的意义就在于,它提供了统一的接口,将类型信息全部集中存放在同一个地方,任何关于类型的运行时信息,全部被标准化公理化。有了完善的反射信息,c++里面做一个eval都手到擒来。说白了,反射就是静态类型语言里把“代码做成数据”的最重要机制(没有之一),虽然比之于lisp的“代码即数据”弱一些,但是已经可以应付99%以上的需求了。甚至可以说,c++的基础库迟迟未出现的原因就是因为反射的缺席而导致的(当然,没有合适的内存管理机制也是重要原因)。而可惜,stl对运行时这一块的关注,不到%1,这真是令人扼腕叹息至极。

2,stl的抽象缺陷:臆造抽象,过度抽象,抽象不足,想当然的抽象,大部分的精力都花在刀背上,或者说是很形式化的学术研究。
突然发现文章已经很长了,就先打住,以后有空再好好发挥。对了,cppblog人气太冷清,门可罗雀。再这样下去,本座只好转战知乎了。

posted on 2017-07-07 16:52 华夏之火 阅读(515) 评论(6)  编辑 收藏 引用 所属分类: c++技术探讨

评论

# re: 非完美的stl 2017-07-08 09:50 eryar

mark!
持续关注中……  回复  更多评论   

# re: 非完美的stl 2017-07-08 22:57 天下

文章写的很好,以前搞C++标准的那些人不接地气啊。
从C++ 11 开始,开始重视起来了,从C++17 module,,,,,以后会越来越好了。  回复  更多评论   

# re: 非完美的stl 2017-07-09 08:02 万连文

因为操作系统 api 没有标准化,所以语言也很难标准化。C++ 门槛高不符合现代主流开发模式,所以人就少了,话题也自然少了。不过转战知乎是为了凑热闹嘛?  回复  更多评论   

# re: 非完美的stl 2017-07-09 09:54 华夏之火

@天下
从c++17的提案上看,标准会对于stl的保守改进和迷糊认识,个人是彻底失望了。所幸的是,c++在大节上的进化还是可取的  回复  更多评论   

# re: 非完美的stl 2017-07-09 09:57 华夏之火

@万连文
系统api的标准化是客观原因,但是stl在二进制层面上的复用之难,真是令人发指。知乎c++板块上的人气比cppblog要更热闹。  回复  更多评论   

# re: 非完美的stl 2017-07-10 09:15 ccsdu2009

cppblog 09-11很热 现在确实不行了  回复  更多评论   


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


导航

统计

常用链接

留言簿(3)

随笔分类

随笔档案

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜