读《C++ Primer》的点儿心得

 

 

想写点《 C++ Primer 》的学习心得。 心得不同于笔记，笔记往往较为详细，并设计到具体的一些实现知识点。而心得主要指自己思考后的所得，侧重于对语言整体的理解。心得分两部分：先“纠正”自己的一点儿错误的认识【加引号是因为自己纠正过的不一定就是正确的】； 再简略说说自己对面向对象的一点理解。 作为笔记分享出来，当然是希望能够与大家共同交流。自身水平目前仅在这个层，闻道有先后，呵呵。如果路过的朋友有话想说，还望不吝赐教。

 

一点儿认识：

 

1 ）旧版

基于以前微薄的基础，我觉得一门语言【注：此处指计算机程序设计语言】应该有着自身的语法和应用体系，以与其他的语言之间互相区别。以为这门语言既然诞生了，那么就意味着现实中已经对它存在着足量的需求，并且它所拥有的特性也是满足这些需求的。而一门已经存在的语言能够经过改进以适应这些新的需求，那么它便不会更名易帜。所以在声明用门语言来开发相关的应用的时候应该仅使用这门语言相关的东西即可，不应该互相掺和【混合编程不在此范围】。 这里绕了一个弯，其实我想说的是 C 和 C++ 。 因为看过一些 C++ 的程序【可能还不够多，不过够说明我想要说明的东西了】，但我常常在这 C++ 工程的代码中发现很多 C 中的库函数、结构体的使用。在我看来，既然 C++ 是一门新的语言，那么用 C++ 时就应该用 C++ 中的那些东西；既然 C++ 如此强调类的使用， 那么 C 中的结构体的使用就应该尽可能的避免而使用类来进行设计。

最近因为要用 C++ 写几段小程序，所以我一直很刻意：在设计到数据结构的定义、函数库的使用的时候，就全部使用 C++ 中的相关 resource 。所以在设计数据结构时便不考虑 C 中常用的结构体，在用文件读取等操作时全用 C++ 中的相关类。其中发现两个问题，一是程序不够灵活，在进行大量数据运算时觉得会影响效率，因为其数据往往存储在类中，那么对类的访问必然会增加额外的时间开销【这里要 throw 一个问题：怎么去衡量段代码的效率，比如用类和用结构体相比（猜测用类肯定更为耗时，但如何证明呢？） 】。二是程序不可避免的要使用到一些数学库，而一些常用的数学函数库在 C 的标准库中已存在，所以要用到它们。这就迫使自己去检测自己的认识， 是不是真的是自己所想的那样 ？

 

2） 更新版

在查阅资料时， C++ Reference  对库的分类对我有了点儿新的启示。其中， 对 C++ 库的分类有如下关系：

 

      C++ 库 = C 库 + C++ 标准库

      C++ 标准库 = 输入输出库 + STL + 其他少数几个库

 

即 C 中的标准函数库也是 C++ 的一部分，所以之前的想法是错的。那么为什么会那样用呢，一个原因可能是因为一些 C 中的库的使用看起来依然是不可避免的（数学库）。 二个原因可能是在 C 与 C++ 中交集部分进行选用时，可以偏重更为效率的使用方式， 如文件的读取， 用 C 中的文件读取函数与 C++ 中的文件读取类进行比较，谁快？ 另外一个原因可能是因为习惯问题。之前虽然听说 C++ 是高级版的 C ，但那也只把重心偏移到“高级”二字，而没有同等的看待其中的“ C ”，它们之间的关系没怎么分清楚，只知道有差别，不知道差在哪里，联系又在哪些地方。所以感觉是没有这次来得深的。

 

一点儿理解：

 

     面向对象的流行主要在于一种合乎人们思考习惯的思维方法。面向对象的世界主要是由各种对象组成的，这里说是由各种对象而没说各种类主要是基于我们通常只是对这个世界中的对象感兴趣。这个世界上的各种活动主要【是主要，想象下类的静态成员】是通过对这些对象的操作（访问、相互之间的交互）来完成的。而其中的类看上去只是一些抽象的实体，实际上极少参与活动。

     在进行需求分析时，我们往往会先从某个对象开始分析，我们需要它哪些功能，即需要提供哪些接口，又需要哪些属性【对象的形成】。向上进行抽象，如果有多个对象，那么能否抽象出它们共同的部分然后再进行派生呢【类的形成】。如果可以，继续向上进行抽象，看能否得到各种类之间的相似部分【类模板】… 从而构成一个类的体系。

 

