《C++的设计与演化》读书笔记
<<C++的设计与演化>>原文摘录与自己翻译及注解
原文1：
1.Even though support of concurrency and Simula-style simulations was a primary aim of C with Classes,the language contained no primitives for expressing concurrency;................
I considered it crucial--as I still do-- that more than one notion of concurrency should be expressible in the language.There are many applications for which support for concurrency is essential,but there is no one dominant model for concurrency support;thus,when support is needed,it should be provided through a library or a special-purpose extension so that a particular form of concurrency support does not preclude other forms.
虽然设计带类的C最初的目的是支持并发和模仿Simula的风格,但是带C的类中并没有包含实现并发的原语支持.我觉得这样的种观念是至关重要的(我现在仍然这样认为):在语言中应该支持多种并发性的概念.支持并发性对许多应用来说是必不可少的,但是在语言中并没有提供一种占主导的并发支持.我们应该通过提供一个类库或者特定的扩充来支持某种并发,这样的话对一种特殊形式的并发的支持才不会导致排斥其他形式的并发.
注解:
C++刚出来的时候叫作带类的C,它设计之初并不是想弄成一个全新的语言,而只要想当作一个扩充C的功能的辅助工具.但是在带类的C中的一些设计思想继续延续到了C++中.上面多次提到了并发,我觉得现在使用的多线程应该就算是一种并发吧.随着多核处理器的普及,并发会成为越来越重要的个概念.以前的多线程并发在一个CPU上只是假象,实际上是通过分割CPU时间片断来模拟了并发.而在多核中有个多个CPU,那就是真正的并发了啊.
上面讲到C++中没有对并发的原语支持,啥叫原语支持?可以这样的简单理解吧.像C中没有某个类型叫字符串,而是通过char数组来模拟字符串,所以可以说C中没有字符串的原语支持.而C#中有string这样的基本类型了,就是原语支持.
其实提不提供对某个特定功能的原语支持是有好处也有坏处的.如果你的语言是作为一种通用的程序语言,想要适用于尽量多的领域,就要少做一些原语的支持.而如果只想针对某个特定领域就要提供该领域的很多原语性支持.比如Matlab对数学方面提供了非常多的原语支持.可以很方便的使用矩阵之类的啊.所以如果要做个数学研究方面的开发工作用matlab就绝对比C,C++这样的语言更有优势了啊.另外Lisp也一样,设计之初重点关注人工智能,所以在人工智能领域相较其他语言也有得天独厚的优势.
另外stroustrup还提到了如果想实现某种形式的并发要用类库来支持.所以很多时候我们要实现一些功能,类库也是挺重要的,类库帮我们做了很多工作,我们只要拿来用就行.所以选择一门程序语言时,除了语言本身设计的好不好,编译器好不好外,还得看有没有很多关于该语言的第三方类库.
原文2：
2.C with Classes could be used for whatever C could be used for.This implied that in addition to matching C in efficiency ,C with Classes could not provide benefits at the expense of removing "dangerous" or "ugly" features of C...........
带类的C应该能适用于C适用的所有领域.这意味着带类的C要取得跟C差不多的效率,不能去掉C中一些"危险的" 或者"丑陋的"特性,因为去掉这些特性会带来性能损失.
注解:
我们看到C++差不多把C中所有特性都保留下来了.关于上面提到的哪些特性算是C中的"危险的"或者"丑陋的"呢?我觉得允许各种数值类型可以隐式的互相转换就算一个.比如unsigned int,long,float,double之前都可以任意的隐式互相转换.做这样的转换带来的结果有时只是精度的不同,而如果存在带符号和不带符号的话可能是完全错误的结果.实际上是可以在运行时做一些检查,如果转换存在精度的损失和出错的可能就当作错误处理.这样做虽然安全很多了,但做多余的检查肯定会导致损耗一定的空间和时间效率.所以C++在数值类型检查这一块没做啥改进.而C#中关于数值类型转换就有做检查了.会出现精度损失时就不让隐式转换.
所以我们使用一些高级语言时,看起来有些地方安全了,方便了.但实际上往往是以牺牲一部分效率为代价的.随着电脑硬件资源越来越廉价,有些时候这样的性能代价是可以承担的.但出于通用性的考虑,就不能承受这样的代价.比如要用到资源紧缺的嵌入式上的话.
原文3：
3.In C with Classes(as in C++) ,a class is a type.This is a key notion in C++.When class means user_defined type in C++,why didn't I call it type? I chose class primarily because i dislike inventing new terminology and found Simula's quite adequate in most cases.
在带类的C中(在C++中也一样),一个class就是一种type.这是C++中的一个关键性的概念.那既然在C++中class是用户自定义的type,为什么不直接把class叫作type呢?我之所以选择class做为关键字最主要的原因一个是我讨厌发明新术语,二是我发现Simula中的class在用在绝大部分情景中是适合的.
注解:
在Simula语言中class已经被做为关键字了,而我们平时虽然常提到type,但它实际上没做为关键字用了.stroustrup讲他没有把type引进来做关键字是因为他不想发明新术语.我觉得这样的思想是一种比较务实的,很替用户考虑的.人总是爱偷懒的,能少记些东西就想少记.而且对一些完全陌生的事务带有排斥心理(当然实际上人心理是复杂的,对陌生事物是排斥心理和好奇,接近心理并存). 所以很多学C++的人刚接触MFC,碰到一堆堆的陌生关键字和术语时会极度反感.可能接触久了才会慢慢习惯. 另外我们会发现讲一些比较专业性的东西时,水平不高的人往往是满口让人难懂的术语.而那些易做图级的人才能做到深入浅出,不用晦涩难懂的术语,而只用些通俗易懂的话语就能讲明白.
补充：软件开发 , C++ ,
