语不惊人死不休

withparadox2

坦白地说,如果你正在和告诉你使用v.begin()代替&v[0]的人打交道的话,你该重新考虑一下你的社交圈了

并且,如果被调用的函数试图在一个大小和容量(参见条款14)相等的vector上追加数据的话,真的会发生灾难性事件。我甚至根本就不愿去想象它,实在太可怕了

表达式!c.key_comp()(x, y)看起来很丑陋,但一旦你知道c.key_comp()返回一个函数(或一个函数对象),丑陋就消散了

你可能会奇怪为什么标准关联容器是基于等价而不是相等。毕竟,大多数程序员对相等有感觉而缺乏等价的感觉。(如果不是这样,那就不需要本条款了)。答案乍看起来很简单,但你看得越近,就会发现越多问题。

! 这就是这个条款!

嗯,如果你使用一个const_cast,正如我们将在下面看到的,你或许能改变它。不管相信与否,有时那是你想要做的。

显示全文

坦白地说,如果你正在和告诉你使用v.begin()代替&v[0]的人打交道的话,你该重新考虑一下你的社交圈了

并且,如果被调用的函数试图在一个大小和容量(参见条款14)相等的vector上追加数据的话,真的会发生灾难性事件。我甚至根本就不愿去想象它,实在太可怕了

表达式!c.key_comp()(x, y)看起来很丑陋,但一旦你知道c.key_comp()返回一个函数(或一个函数对象),丑陋就消散了

你可能会奇怪为什么标准关联容器是基于等价而不是相等。毕竟,大多数程序员对相等有感觉而缺乏等价的感觉。(如果不是这样,那就不需要本条款了)。答案乍看起来很简单,但你看得越近,就会发现越多问题。

! 这就是这个条款!

嗯,如果你使用一个const_cast,正如我们将在下面看到的,你或许能改变它。不管相信与否,有时那是你想要做的。

我们先得会爬,然后才能在碎玻璃上爬。

坦率地说,我认为它可以。不过,由于同样的坦率,我怎么认为是不重要的,重要的是标准委员会怎么认为, 而它认为的是map/multimap键应该是const而set/multiset的值不是。

除了碎玻璃以外。记得我早先提及的碎玻璃吗?我们现在在那里了。抓一些绷带跟我来

我知道你在想什么。你正在想,“每当无路可走的时候,就举起大锤!”。 在C++的世界里,你的意思只能是:映射。这种想法很可耻。真不知道你是哪儿学来的。

我讨厌为你做这些,但我们必须从一个简短的词汇课开始 :

就这些了,我保证

这些东西是STL古董的附加例子(正如在条款10和18中描述的那样),或者只是一些标准委员会的成员因为太闲扭曲的幽默感而强加给我们的语法玩笑。

可能出现的最坏的情况就是一些读你代码的人当看见不必要的ptr_fun使用时,可能会扬起眉毛。我认为,那有多让你操心依赖于你对扬起眉毛的敏感性

除了最微不足道的STL算法,所有的STL算法使用的计算机科学都比一般的C++程序员能拿得出来的算法复杂——有时候会复杂得多。

如果这不是你想要的(还是承认吧,它肯定不是) 。

运气好的话,你现在已是一个算法的信徒了。然而运气是变化无常的,在我休息前,我想更确定些。因此,让我们继续行进到代码清晰性的议题。

可能因为编译器厂商从来没有觉得值得实现这个优化。你得稍微同情一下编译器厂商。他们有很多需求,而他们不能做每一件事。你的需要并不能让他们实现那个优化 。

“不!”大部分C++程序员惊叫,他们的声音中充满了害怕和讨厌。“是!”他们中的一部分显然高兴地说。但那儿有一个问题。一个程序员很有表现力的方法是另一个程序员的噩梦

是不是很奇妙?消息的第一部分看起来像一只猫走过键盘,第二部分神秘地提到了一个从未在源代码中涉及的分配器,第三部分说构造函数调用是错的。

正如你所猜测的,错误信息以外的特性是造成我喜爱它的原因。 (注:错误信息太多)

写过的(但我希望我没有)。 (注:作者书的勘误表)

:-)

0
0

查看更多豆瓣高分好书

回应(0)

添加回应

Effective STL中文版的更多书评

推荐Effective STL中文版的豆列

了解更多图书信息

值得一读

    豆瓣
    我们的精神角落
    免费下载 iOS / Android 版客户端