1 ） 类

     书中有这么一段话：

“

     Classes are the most important feature in C++. Early versions of the language were named "C with Classes," emphasizing the central role of the class facility. As the language evolved, support for building classes increased. A primary goal of the language design has been to provide features that allow programmers to define their own types that are as easy and intuitive to use as the built-in types. This chapter presents many of the basic features of classes.

”

     我们在使用一些整形、浮点型进行运算的时候感觉很直观，这些类型的一些计算属性是我们非常熟悉的。那么在定义出新的数据结构的时候，能不能让它们也具有相类似的属性，让这些新的数据结构本身及其它们之间的关系也变得这么容易呢。这是一个很好的注意，所以 C++ 便提供了这些特性，让我们可以定义一些我们需要的类，并对其进行封装、接口设计来达到我们任性的要求。而面向对象中的“抽象”属性【继承、泛型】往往能够让一个大型整个工程的结构变得更清晰，实现起来更效率。

     可窥知，面向对象的程序设计主要为减轻程序设计负担，让程序员从繁杂的数据和逻辑中脱离出来。其中很重要的一点是其代码的可重用好，不难明白，在进行 GUI 开发的时候通常都是基于一些面向对象的设计。

 

2 ） 异常处理机制

 

     这些天读了一些程序，发现程序中极少使用 C++ 的异常处理机制，是因为效率原因还是因为程序员习惯的疏漏？当然，可能因为我看的这些程序仅是一些非商业化的程序，比如程序只用来当教程或者演示基本功能使用，可以不用考虑高可靠性。对于一些初级教程这是可以理解的，毕竟如果开始便加入这些东西只会增加其理解难度。而对于一些已经作为一个微型工程在进行构建的代码，我更愿意把它看作一种习惯式的编程风格，也即，好的编程风格应该考虑到这些异常。粗略看起来，使用异常处理机制往往很繁琐，因为首先要考虑到尽可能多的异常情况，然后再添加相应的处理代码。 其实，用好异常处理机制往往能够使程序在具有高可靠性的同时，还能够缩减一些重复的判断代码。比如， 在一段代码块中，你可能对针对多处具有明显异常的地方分别进行处理，但用异常捕获机制先对这些异常进行分类，再分别针对各种类型的异常对象进行处理。

 

3） 命名空间

     又一个优化程序管理，提升开发效率的特性。 不多说了， 书看了就能懂，懂了就能用；不用的话看了也没用，懂了也会易忘掉。并且一般在比较大的工程中才能用到。

 

本笔记的几句话

也没说多少东西， 只是自己突然感觉更新的认识，一时激动，想写出来。自己也在想，要不要等把所有的章节看完后再写。不过基于两点考虑，还是觉得先写下来好，即使写得不是很对。一是一本书往往比较多，看完要花费一些时日，周期偏长。这对一部分人来说往往是件挺奢侈的事情。二是在看的过程中如果太注重是否“看完”往往会忽略掉看书过程当中的一些小的问题，有时候你即使记下这些问题，等看完之后来整理往往没有了当初那个劲头而不能很好的完成。这就像有时候我们突然很想做一件事情，但因为一些习惯而拖到之后再去完成，等到之后时，要么没有了当初那个热情而放弃，要么再之后直到没有下文。   

所以，自己觉得。对于一本书不论看了多少，如果觉得有了点感觉，那么就应该写下来，这样有所思考的学， 感觉会好一些。

 

更新（2010.7.29）：

【类】
 　 经朋友（感谢小唐）提醒， 在“类”中这一部分有个概念有误，即我将泛型归划到面向对象的范畴。面向对象和泛型其实只是两个东西，面向对象侧重数据抽象，定义不同的数据类型。而泛型侧重念抽象，将一些算法泛化到各种泛型容器上。在这里（即C++中）STL即是泛型的一种实现，里面定义的一些容器能够很好的使用泛型算法。更为详细的文章可以参见这里。

【异常处理机制】
      关于C++中异常处理的一点儿讨论可参加这里，如果觉得帖子比较长可以参加这里详细的机制分析。

【本笔记的几句话】
      当然，不仅仅该写下来，还应该有勇气分享出来。这样便可和朋友们进行一些讨论或者争论，也会有不小的收获。

更新（2010.8.13）：

【异常处理机制】

    有关异常处理与错误处理的比较，见这里。基于一些主观原因，目前这些都是支持异常处理的，但这并不表示它一定就是完美的。