lostmouse-CSDN博客

原创 More Exceptional C++中文版试读（泛型程序设计与C++标准库）

[Herb Sutter 的名作More Exceptional C++中文版即将出版。作为本书译者，我很高兴将本书推荐给大家。征得华中科技大学出版社同意，我将公开部分译稿，敬请大家批评指正。] 泛型程序设计与C++标准库 C++威力强大的特性之一是对泛型程序设计（generic programming）的支持。这种威力直接反映在C++标准库的灵活性上，特

2002-05-08 18:55:00 1873

原创 More Exceptional C++中文版试读（优化与性能）

[Herb Sutter 的名作More Exceptional C++中文版即将出版。作为本书译者，我很高兴将本书推荐给大家。征得华中科技大学出版社同意，我将公开部分译稿，敬请大家批评指正。] 优化与性能对程序员来说，效率总是很重要。在C和C++的传统中，效率是重要支柱之一，“不要为没有使用的东西支付任何成本”这一指导原则——也称为零成本原则——总是语言设计和程序库

2002-05-08 14:55:00 1369

原创 More Exceptional C++中文版试读（异常安全议题及技术）

[Herb Sutter 的名作More Exceptional C++中文版即将出版。作为本书译者，我很高兴将本书推荐给大家。征得华中科技大学出版社同意，我将公开部分译稿，敬请大家批评指正。] 异常安全议题及技术在现代C++程序设计中，对异常安全（exception safety）议题一无所知却想写出健壮的代码，这无异于痴人说梦。的确如此。

2002-05-08 14:55:00 1456

原创 More Exceptional C++中文版试读（继承与多态）

[Herb Sutter 的名作More Exceptional C++中文版即将出版。作为本书译者，我很高兴将本书推荐给大家。征得华中科技大学出版社同意，我将公开部分译稿，敬请大家批评指正。] 继承与多态不来点继承和多态，面向对象将会怎样？尽管继承常被滥用，但它还是一种很重要的工具——这包括多继承。特别是，当你生活在现实世界中时，你会发现，

2002-05-08 14:55:00 1745

原创 More Exceptional C++ 中文版试读（译序及目录）

[Herb Sutter 的名作More Exceptional C++中文版即将出版。作为本书译者，我很高兴将本书推荐给大家。征得华中科技大学出版社同意，我将公开部分译稿，敬请大家批评指正。] 与大师面对面（译序）小提琴家穆特录制过一张唱片，收录的是贝多芬最伟大的两部小提琴作品1。聆听那张唱片，你仿佛听见贝多芬在向你倾诉他对音乐艺术的理解和感悟、为你解答小提琴音乐创作

2002-05-08 10:26:00 1644

原创基于DirectDraw的Gamma calibrator机制之探讨

基于DirectDraw的Gamma calibrator机制之探讨一.问题的提出Gamma calibrator基于动态gamma ramp技术。为系统提供动态gamma ramp支持，基于以下应用的需要：1. 游戏程序的设计者可以为用户提供一致的视觉效果，而不论用户使用什么系统。2. 随着电子商务的迅猛发展，商家和用户都迫切需要在Internet上看到货物样品的真实色彩。3. 谁都希望

2001-11-19 16:04:00 1379

原创 Java Tip: 实现Command模式

Java Tip: 实现Command模式概述有时需要向对象发送请求，但是不知道 "被请求的操作" 或 "请求的接受者" 的任何信息。在面向过程的程序设计语言中，这类通信是通过回调函数来完成的：在某个地方登记这个函数，然后在后面调用它。在面向对象程序中，command(命令)与回调函数等价，它封装了回调函数。本文演示如何在Java中实现Command模式。--------------

2001-09-25 13:04:00 1851 1

原创 Java Q&A: 使用Singleton模式？给我一个理由先！

Java Q&A: 使用Singleton模式？给我一个理由先！Q: 在很多地方我都看到使用了Singleton类。我的问题是：较之一个包含static方法(methds)的类，使用Singleton具有什么优点呢？A: 不使用包含static方法的类而使用Singleton，其区别在于，后者可以带来有效的面向对象设计。Singleton通常展示的是一种更清晰的方法。而一个包含static

