VB+ACCESS交通法规模拟考试系统-读书笔记

1毕业设计之读书笔记 -Visual C+读与感Vc 软件的实用性使得它能够在市场上迅速流行并得到用户的喜爱和认可,该软件功能强大,简单易学,用户可根据它设计和开发功能强大的应用程序.软件实用的另一方面,体现在每个都是结合著者的实际开发经验来进行的,能给用户带来最实用的开发技巧,经验等.本书没有高深的理论描述,而用深入浅出的讲解和简短使用的例子,帮助我们循序渐进的掌握软件最精髓的内容,使我们能够重点掌握,消化吸收,学会开发大型应用程序的方法,下面详细谈谈 VC+6.0 一些特点和应用及感受:VC+6.0 是微软可视化编程套件 Visual Studio(下面简称 vs)98 中的重要组成部分,这套功能强大的应用程序开发系统是由 microsoftc/c+演化而来的,从 Microsiftc/c+8.0 开始改称Visual c+,发展到今天的 Visual c+6.0 .该系统采用的 32 位编程方式,也就是说其生成的程序是运行在像 windows95 这样的 32 位操作系统下通过硬件平台编程,其程序还可以运行在像 Alpha、Macintosh 等非 Intel 平台上。Windows 编程采取面向对象编程方法 ,要编写真正的 Windows 应用程序,就必须对 OOP有一定的了解。学习 OOP 编程方法，有利于了解 Visual C+的基础。MFC 提供了一套强有力的 C+类，从而能更快地学习使用 MFC 编程。要学习 vc+，我们当然就要涉及面向对象，而面向对象程序设计并不是新事物，只不过人们渐渐认识它是从 C+开始的。面向对象程序设计语言的鼻祖是 Smalltalk 语言，这种语言产生于 70 年代，但并未流行起来。只到近来，随着新的计算机语言的发展而发展起来。在现实生活中，人们对客观事物不同方面的性质各有兴趣。一个组装计算机的人可能只对 CPU、板卡和外部设备的质量、功能感兴趣，而他对这些物品的制造过程不感兴趣，可能对其中涉及到的集成电路更不感性趣。在软件设计中也是这样，程序员对模块和函数的输入、输出变量以及提供的服务更感性趣，而对模块内部的功能实现并不关心。这就要求模块和函数具有“黑盒”性质，即将模块内部复杂的实现过程包装起来。这样既简化了应用，又保护了模块的私有数据。可惜的是在过程式编程的方法下，实现“黑盒”比较困难。程序代码的重复使用也是比较难的，特别是程序结构越复杂，程序越大， “黑盒”思想的实现就越复杂。面向对象的技术正能解决上述问题。在面向对象技术中， “对象”的概念最重要，然而又是最难准确描述的。对象可以理解为待研究的客观事物的软件模型。客观事物的模型可以因为研究的侧重点不同而不同。总的来说客观事物可以抽象成特性加上行为、功能。 面向对象的程序设计方法使程序更容易设计。这还要归功于在面向对象的程序设计中，类具有封装性、继承性和多态性。在大型程序中，面对对象的代码更安全，可重用性更强。在应用过程中，难点常常不在面向对象程序设计语言本身，而在于如何建立类中的函数与变量，正确反映客观事物的内在运行机制。一旦类的模型建立，后续工作就再也不必为此进行重复劳动。构造函数中有着比我们所见的还要多的细节。除了程序员所编写的代码之外，构造函数还可以调用其他的构造函数来初始化对象中的基类对象和数据成员。即使程序中并没有明确的调用，编译器也可以向代码中插入构造函数的调用代码。在某些情况下，即使有新对象被创建时，由于某些特殊的操作缘故，我们也不能使用缺省的复制构造函数。假设我们用它来表示一个文件描述符。有些应用程序可能需要知道在某个给定的时间内到底存在着多少个 File 的对象。我们可以很容易做到这一点：只要让 File 维护一个当前存在的 File对象个数计数器就可以了。在 File 的构造函数中我们会对这个计数器进行递增，在析构函2数中对计数器则是递减。缺省情况下，在构造函数的函数体被执行前，对象中的所有成员都已经被它们的缺省构造函数所初始化。那些没有构造函数的成员则将拥有一个未定义的初始值。编译器忽略掉构造函数中的初始顺序这个现象看起来好象有违我们的直觉，但这却是VC+要求“对象的析构过程必须和其创建过程相反”得到的结果。如果构造函数中指定了一个特殊的构造顺序，那么析构函数将不得不去查询构造函数的定义，以获得如何对成员进行的顺序。由于构造函数和析构函数可以在不同的文件中定义，这就将给编译器的实现者造成一个难题。更糟糕的是，一个类可以有两个或者更多的构造函数，对于这些构造函数的定义，我们并不能保证它们中的成员出现的实现都是一致的。然而我们可以确保类的声明在所有的文件中都有效，并且不同的文件中出现的声明都是一致的；所以我们使用类的声明来解决成员的构造和析构顺序。依照 C+的语言规则来说，类的面向用户的接口包括它的公有成员；面向派生类的接口则同时包括它的公有和保护型成员。由类所提供的抽象模型要比它成员的类型签名和存取类型都重要。一个不能提供让人容易理解并详细记录的抽象模型的类用途也不会太大。一个被设计为不能被继承的类同样也可以向其用户提供一个很好的抽象模型，但它向其派生类所展示的抽象模型则是完全随机构造的！这个随机接口的可用性通常都很小。应该强调的是，我们在此所谈论的是如何设计一个将要被其他拿去当作基类使用的类。很显然，如果我们是要被卖出去的类库的所有者，那么我们就可以通过修改相应的基类来修正我们可能碰到的所有问题。在这种情况下，对不恰当的继承的担心在此没有意义。问题只出在用户对于需要被修改的类没有所有权的时候。使用模板可以使程序员避免设计大量的功能类似的新类，但对于编译器来说则没有得到任何好处。对于大程序来说，编译器在实例化模板时所耗费的时间相当可观。我们期望某些通用的容器可以在一个程序中被多次实例化。当设计这样的摸板时，我们应该尽量将那些和参数类型无关的代码放到一个单独的地方，这样的话，该模板的多份实例就可以共享唯一的一份这样的代码。这样做可以避免编译器在每次实例化时都编译同样一份代码，程序的大小也会因为少掉的多分代码而得到精简。找到这种代码的最好机会就是那些处理不清楚自己所指向的指针的操作。我们通常都可以使用 void*来实现这些操作。所有处理 void*代码都被共享，它们的返回值会被模板类中其他的逻辑转换为真正适合它们的类型。按照 VC+中的规则来说，在模板中有一个或多个成员函数都还没有被实例化时，我们也可以用该模板前提是那些没有被实例化的函数没有被程序所使用。对于这个规则有两点要注意：首先，所有在模板类中声明的虚函数都被视为“被调用” ；如果我们使用了某个模板类，那么它里面所有的虚函数都必须被正确的实例化。其次，某些编译器实现行规实例化模板类中所有的成员函数，而不仅仅是那些被使用的成员；如果我们正在使用的正是这样的编译器，对于那些不能被正确编译的成员，无论是否使用了它们，我们都会得到一个实例化错误信息。C+成功的原因之一也“继承”自 C：C+程序运行速度很快。这并不意味着所有的VC+程序都已经运行得足够快了。很多通常使得 C 程序运行得更快的技巧也适用于VC+，如：明智地选择使用寄存器变量，以及使用指针而不是数组下标。如果我们检查一段关键的代码，它里面的每行语句都已经被最大程度地优化时，我们就很容易发现这一点。然而，随着程序员对于数据抽象的使用技巧提高，他们开始在一个较高的层次上面进行编程。这使得单个的程序员可以完成比以前要多得多的功能；但这也意味着，除非某些关键的代码段，他们也变得不再去关心每行程序间的性能问题了。相反的是，程序远将会3在一个更高的层次上来关注优化这个问题。当面对性能时，数据抽象就是一柄双刃剑。当库的实现对用户来说是可见时，用户就可以得知哪些操作开销比较小，哪些开销比较大。如果我们对数据的抽象实现得很好的话，那么对于用户来说实现就不再是可见的，他们也就不可能会对某个操作的开销有着很好的了解除非我们告诉他们结果。如果我们是库的提供商，我们就应该将库中函数的性能复杂度记录到文档中去。这样用户就可以用这些信息来计算他们应用程序的性能复杂度。是的，这样做可以使得我们的实现的某方面对用户来讲是可见的；但我们无法避免这点。对于库来说，它的性能特性对用户来说总是“可见”的，以使得用户知道他们的程序需要运行多久。将我们的性能特性记录下来可以帮助我们的用户算出他们自己的程序的性能特性。经过对 VC+的进一步学习与研究，我对其发展历史和优越的性能有了进一步的认识。由于 VC+提出了把数据和在数据之上的操作封装在一起的类、对象和方法的机制，并通过派生、继承、重载和多态性等特征，实现了人们期待已久的软件复用和程序自动生成功能。这使得软件，特别是大型复杂软件的构造和维护变得更加有效率和容易，并使软件开发能更自然的反映事物的本质，从而大大提高了软件的开发效率和质量。但在认识中还存在很多不足之处，主要原因是自己的水平有限，不能在短时间内领会编者的思想的精髓，只得到一些粗浅的看法，但对我的启发却是很大的，一是，发现自己走过的脚印是那样的粗浅，方向还比较模糊，并总结了之所以这样的原因；二是，通过这个平台，我看到了更远的路待我去跋涉，去探索，也许不能蹬上山之颠，但