一、总论
STL提供了一组表示容器、迭代器、函数对象(没看懂,不会)和算法的模板。
- 容器是一个与数组类似的单元,可以存储若干个值。STL的容器是同质的,即存储的值的类型相同;
- 算法是完成特定任务的方法;
- 迭代器能够用来遍历容器的对象,与能够遍历数组的指针类似,是广义指针;
- 函数对象是类似于函数的对象,可以是类对象或函数指针(包括函数名,因为函数名被用作指针)。
STL是一种泛型编程(generic programming)模板使得算法独立于存储的数据类型,而迭代器使算法的独立于使用的容器类型。
首先,最重要最需要强调的是,排版是一个信息量极大的工程。字体,格式,对齐方式,页眉页脚,都只是排版的冰山一角,可以说,一个人是没有办法完全控制一个印刷文件里面的所有排版细节的,就好像人们可以挑选衣服的颜色,款式,但是人们却对“编织手法,扣子是材质”之类的问题疏于关注,这是因为这些细节没办法全部被考量,人类的大脑接受不了这么多的信息。
由此就衍生出了排版里面我最看重的一个概念,就是“缺省”。正是由于人们没有办法关注到每一个细节,所以对于用户没有办法关注到的细节,软件开发者就必须提供“默认设置”,也就是“缺省”。当然理想的缺省是没有任何问题的,人们可以随意修改自己关心的缺省设置为自己的设置,而对于自己不关心的设置就采用“默认设置”。
但是事实似乎并不是这样的,修改缺省设置并不是简简单单的,我曾经为了在word中将目录调成人能看的样子,查阅各种资料查了一个小时,最后手敲的目录。由此就引出了一个基本的问题:似乎缺省设置侵犯了用户排版的权利。而我评价一款排版编辑工具的好坏,最重要的就是看它在我看重的的设置中修改的难度。
当我们讨论芯片的性能的时候,我们到底在讨论什么?我觉得我们讨论的是理想的优秀。所谓的“高性能”,就跟“成功”一样,是一个绝对正确的概念,有人会说“有钱”好,有人会说“有钱”不好,有人会说“有媳妇”好,有人会说“有媳妇”不好,成功有很多的标准,但是作为最终目标的“成功”,是绝对褒义的,没有人会说“成功”是不好的。
“高性能”这个概念跟“成功”一样,没人会拒绝“高性能”。但是跟“成功”一样,每个人对“高性能”的定义是不一样。为了方便之后的整章对性能的理解,我们这里引入一个贯穿全篇的类比 — 一个饭店。一个饭店好不好,站在消费者的角度,出菜快就是好的,但是在掌柜的角度,出菜快只是一个方面,如果一个饭店只有一张桌子,一个厨子,哪怕这个厨子是厨神,做菜又快又好吃,饭店盈利状况也可能不好,毕竟厨子也是凡人,做菜再快一快不到哪里去,换句话说,这个饭店的客流量的上限是很小的,那么对于掌柜的来说,这个饭店就是不好的。
啰嗦了这么多,只是想说,对于“性能”评价,是一个很困难而且复杂的事情,是一个需要从多方面分析的事情。我们去做体系优化的时候,或许只能优化一个方面,或许优化这个方面会导致另一个方面的下降,就好比厨子应付一些,出菜速度会提高,但是菜品就不一定好吃了,所以根据需求的不同,优化的思路和方向就会不同。承认“性能”的不可度量性,就跟承认“成功”的不可度量性一样,是我认为比较成熟的标志。
这已经是我第三遍学Git相关操作了,可以说这个玩意是真的狗,因为确实用不到,不知道下个学期会不会用到,直到现在我刚刚学完,处于知识水平的巅峰,知道Git的具体功能,我也觉得真没啥必要学。我一开始学Git,是因为以为这个跟Github有啥关系似的,其实对于个人来说,使用Github完全没有必要学习Git。
这就引出了Git最重要的一个认识了,就是Git的基本上所有的功能都是为了团队协作开发的,而不是所谓的版本控制(当然也可能是,反正我理解的不是)。Github上面那些看似唬人的branch,tag,respository,ssh key,token之类的概念,其实都是为了团队协作设计的,而不是为了版本控制,或者其他啥目的,简而言之,就是与我现在的需求无关。
对于Git的学习,大致分为两个部分,即版本控制和团队协作。之后会详细介绍。