2001-09-23 15:34:00 1195

原创 Java Q&A: 使用Factory Method模式

Java Q&A: 使用Factory Method模式Q: 阅读 "Polymorphism in its purest form" 一文时，我看到了一个不熟悉的术语 "Factory method"。你能解释一下什么是Factory method并说明如何使用它吗？A: Factory method(工厂方法)只不过是实例化对象的一种方法的名称。就象工厂一样，Factory metho

2001-09-14 13:05:00 1045

原创 Java Tip: 用Reflection实现Visitor模式

Java Tip: 用Reflection实现Visitor模式概述Visitor模式的常用之处在于，它将对象集合的结构和对集合所执行的操作分离开来。例如，它可以将一个编译器中的分析逻辑和代码生成逻辑分离开来。有了这样的分离，想使用不同的代码生成器就会很容易。更大的好处还有，其它一些公用程序，如lint，可以在使用分析逻辑的同时免受代码生成逻辑之累。不幸的是，向集合中增加新的对象往往需要修

2001-09-13 19:48:00 1294

原创 Java Q&A: 使用Observer模式

Java Q&A: 使用Observer模式A：我想在自己的Java程序中使用Observer模式。基于此，能否提供某些示例代码来演示如何去做？Q：正如面向对象编程有助于代码复用一样，设计模式可以促进设计复用。确实，设计模式可以让你复用那些正确的、成熟的设计。但近来，批评设计模式的声音越来越多。批评者指出，缺乏经验的开发者会很容易地掉进 "模式陷阱" 之中。模式陷阱让缺乏经验的开发者迷

2001-09-10 18:41:00 1117

原创 Java Q&A: 抽象类和接口 - 实战练习

Java Q&A: 抽象类和接口- 实战练习在Java中，什么时候该用抽象类，什么时候该用接口？下面的文章将通过实例，而不是从理论的角度给你一个清晰的回答，让你有可能获得醍醐灌顶般的彻悟。以下是原文翻译。----------------------------------------------------针对2001年4月的 "抽象类和接口" 一文，读者给予了积极的反馈。其

2001-09-09 12:30:00 1630

原创 CUJ C++ Experts Forum: conversation (September 2001)

Conversations: Back to Base-icsCUJ C++ Experts Forum: conversation (September 2001)和往常一样，我又在为一个按说应该很简单的设计问题大伤脑筋。可能是劳工节假期刚过还没来得及收心吧，我感觉自己有点迷迷糊糊的。Wendy刚开始休产假，我的靠山也没了。其实任务只不过是要在一个工程中引入一个新类而已。我已经有一

2001-08-18 21:32:00 1618 1

原创 Effective C++ 2e Item50

条款50: 提高对C++的认识C++中有很多 "东西"：C，重载，面向对象，模板，例外，名字空间。这么多东西，有时让人感到不知所措。怎么弄懂所有这些东西呢？C++之所以发展到现在这个样子，在于它有自己的设计目标。理解了这些设计目标，就不难弄懂所有这些东西了。C++最首要的目标在于：· 和C的兼容性。很多很多C还存在，很多很多C程序员还存在。C++利用了这一基础，并建立在 ---- 我是

2001-08-10 20:23:00 1260

原创 Effective C++ 2e Item49

条款49: 熟悉标准库C++标准库很大。非常大。难以置信的大。怎么个大法？这么说吧：在C++标准中，关于标准库的规格说明占了密密麻麻300多页，这还不包括标准C库，后者只是 "作为参考"（老实说，原文就是用的这个词）包含在C++库中。当然，并非总是越大越好，但在现在的情况下，确实越大越好，因为大的库会包含大量的功能。标准库中的功能越多，开发自己的应用程序时能借助的功能就越多。C++库并非提

2001-08-09 22:32:00 1204

原创 Effective C++ 2e Item48

条款48: 重视编译器警告很多程序员日常总是不理睬编译器警告。毕竟，如果问题很严重，就会是个错误，不是吗？这种想法在其它语言中相对来说没什么害处，但在C++中，可以肯定的一点是，编译器的设计者肯定比你更清楚到底发生了什么。例如，大家可能都犯过这个错误：class B {public: virtual void f() const;};class D: public B {public

2001-08-08 20:46:00 969

原创 Effective C++ 2e Item47

条款47: 确保非局部静态对象在使用前被初始化大家都是成年人了，所以用不着我来告诉你们：使用未被初始化的对象无异于蛮干。事实上，关于这个问题的整个想法会让你觉得可笑；构造函数可以确保对象在创建时被初始化，难道不是这样吗？唔，是，也不是。在某个特定的被编译单元（即，源文件）中，可能一切都不成问题；但如果在某个被编译单元中，一个对象的初始化要依赖于另一个被编译单元中的另一个对象的值，并且这第二

2001-08-08 20:45:00 1170

原创 Effective C++ 2e Item46

条款46: 宁可编译和链接时出错，也不要运行时出错除了极少数情况下会使C++抛出异常（例如，内存耗尽 ---- 见条款7）外，运行时错误的概念和C++没什么关系，就象在C中一样。没有下溢，上溢，除零检查；没有数组越界检查，等等。一旦程序通过了编译和链接，你就得靠自己了 ---- 一切后果自负。这很象跳伞运动，一些人从中找到了刺激，另一些人则吓得摔成了残废。这一思想背后的动机当然在于效率：没有运

2001-08-07 21:00:00 1016

原创 Effective C++ 2e Item45

杂项进行高效的C++程序设计有很多准则，其中有一些很难归类。本章就是专门为这些准则而安排的。不要因此而小看了它们的重要性。要想写出高效的软件，就必须知道：编译器在背后为你（给你?）做了些什么，怎样保证非局部的静态对象在被使用前已经被初始化，能从标准库得到些什么，从何处着手深入理解语言底层的设计思想。本书最后的这个章节，我将详细说明这些问题，甚至更多其它问题。条款45: 弄清C++在幕后为你

2001-08-06 19:17:00 1039

原创 Effective C++ 2e Item44

条款44: 说你想说的；理解你所说的在本章关于 "继承和面向对象设计" 的简介中，我曾强调，理解不同的面向对象构件在C++中的含义十分重要。这和仅仅知道C++语言的规则有很大的不同。例如，C++规则说，如果类D从类B公有继承，从D的指针到B的指针就有一个标准转换；B的公有成员函数将被继承为D的公有成员函数，等等。这些规则都是正确的，但在将设计思想转化为C++的过程中，它们起不到任何作用。相反，

2001-08-05 19:04:00 1033

原创 Effective C++ 2e Item43

条款43: 明智地使用多继承要看是谁来说，多继承（MI）要么被认为是神来之笔，要么被当成是魔鬼的造物。支持者宣扬说，它是对真实世界问题进行自然模型化所必需的；而批评者争论说，它太慢，难以实现，功能却不比单继承强大。更让人为难的是，面向对象编程语言领域在这个问题上至今仍存在分歧：C++，Eiffel和the Common LISP Object System (CLOS)提供了MI；Smallt

2001-08-05 19:01:00 866

原创 Effective C++ 2e Item42

条款42: 明智地使用私有继承条款35说明，C++将公有继承视为 "是一个" 的关系。它是通过这个例子来证实的：假如某个类层次结构中，Student类从Person类公有继承，为了使某个函数成功调用，编译器可以在必要时隐式地将Student转换为Person。这个例子很值得再看一遍，只是现在，公有继承换成了私有继承：class Person { ... };class Student:

2001-08-02 19:18:00 810

原创 Effective C++ 2e Item41

条款41: 区分继承和模板考虑下面两个设计问题：· 作为一位立志献身计算机科学的学生，你想设计一个类来表示对象的堆栈。这将需要多个不同的类，因为每个堆栈中的元素必须是同类的，即，它里面包含的必须只是同种类型的对象。例如，会有一个类来表示int的堆栈，第二个类来表示string的堆栈，第三个类来表示string的堆栈的堆栈，等等。你也许对设计一个最小的类接口（参见条款18）很感兴趣，所以会将

2001-08-01 20:11:00 875

原创 Effective C++ 2e Item40

条款40: 通过分层来体现 "有一个" 或 "用...来实现"使某个类的对象成为另一个类的数据成员，从而实现将一个类构筑在另一个类之上，这一过程称为 "分层"(Layering)。例如：class Address { ... }; // 某人居住之处class PhoneNumber { ... };class Person {public: ...

2001-08-01 20:09:00 826

原创 Effective C++ 2e Item39

条款39: 避免 "向下转换" 继承层次在当今喧嚣的经济时代，关注一下我们的金融机构是个不错的主意。所以，看看下面这个有关银行帐户的协议类(Protocol class )（参见条款34）：class Person { ... };class BankAccount {public: BankAccount(const Person *primaryOwner,

2001-07-31 22:13:00 1234

原创 Effective C++ 2e Item38

条款38: 决不要重新定义继承而来的缺省参数值让我们从一开始就把问题简化。缺省参数只能作为函数的一部分而存在；另外，只有两种函数可以继承：虚函数和非虚函数。因此，重定义缺省参数值的唯一方法是重定义一个继承而来的函数。然而，重定义继承而来的非虚函数是一种错误（参见条款37），所以，我们完全可以把讨论的范围缩小为 "继承一个有缺省参数值的虚函数" 的情况。既然如此，本条款的理由就变

2001-07-31 22:12:00 1019

原创 Effective C++ 2e Item37

条款37: 决不要重新定义继承而来的非虚函数有两种方法来看待这个问题：理论的方法和实践的方法。让我们先从实践的方法开始。毕竟，理论家一般都很耐心。假设类D公有继承于类B，并且类B中定义了一个公有成员函数mf。mf的参数和返回类型不重要，所以假设都为void。换句话说，我这么写：class B {public: void mf(); ...};class D: public B

2001-07-30 19:06:00 751

原创 Effective C++ 2e Item36

条款36: 区分接口继承和实现继承（公有）继承的概念看起来很简单，进一步分析，会发现它由两个可分的部分组成：函数接口的继承和函数实现的继承。这两种继承类型的区别和本书简介中所讨论的函数声明和函数定义间的区别是完全一致的。作为类的设计者，有时希望派生类只继承成员函数的接口（声明）；有时希望派生类同时继承函数的接口和实现，但允许派生类改写实现；有时则希望同时继承接口和实现，并且不允许派生类改写

2001-07-30 19:05:00 868

原创 Effective C++ 2e Item35

继承和面向对象设计很多人认为，继承是面向对象程序设计的全部。这个观点是否正确还有待争论，但本书其它章节的条款数量足以证明，在进行高效的C++程序设计时，还有更多的工具听你调遣，而不仅仅是简单地让一个类从另一个类继承。然而，设计和实现类的层次结构与C语言中的一切都有着根本的不同。只有在继承和面向对象设计领域，你才最有可能从根本上重新思考软件系统构造的方法。另外，C++提供了多种很令人困惑的面

2001-07-29 18:38:00 747

原创 Effective C++ 2e Item34

条款34: 将文件间的编译依赖性降至最低假设某一天你打开自己的C++程序代码，然后对某个类的实现做了小小的改动。提醒你，改动的不是接口，而是类的实现，也就是说，只是细节部分。然后你准备重新生成程序，心想，编译和链接应该只会花几秒种。毕竟，只是改动了一个类嘛！于是你点击了一下"Rebuild"，或输入make（或其它类似命令）。然而，等待你的是惊愕，接着是痛苦。因为你发现，整个世界都在被重新编译

2001-07-28 19:32:00 988

原创 Effective C++ 2e Item33

条款33: 明智地使用内联内联函数------多妙的主意啊！它们看起来象函数，运作起来象函数，比宏(macro)要好得多（参见条款1），使用时还不需要承担函数调用的开销。你还能对它们要求更多吗？然而，你从它们得到的确实比你想象的要多，因为避免函数调用的开销仅仅是问题的一个方面。为了处理那些没有函数调用的代码，编译器优化程序本身进行了专门的设计。所以当内联一个函数时，编译器可以对函数体执行特

2001-07-25 20:26:00 987

原创 Effective C++ 2e Item32

条款32: 尽可能地推迟变量的定义是的，我们同意C语言中变量要放在模块头部定义的规定；但在C++中，还是取消这种做法吧，它没必要，不自然，而且昂贵。还记得吗？如果定义了一个有构造函数和析构函数的类型的变量，当程序运行到变量定义之处时，必然面临构造的开销；当变量离开它的生命空间时，又要承担析构的开销。这意味着定义无用的变量必然伴随着不必要的开销，所以只要可能，就要避免这种情况发生。正如我

2001-07-25 20:24:00 820

原创 Effective C++ 2e Item31

条款31: 千万不要返回局部对象的引用，也不要返回函数内部用new初始化的指针的引用本条款听起来很复杂，其实不然。它只是一个很简单的道理，真的，相信我。先看第一种情况：返回一个局部对象的引用。它的问题在于，局部对象 ----- 顾名思义 ---- 仅仅是局部的。也就是说，局部对象是在被定义时创建，在离开生命空间时被销毁的。所谓生命空间，是指它们所在的函数体。当函数返回时，程序的控制离开了这

2001-07-23 20:24:00 909

原创 Effective C++ 2e Item30

条款30: 避免这样的成员函数：其返回值是指向成员的非const指针或引用，但成员的访问级比这个函数要低使一个成员为private或protected的原因是想限制对它的访问，对吗？劳累的编译器要费九牛二虎之力来确保你设置的访问限制不被破坏，对不对？所以，写个函数来让用户随意地访问受限的成员没多大意义，对不对？如果你确实认为有意义，那么请反复阅读本段，直到你不这样认为为止。实际编程中很容易

2001-07-23 20:23:00 1479

原创 Effective C++ 2e Item29

类和函数: 实现C++是一种高度类型化的语言，所以，给出合适的类和模板的定义以及合适的函数声明是整个设计工作中最大的一部分。按理说，只要这部分做好了，类、模板以及函数的实现就不容易出问题。但是，往往人们还是会犯错。犯错的原因有的是不小心违反了抽象的原则：让实现细节可以提取类和函数内部的数据。有的错误在于不清楚对象生命周期的长短。还有的错误起源于不合理的前期优化工作，特别是滥用inline关

2001-07-22 17:35:00 1019

原创 Effective C++ 2e Item28

条款28: 划分全局名字空间全局空间最大的问题在于它本身仅有一个。在大的软件项目中，经常会有不少人把他们定义的名字都放在这个单一的空间中，从而不可避免地导致名字冲突。例如，假设library1.h定义了一些常量，其中包括：const double LIB_VERSION = 1.204;类似的，library2.h也定义了：const int LIB_VERSION = 3;很

2001-07-22 10:14:00 888

原创 Effective C++ 2e Item27

条款27: 如果不想使用隐式生成的函数就要显式地禁止它假设想写一个类模板Array，它所生成的类除了可以进行上下限检查外，其它行为和C++标准数组一样。设计中面临的一个问题是怎么禁止掉Array对象之间的赋值操作，因为对标准C++数组来说赋值是不合法的：double values1[10];double values2[10];values1 = values2;

2001-07-15 18:30:00 1188

原创 Effective C++ 2e Item26

条款26: 当心潜在的二义性每个人都有思想。有些人相信自由经济学，有些人相信来生。有些人甚至相信COBOL是一种真正的程序设计语言。C++也有一种思想：它认为潜在的二义性不是一种错误。这是潜在二义性的一个例子：class B; // 对类B提前声明 // class A {public: A(

2001-07-15 18:28:00 810

原创 Effective C++ 2e Item25

条款25: 避免对指针和数字类型重载快速抢答：什么是“零”？更明确地说，下面的代码会发生什么？void f(int x);void f(string *ps);f(0); // 调用f(int)还是f(string*)?答案是，0是一个int——准确地说，一个字面上的整数常量——所以，“总是”f(int)被调用。这就是问题所在：因为

2001-07-15 18:27:00 836

原创 Effective C++ 2e Item24

条款24: 在函数重载和设定参数缺省值间慎重选择会对函数重载和设定参数缺省值产生混淆的原因在于，它们都允许一个函数以多种方式被调用：void f(); // f被重载void f(int x);f(); // 调用f()f(10);

2001-07-15 18:25:00 904

空空如也

空空如也