参考资料：《HowTo.SMTP》，《SendMail》(NextFly写的)，《MSDN 2005》

好了，废话就不说了。下面是源代码：

其中需要注意的是寄件人地址与邮件内容里的邮件地址的关系：

寄件人的地址必须和你用的连接帐号一致。帐号和密码是使用Base64编码的（关于什么是Base64编码请到http://www.ynutx.net/blog/user1/Myth/archives/2006/1682.html下面看看，它的C实现代码在下面）。。。。

而在邮件内容里的地址只是一个告诉邮件服务器这封信是谁发的。可以和你所使用的发送帐号不一致！也就是说你可以伪造别人的地址进行邮件发送。。。。

哎，不要干什么干事哟^_^!

好了，下面就是Base64编码与解码的实现代码了：

呵呵，终于完了。有兴趣的可以试试哦，发不了的话加我QQ：845765,或者发邮件给我：DL88250@gmail.com 大家一起研究学习一下！

大牛 Andrei Alexandrescu 的《 Modern C++ Design 》讨论的是 C++ 语言的最前沿研究： generative programming 。本书中译版估计得要半年以后才能出来，所以只能靠其所附源码来窥测generative programming了。

目前，我刚将源码读解了约一半，等全部读完，我会将我的读解注释放出来的。现在，现谈一下我的感想。

    先扯得远一点。C++有两个巨大优点：和C兼容，自由；有两个巨大缺点：和C兼容，复杂。C++极其复杂，很难掌握，而这正是“自由”的代价。C++语言是个多编程风格的语言，它同时支持 过程化、基于对象、面向对象、泛型、生成性 这5种编程思想，具有极其强大的表达能力，可以方便地将各种设计转化为实现。

generic Programming 的思想精髓是基于接口编程（相对于OOP，连多态所需的基类都不要了），它的技术出发点是选择子，核心技术是：类型推导、类型萃取、特化/偏特化，其成果是STL库：一组通用容器和一组操作于通用容器上的通用算法。

generative programming 的思想精髓是基于策略编程（编译器根据策略自动生成所需代码，由于具有更高的抽象性，所以代码复用度也更高），在Loki库的实现中，目前只使用了递归策略，它的技术出发点是Typelist，核心技术是：类型推导、类型萃取、特化/偏特化、多重继承、类型间去耦合，其成果是Loki库：对设计模式的封装。

Typelist 是一种对类型本身进行存储和管理的技巧，它的源码已经贴过了，我也作了注解，此处不再谈论。

这是多重继承在COM之后的又一大型运用。多重继承极易发生菱型缺陷，所以Loki库使用了类型间去耦合技术来避免：

    template <typename T>

    struct Type2Type

    {

        typedef T OriginalType;

    };

经过这样一层转换后，原类型 T 间的各种转换关系（尤其是继承 / 派生关系）已不复存在， 菱型缺陷 不会再发生了。

Loki库的具体实现相当讲究技巧，设计它非常困难（难度远大于STL库，和Boost库有得一拼啊）。但使用它却非常容易，而且便利显著。由于Loki库提供了对设计模式的封装，所以极大量地丰富了C++语言的表达能力，使的你的设计更容易地转化为实现。

目前，Loki库只提供了对厂模式和visitor模式的封装，它还处于发展初期。

我以visitor模式为例，讲解Loki库提供的便利。

Visitor 模式有四种实现方式：1一串RTTI的类型判断；2二次调度（double dispatch）；3建立类型与处理函数的对应表；4非循环visitor（Acyclic Visitor）。在《More Effective C++》 Item 31中讨论了前3种实现（虽然它的例子本身不太算visitor模式的）。第四种方式在《使用设计模式改善程序结构》（二）（ http://www-900.ibm.com/developerWorks/cn/java/l-dpstruct/part2/index.shtml ）中有详细讲解。

原型图

以这张原型图而言，用户需要自己实现大量的代码，而且，由于使用多重继承技术，在具体 Host 类间有继承关系时，它一定会发生问题。

 Loki 库实现图

使用 Loki 库，用户实现 visitor 模式时只需：让 Host 类从 BaseVisitable 继承，并在所有派生类中加上 DEFINE_VISITABLE() 宏，让所有 Visitor 类从 BaseVisitor 类和 VisitorImpl 类进行二重继承（并且可以只提供对自己感兴趣的 Host 类的处理函数，不感兴趣的不提供处理函数）。用户的工作量非常小、非常简单，设计人员可以不用为实现而分心了。

更重要的是，由于采用了类型间去耦合技术，多个 Host 之间存在继承关系时，不会发生问题（其具体实现较复杂，于是我在 UML 图上作了模糊处理，没有展示出来，留在以后 Loki 库源码读解时讲述）。

    将 算法独立抽象出来，在C++中算不上新鲜：STL中就封装了不少高效、健壮、灵活的泛型组件及对应的基础算法，工艺之高、适用性之强，非寻常我辈所轻易能 及。这里不打算（也暂没有能力打算）以STL这样的工业级要求来谈论算法封装，只因最近尝翻大师名著，阅者水平有限，仅嗅触至皮毛，理智薄弱，感情却蓬勃 发展：也欲尝试“封装”的味道。选择了最简易的穷举算法，抽其骨架，炮制成class，套上一实际例子，观之run之，抽象程度颇低，效率损失弥彰；然却 也自觉有可爱之处，遂作此文以记之。诚惶诚恐，便于名目之前加“闲谈”二字，倘果因技术问题招致痛骂，则试以此二字为护文符，聊且一挡。

    众所周知，穷举法可视为最简单的搜索：即是在一个可能存在可行状态（可行解）的状态全集中依次遍历所有的元素，并判断是否为可行状态。例如，要设计一个“从一堆苹果中找出蓝色的苹果”这样的穷举算法，则定义：

    (1) 状态全集：一堆苹果

    (2) 可行状态：蓝色的苹果

    噢， 好，我们现在已经抽取了两个基本概念，迫不及待要开始穷举了，但……怎么做呢？穷举的关键是“依次遍历”，即做到不重、不漏。呃，我们可以让听话的苹果们 排成一行，放在“苹果数组”中，然后呢，我们就可以按照0号苹果、1号苹果、2号苹果、...、n号苹果这样的顺序成功遍历。好，我们解决了遍历苹果的问 题……慢，我们现在是设计一个算法的抽象模型，如果一切待穷举的对象都已经活生生地摆在那里，当然有可能把它们全部收集起来并排队，但如果开始的时候我们 并不知道所有要穷举的对象，比如我们或许要通过一台安装在探测飞船内的计算机在全宇宙范围内穷举出除地球以外有生命的星球，那么我们的计算机可能是随着飞 船的前行方能不断地得到新星球的信息，而不是停在地球的时候就获得全宇宙的星球信息（就算可能，内存或许也装不下如此大的数据量——哪怕宇宙真的是有限 “大”的）。所以我们不应当要求穷举进行之前就能获得状态全集中的所有状态，这样一来，我们的“苹果数组”计划就宣告流产了。现在再看看我们激动人心的星 球搜索计划：它并没有把所有星球收罗排队，那么它成功的关键在哪里？在于飞船能否以适当的路径“光顾”完所有的星球；我们把这个条件加强一下：飞船每次到 达一个星球，都会看到星球上立着一个方向标，标示下一个星球的方位；而假定这样的标示保证飞船能够不重不漏地飞临宇宙中的所有星球。啊喔……你是不是觉得 我这是在异想天开？哦，没关系，大不了我们不搜索星球了，而除此之外的很多现实穷举问题都可以满足这个加强条件。嗯，我承认本文讨论的是满足这个加强条件 的稍稍狭义的穷举：它必须保证在知道一个状态的前提下能获得一个新状态，并且这样的“状态链”刚好能遍历整个状态全集。我们称从当前状态获得并转到下一个 状态的过程为“状态跳转”（我是想用“状态转移”的，嗨，可惜它会与动态规划算法的术语相混淆）：

    (3) 状态跳转：根据当前得到的苹果，按一定的“遍历算法”取得下一个苹果；这个算法保证不重不漏地取遍苹果堆中的所有苹果，只要所取的第一个苹果也是按算法定义给出的

    很显然，对于不同的穷举任务，都会有不同的遍历算法，所以这样一来我们就得将其实现下放给调用我们“穷举算法库”的用户们了。不过考虑到这的确是由于问题的多样性所决定的，因而这个要求应当是合理的。

    嗯啊，现在我们已经有了苹果源，目标苹果，乃至遍历苹果的方案（用户提供），接下来还差一个判断标准，这个倒简单了：

    (4) 判断标准：当前苹果是否为蓝色的苹果

    下一步，我们就可以考虑“the class of 穷举算法”的具体实现了。我们把这个class的名字定义为WalkThrough.

    首 先，让我们注意到，“状态”是一个很重要的概念：不同的穷举问题都有彼此不同的状态，在苹果问题中，“状态”是苹果，它包含了苹果颜色或者更多的信息；而 在星球搜索计划中，“状态”则是星球，它可能包含该星球的体积、平均密度、温度、是否有大气、是否探测到水、星表活动状况等一系列丰富得惊人的信息。因 此，不同状态(state)对应不同的数据类型，要让WalkThrough能处理它们，有必要使用模板，于是我们的最初定义如下：

template <class State>

class WalkThrough

{

};

    万 事开头难，但现在我们显然已经开了一个不错的头，嗯，继续。在考虑具体实现之前，先幻想一下我们的WalkThrough能为用户提供怎样的服务——当 然，它的本职工作是找到并返回可行状态，因此它似乎应该有一个类似于getFilter()的成员函数。问题是，如果可行状态不止一个时， getFilter()应当返回一个可行状态还是所有的可行状态？不难想象，返回所有可行状态的作法并不太现实，因为：1.有时候用户只需要一个，或者少 数几个可行状态，此时把所有的可行状态都穷举出来显然是低效而不必要的；2.甚至，有些问题的可行状态数量是无限的，如穷举素数，此时返回所有状态当然不 可能。同时考虑到用户要求的仍有可能是不止一个可行解，我们现在知道，应当提供一个getNextFilter()而不是getFilter()的函数： 第一次调用它时，将返回从初始状态开始，依序遍历到的第一个可行状态；而此后的调用都将以上次调用为起点继续向前遍历，返回下一个可行状态。需要注意的 是，如果已经遍历完了状态全集，显然再调用此函数是没有意义的，所以它应当返回一个标志，反馈给用户是否遍历已经完成。我们将这个函数定义为bool，如 果调用有效，则返回true，反之如果已经完成遍历，则返回false. 显然，我们相应需要一个私有的State对象变量curState，它用于存储当前的状态值。

    我 们是否应当给getNextFilter加上一个State引用参数，以向用户返回每次穷举到的可行状态？在这里我们并没有这样做。试想，可能用户会想获 得第5个遍历到的可行状态，那么他当然就要调用5次getNextFilter()，但前4次他并不要求得到所搜索到的可行状态。所以，我们将“找到下一 个可行状态”与“获得当前找到的可行状态”分离开来，新增加一个getState()成员函数，它返回一个State对象，注意到getState()操 作并不影响WalkThrough对象的内部状态，所以它同时应被声明为const成员函数。

    相 应地，我们需要一个setState()成员函数，它用于改变当前的状态值，例如设置初始状态的时候都有可能用到。它带一个const State&类型的参数，用以指定所要设定的State值，由于State可能是一个较大的类型，所以使用引用传递能保证效率，同时加上 const限制则保证该函数不会更改所传入的引用对象本身的值。

    同 时用户可能需要知道，对于一个穷举对象，是否已经完成穷举，当然他可以调用getNextFilter()并检查返回值，但如果遍历没有完成，则 getNextFilter()除了最后返回true之外还会额外地进行搜索，并将当前状态改为下一个可行状态，这份额外的工作可能并不是用户所期望需要 的。因此我们将增加一个成员函数isOver()，它不带参数，返回一个bool值：如果已经完成遍历，返回true，反之返回false. 相应地，我们需要一个私有bool变量overFlag，它用于存储isOver()所需要的状态值。

    至此，WalkThrough的定义如下：

template<class State>

class WalkThrough

{

public:

    void setState(const State& s) { curState = s; }

    State getState() const { return curState; }

    bool getNextFilter();

    bool isOver() const { return overFlag; }

private:

    State curState;

    bool overFlag;

};

    我 们把构造函数与析构函数置后，先考虑起关键作用的getNextFilter()的实现。首先，getNextFileter()由当前的状态跳转为下一 状态，然后判断新状态是否为可行，若可行，则停止跳转并返回true，否则继续跳转，重复上述步骤。另一方面，如果已经完成了遍历而还没有找到可行状态， 则将overFlag设为false并且返回false.

    我 们将跳转操作、判断是否为可行状态操作下放给用户实现：用户相应提供两个函数，然后向WalkThrough对象传入函数指针，供 getNextFileter()调用。那么这两个函数应该采用什么样的接口形式比较合适呢？先看看跳转函数，一个很直观的实现是传入一个State对象 （或其const引用），然后返回“下一个”State对象，不过至少在返回的时候，值传递会产生State对象的复制操作（诸如NRV优化之类的语言标 准外的特定编译器实现不在讨论之列），当State对象比较大的时候，开销是不值得的。我们应当考虑传入State对象的引用，然后“全权委托”跳转函数 进行直接修改——把它“变”成下一个状态。可能会有人质疑这样做是否违反了封装原则，但即使摒弃效率方面的权衡，这样做也是合情合理的。跳转函数——不妨 视为负责“状态转化”函数，就像一个炼丹炉——有权利、甚至有义务这样做，它的职责是“转化状态”而非“获得状态”。唔……我都觉得自己在语言上过于细究 了。嗯，除了转化状态，跳转函数在发现遍历完成之后也应当及时告知调用它的getNextFilter()，否则下放了大部分权力的 getNextFilter()是无从知晓的。于是我们的跳转函数接口为：接受一个State的引用，返回一个bool值。如果遍历没有完成，那么函数执 行完毕之后State引用将变为它的后继状态，且函数返回true；否则State不变，函数返回false.

    判断是否为可行状态的函数接口则很好定义了：它接受一个const State型引用作为待判断的状态，返回bool值，其中true表示该状态为可行状态，false表示该状态不是可行状态。

    我们将跳转函数以及判断函数的函数指针类型分别定义为StateJumper及Matcher，由于用户可能也会用到这些函数指针类型，我们将定义加到public域中：

public:

    typedef bool (*StateJumper)(State&);

    typedef bool (*Matcher)(const State&);

// others...

    并且，在private域中相应加上StateJumper和Matcher的函数指针变量，存储用户提供的相应函数的地址：

private:

    // others...

    StateJumper Jumper;

    Matcher IsMatch;

    相应地，内联定义公有成员函数：

    void setJumper(const StateJumper j) { Jumper = j; }

    void setMatcher(const Matcher m) { IsMatch = m; }

    分别用于设置Jumper和IsMatch的函数指针值。

    现在所有的成员变量都已经浮出水面，我们可以定义构造函数和析够函数了，我们不打算对WalkThrough的创建与继承等方面作限制，因此它们都加在public域中。先看构造函数，有必要定义一个默认构造函数：

    WalkThrough(): overFlag(false), Jumper(0), IsMatch(0) { }

    这个构造函数不指定任何初始条件，包括当前状态。可以在需要的时候使用一系列的set成员函数定义。

    接下来定义一个“全功能”的构造函数：

    WalkThrough(const State& s, StateJumper j = 0, Matcher m = 0)

    : overFlag(false), curState(s), Jumper(j), IsMatch(m) { }

    除了overFlag外，所有的属性都可以在这个构造函数中设定（当然，它允许缺省值）。由于没有进行任何穷举操作，将overFlag强制为false是合理的。

    对 于拷贝构造函数，由于我们这里没有涉及内存分配，没有“深拷贝”的需求，因此不作定义，使用默认的位拷贝可以有不错的效率。类似地，析构函数也没有什么事 务需要处理，不过考虑到这个WalkThrough可能用于继承，且有可能出现delete基类指针来删除派生对象的情况，便定义一个空的虚析构函数，以 免引起错误：

    virtual ~WalkThrough() { }

    最后，我们来实现唯一的一个非内联函数：getNextFilter()，在给出实现之前顺便给出完整的WalkThrough的定义：

template <class State>

class WalkThrough

{

public:

    typedef bool (*StateJumper)(State&);

    typedef bool (*Matcher)(const State&);

    WalkThrough(): overFlag(false), Jumper(0), IsMatch(0) { }

    WalkThrough(const State& s, StateJumper j = 0, Matcher m = 0)

    : overFlag(false), curState(s), Jumper(j), IsMatch(m) { }

    virtual ~WalkThrough() { }

    void setJumper(const StateJumper j) { Jumper = j; }

    void setMatcher(const Matcher m) { IsMatch = m; }

    void setState(const State& s) { curState = s; }

    State getState() const { return curState; }

    bool getNextFilter();

    bool isOver() const { return overFlag; }

private:

    State curState;

    bool overFlag;

    StateJumper Jumper;

    Matcher IsMatch;

};

template <class State>

bool WalkThrough<State>::getNextFilter()

{

    if (overFlag)  // 若已完成遍历，则直接返回

    return false;

    if (!Jumper || !IsMatch)  // 若用户未定义Jumper或IsMatch函数，则返回

    {

        overFlag = true;  // 这里将没有定义Jumper或IsMatch的穷举视为遍历完成

        return false;     // 不过，如果你认为两者绝不能等同，也可以抛出异常

    }

    while (!(overFlag = !Jumper(curState)) && !IsMatch(curState))

    ;  // 获取下一状态，直到找到可行状态或者遍历完成

    if (overFlag)   // 根据遍历完成情况决定返回值

        return false;

    else

        return true;

}

    呼……小功告成，总算可以小松一口气。不过如果到此就关闭计算机，就像直播球赛进行到高潮时突然停电一样，太令人不爽。——弄了这么久，总该给个example试一试，来点成就感吧？

    没 问题。苹果问题太简单，于是我们选择的是一个传说中的“和是50”超级难题，什么是“和是50”超级难题？请听好了：所谓“和是50”超级难题，就是在0 到99的整数组成的一个加法算式中，找出和是50的算式，考虑加数顺序，像0+50啊，1+49啊，……，49+1啊，50+0啊……（喂，我知道你可能 想杀人，但请不要让与之匹配的眼光朝着我……）对于这样一个超级难题，我们经过研究，决定采用……穷举法来实现（哪来的这么多西红柿？）。

    首先我们研究这个问题的状态是什么——两个加数，不是么，它们是有顺序的，并且可以取0到99的整数。于是乎，我们定义状态类如下（注：STL中有类似的东西，但作为完整的示例，我们亲自手工打造）：

class Pair

{

public:

    Pair(int mx = 0, int my = 0): x(mx), y(my) { }

    int x, y;

};

    Pair虽然属于世界上最深奥的class之一，然而凭各位的智慧，我就不用多解释了。接着我们来看一下跳转函数的实现——当然，它应当符合WalkThrough中定义的StateJumper类型：

bool counter(Pair& pair)

{

    if (pair.y < 99)

    ++pair.y;

    else

    {

    if (pair.x < 99)

    {

        ++pair.x;

        pair.y = 0;

    }

    else

        return false;

    }

    return true;

}

    counter 的作用是试图将pair.y增1，但如果pair.y已经到达上限99，则将pair.x加1，同时pair.y置0继续下一轮；但如果pair.x也到 了99，那么，噢，说明遍历结束了。——嗯，这样的确是一种有效的遍历方式，对吧。它实际上类似于下面的二重循环：

    for (; pair.x <= 99; ++pair.x)

        for (pair.y = 0; pair.y <= 99; ++pair.y)

             ...

    只不过循环要求在循环体内解决一切问题，而我们“解决一切问题”的重任担在了另一个函数里，counter不能越权，因而不能这样直接使用循环。

    接下来是判断是否为有效状态的函数，它最简单了：

bool match(const Pair& pair)

{

    return (pair.x + pair.y) == 50;

}

    万事俱备，可以写main:

int main()

{

    WalkThrough<Pair> sf50(Pair(0, -1), &counter, &match);

    while (sf50.getNextFilter())

    cout << sf50.getState().x << " + "

         << sf50.getState().y << " = 50" << endl;

    return 0;

}

    请 一定要注意，getNextFilter()中有一个"Next"，也就是说，如果把状态全集中的第一个状态作为构造的参数，——本题中就是Pair (0, 0)——是可行状态的话，getNextFilter()将不会判断到，它直接判断“下一个”状态，就是Pair(0, 1)去了。为了让它能够完整地判断，我们不能让Pair(0, 0)作为第一个状态，而是作为首次运行getNextFilter()后到达的状态。于是，在构造初始状态时我们就要用“前”一个状态Pair(0, -1)作为构造参数（虽然它根本不在本题的状态全集中），以使得getNextFilter()从Pair(0, 0)开始判断。

    嗯， 好，在运行之前不要忘了#include <iostream>，不要忘了打开std名字空间（using namespace std;），不要忘了粘上/包含上前面的WalkThrough的完整定义……编译，运行，好，这个超级难题被我们解决了。我的编译平台是Redhat Linux 9， GNU C++ 3.2.2.

    最 后我们分析小结一下经过封装之后的穷举算法。首先看效率——是啦，我知道这个“和是50”超级难题所用的算法很糟糕——我是指在相同算法的前提下，使用我 们封装好的穷举类进行实现时的效率损失：初始化以及一系列set/get函数基本不影响效率，主开销源自于getNextFilter()本身的调用及 getNextFilter对两个用户提供函数的调用所产生的额外开销。试想如果用相同的算法，但仅用两层for来做穷举，则少了上万次的函数入栈、清栈 操作。穷举法本身就不是一个高效的搜索思想，所以对内层代码的效率变化是最敏感的，这一点是我们所封装的穷举类的最大缺点。

原作： Ilia Yordanov,  loobian@cpp-home.com

二进制文件的处理

虽然有规则格式（ formatted ）的文本（到目前为止我所讨论的所有文件形式）非常有用，但有时候你需要用到无格式（ unformatted ）的文件——二进制文件。它们和你的可执行程序看起来一样，而与使用 << 及 >> 操作符创建的文件则大不相同。 get() 函数与 put() 函数则赋予你读 / 写无规则格式文件的能力：要读取一个字节，你可以使用 get() 函数；要写入一个字节，则使用 put() 函数。你应当回想起 get() ——我曾经使用过它。你可能会疑惑为什么当时我们使用它时，输出到屏幕的文件内容看起来是文本格式的？嗯，我猜这是因为我此前使用了 << 及 >> 操作符。

译注：作者的所谓“规则格式文本（ formatted text ）”即我们平时所说的文本格式，而与之相对的“无格式文件（ unformatted files ）”即以存储各类数据或可执行代码的非文本格式文件。通常后者需要读入内存，在二进制层次进行解析，而前者则可以直接由预定好的 << 及 >> 操作符进行读入 / 写出（当然，对后者也可以通过恰当地重载 << 及 >> 操作符实现同样的功能，但这已经不是本系列的讨论范围了）。

get() 函数与都各带一个参数：一个 char 型变量 （译注：指 get() 函数） 或一个字符 （译注：指 put() 函数，当然此字符也可以以 char 型变量提供） 。

假如你要读 / 写一整块的数据，那么你可以使用 read() 和 write() 函数。它们的原型如下：

istream &read(char *buf, streamsize num);

ostream &write(const char *buf, streamsize num);

对于 read() 函数， buf 应当是一个字符数组，由文件读出的数据将被保存在这儿。对于 write() 函数， buf 是一个字符数组，它用以存放你要写入文件的数据。对于这两个函数， num 是一个数字，它指定你要从文件中读取 / 写入的字节数。

假如在读取数据时，在你读取“ num ”个字节之前就已经到达了文件的末尾，那么你可以通过调用 gcount() 函数来了解实际所读出的字节数。此函数会返回最后一次进行的对无格式文件的读入操作所实际读取的字节数。

在给出示例代码之前，我要补充的是，如果你要以二进制方式对文件进行读 / 写，那么你应当将 ios::binary 作为打开模式加入到文件打开的参数表中。

现在就让我向你展示示例代码，你会看到它是如何运作的。

示例 1 ：使用 get( ) 和 put( )

#include <fstream.h>

void main()

{

    fstream File("test_file.txt",ios::out | ios::in | ios::binary);

    char ch;

    ch='o';

    File.put(ch); // 将 ch 的内容写入文件

    File.seekg(ios::beg); // 定位至文件首部

    File.get(ch); // 读出一个字符

    cout << ch << endl; // 将其显示在屏幕上

    File.close();

}

示例 2 ：使用 read( ) 和 write( )

#include <fstream.h>

#include <string.h>

void main()

{

    fstream File("test_file.txt",ios::out | ios::in | ios::binary);

    char arr[13];

    strcpy(arr,"Hello World!"); // 将 Hello World! 存入数组

    File.write(arr,5); // 将前 5 个字符—— "Hello" 写入文件

    File.seekg(ios::beg); // 定位至文件首部

    static char read_array[10]; // 在此我将打算读出些数据

    File.read(read_array,3); // 读出前三个字符—— "Hel"

    cout << read_array << endl; // 将它们输出   

    File.close();

原作：Ilia Yordanov,  loobian@cpp-home.com

构造函数(中)

三、复制构造函数

    1.存在的理由

    厨 师做烹饪的时候总要往锅里加入各式各样的调料，调料的种类、数量在相当大的程度上就决定了菜肴的口感；经验丰富的厨师总是擅长于根据顾客的品味差异来调节 调料的投入，以迎合顾客的喜好。我们在炮制对象的时候亦如此：通过重载不同具有参数表的构造函数，可以按我们的需要对新创建的对象进行初始化。譬如，对于 复数类Complex，我们可以在创建时指定实部、虚部，它通过“投入”的两个double参数来实现；而对于整型数组类IntArray，我们亦可以在 构造函数中“投入”一个int值作为数组对象的初始大小，如果需要，我们还可以再“撒进”一个内部数组作为数组各元素的初始值，等等。嗯，总之，就是说我 们可以通过向类的构造函数中传入各种参数，从而在对象创建之初便根据需要可对它进行初步的“调制”。假使我们已经做好了一道菜，呃，不，是已经有了一个对 象，比如说，一个复数类Complex的对象c，现在我们想新创建一个复数对象d，使之与c完全相等，应该怎么办？噢，有了上节的经验，我知道你会兴冲冲 地走到电脑，敲出类似于下面的代码：

    Complex d(c.getRe(), c.getIm());     // getRe()与getIm()分别返回复数的实、虚部

    很 好，它可以正确的工作，不是吗？不过，再回过头两欣赏几眼之后，你是否和我一样开始觉得似乎这样有些冗长？而且，应该看到复数类是一个比较简单的抽象数据 类型，它提供的公有接口可以让我们访问到它所有的私有成员变量，所以我们才得以获得c的所有的“隐私”数据来对d进行初始化；但有相当多的类，是不能也不 该访问到它所有的私有对象的，退一步说，就算可以完全访问，我们的构造函数参数表也未必总能精细地、一丝不苟地刻画对象，例如对于IntArray类的某 个对象，例如a，可能它会包含一千个元素，但我们不可能写

    IntArray copy_of_a(a.size(), a[0], a[1], a[2], ..., a[999]);  // 足够详细的刻画，同时也足够愚蠢

    唔， 看来我们错就错在试图用数量有限的辅助参数来刻画我们的对象，而它往往是不合适的。要想以对象a来100%地确定对象b，就必须让对象b掌握对象a的 100%的信息，也就是说，构造函数中所传入的参数应该包含对象a的100%的信息。谁包含了“对象a的100%的信息”呢？看上去似乎是一道难题，哦， 我们似乎被前面各个杂乱的参数表弄得头晕脑胀，但我们不应该忘却从简单的方面考虑问题的法则，包含“对象a的100%的信息”的家伙，不应该是一群数量巨 大的变量，不应该是一组令人恐惧的参数，它应该就是...就是对象a本身。

    啊哈，真是废话。别管这么多，我们现在要让复数d初始化之后立刻等于复数c，就可以写

    Complex d(c);    // 嗯...完美的表示

    “等等...”你也许会提醒说，“你好像还没有定义与之对应的构造函数。”

    这 是一个非常好心的提醒，不过我可以带着愉悦的心情告诉你：C++对于“以与自己同类型的对象为作为唯一参数传入的构造函数”已经做了默认的定义，对于这个 默认的构造函数所创建的对象，将与作为参数传入的对象具有完全相同的内容：实际上，这个过程一般是以“位拷贝”的方式进行的，即是将参数对象所占的那一块 内存的内容“一股脑”地拷贝到新创建的对象所处的内存区块中，这样做的结果，便使得新创建的对象与参数对象内有完全相同的成员变量值，无论是公有的还是私 有的，因而，我们也就得以以一个已存在的对象来初始化一个新的对象，当然，两者应该是同一类型的。

    你也许会对“为何C++要默认提供这样一个构造函数”感兴趣。实质上，不仅仅是上面的“声明对象并初始化”的例子要使用到这个特性，在一些更普遍的情况、同时也是我们所不注意的情况中，必须要使用到这个功能，例如：进行值传递的函数调用。考虑下面的代码片断：

    void swap(int a, int b)

    {

        int temp = a;

        a = b;

        b = temp;

    }

    int main()

    {

       int x = 1, y = 2;

       swap(x, y);    // 噢...

       ... // others

       return 0;

    }

    问 题：执行了swap(x, y)之后，x, y的值分别是多少？毫无疑问，当然是x==1, y==2，因为执行swap时，交换的并不是x,y变量的值，而只是它们的一个副本。我们可以从某个角度认为：在调用swap函数时，将会“新创建”两个 变量a, b，而a, b分别以x, y的值进行初始化，像这样：

    int a(x), b(y);

    ...  // 此后的操作都与x, y无关了

    同样，假如有这样一个函数：

    void swap(Complex a, Complex b)

    {

        ...

    }

    在出现诸如swap(p, q)这样的调用时，也会对p, q进行复制操作，类似于：Complex a(p), b(q);

    与参数的传入一样，函数在返回时(如果有返回的话)，只要不是返回某个引用，则也会出现类似的复制操作(这里不考虑某些省却复制步骤的编译优化)。

    所以，假如系统不会为我们默认定义这样的特殊的构造函数，我们将不能定义任何出现Complex类型的参数，或者返回值为Complex类型的函数，而这简直是没有道理的，至少，看上去不是那么好令人接受。

    由于这样的构造函数可以看作是从一个既有的同型对象中“复制”创建出一个新对象，所以也把这个构造函数称为复制构造函数，或拷贝构造函数(copy constructor).实质上它与其它的构造函数没有区别，只是：

    1.如果没有明确给出，系统会默认提供一个复制构造函数(类似于不带参数的构造函数，以及析构函数)；

    2.进行值传递的函数调用或返回时，系统将使用此构造函数(相对于其它的通常只存在人为调用的构造函数)。

    噫，以上便是有关复制构造函数的讲解。时间不早，该休息了。朋友，祝您晚安，下次见...

    哦， 不不不，弄错了，没有这么简单。我们...我们才刚刚开始...唔，至少我还得在睡前把这篇文章打完，而且下面似乎内容不少，总之，还有相当多的因素要考 虑。嗯，你可能说，C++提供的默认复制构造函数不是已经尽职尽责地、一个bit不漏地为我们将对象原原本本地克隆过去么，那么所得的新对象肯定与被复制 对象完全一样，还有什么要考虑的？

    问 题就出在对于“完全一样”的理解上。我们说两个三角形完全一样，是指它们具有对应相同的边、角；我们说两个复数完全一样，是指它们具有对应相等的实部、虚 部；我们说两个文件完全一样，是指它们的内容一丝不苟地相同...那我们说某个类型的两个对象完全一样，当然，从朴素的意义上说，应该是指这两个对象具有 相同的成员，包括成员函数与成员变量；不过，同型对象当然有相同的成员函数，所以更确切地说，完全相同即是具有相同的成员变量。

    但C ++中的类的对象并非、也不应该仅被视为绻缩于内存中某个角落的一系列二进制数据，那是机器的观点。事实上，对象作为现实模型的一个描述，它本身应该具有 一定的抽象而来意义。一个Orange类的对象，在编程时也许我们更多的时候会有意无意地将其作为一个活生生的桔子进行考虑，而非一撮二进制流。C++的 面向对象抽象使我们更好地刻画现实模型，并进行正确的、恰当的使用。因此，当我们说两个对象“完全相等”，基于抽象的思想，我们所指的，或者说所要求的， 只是对象所代表的现实模型的意义上的相等，至于在二进制层面的实现上，它们内部的0101是否一样，倒不是我们最关心的，当然，可能在许多情况下，两者是 等同的，但也不尽然。譬如两个IntArray数组对象，当然，它们各包含了一个整型指针作为私有成员，以存放数组所处内存空间的首地址。但我们说这两个 数组对象相同，更多意义上指的是它们含有相同的维数、尺寸，以及对应相等的元素，至于存放首地址的指针值，尽管它们在大多数情况下都不相等，但这并不妨碍 我们认为两个数组相同。在这个例子中，“对象”所代表的概念上的意义与它在机器层面的意义出现了分岐，程序语言的任务之一就在于提供更恰当的抽象，使程序 具有某种吻合于现实模型的条理性。所以两者出现分岐之时，既然我们使用的是具有相当抽象能力的高级语言，就应当倾向于尊重现实的概念，而不是返朴归真。

    说 了这么多，现在该回过头来看一看默认复制构造函数所采用的“完全照搬”复制模式将有可能带来怎样的“概念层面”与“机器层面”的矛盾。刚才我们已经抓到了 IntArray类的尾巴，现在来看看，假如使用代表着“机器层面理解”的默认复制函数对它进行复制构造，会发生什么事情。嗯，没错，新创建的 IntArray对象--不妨称为b--将具有与原对象--不妨称为a--完全相同的成员变量，当然也包括用于存储数组内存空间首地址的指针成员，也就是 说，a与b实际上是“共享”了同一块内存以存放“它们”的数据。从此，如果我改变a数组中的某个元素的值，则b中相应元素也会改变，反之亦然--我们的程 序闹鬼了。更为严重的是，如果我们在IntArray的析构函数中加入了释放数组内存的代码(几乎所有的容器都会这样做)，那么由于有多个对象共享同一块 内存，这块可怜的内存将会被释放多次，事实上当第二次来临时我们的程序很可能就已经崩溃了，这种情况在值传递调用函数时最为典型。

    我 们概念意义上对“数组复制”的理解是产生一个新数组，使之与原数组的元素均对应相同，而绝不是什么共享内存的鬼把戏。但我们忠厚的C++编译器可不了解这 些，毕竟它只是机器，所以也只会尽职尽责地为我们施行位拷贝。这样一来，我们就有义务把我们对概念本身的理解告诉C++，当然，这个途径就是显示地定义一 个复制构造函数。

    2.关于声明的讨论

    首 先，以IntArray类为例，我们来看看复制构造函数的声明应该是什么样子：构造函数是没有返回值的，复制构造函数当然也不例外，因此我们只须考虑参 数。复制构造函数只有一个参数，由于在创建时传入的是同种类型的对象，所以一个很自然的想法是将该类型的对象作为参数，像这样：

    IntArray(IntArray a);

    不 幸的是，即使是这样朴实无华的声明也隐含了一个微妙的错误，呵，我们来看看：当某个时候需要以一个IntArray对象的值来为一个新对象进行初始化时， 当然，编译器会在各个重载的构造函数版本(如果有多个的话)搜寻，它找到的这个版本，发现声明参数与传入的对象一致，因此该构造函数将会被调用。目前为 止，一切都在我们的意料之中，但问题很快来了：该函数的参数我们使用了值传递的方式，按照前面的分析，这需要调用复制构造函数，于是编译器又再度搜寻，最 后当然又找到了它，于是进行调用，但同样地，传参时又要进行复制，于是再调用...这个过程周而复始，每次都是到了函数入口处就进行递归，直到堆栈空间耗 尽，程序崩溃...

    当 然，这样的好戏在现实中不大会出现，因为编译器会及时发现这一明显是问题的问题，并报告错误，终止编译；所以接下来我们还得想想其它办法。我们刚才之所以 没有获得想当然的成功是由于在传参时出现了复制构造函数的调用--而这本来就是它需要解决的操作--从而产生无穷递归。由是观之，值传递看来是行不通的 了；我想C语言的用户这时很快会反应到与值传递对应的方式：地址传递(传址)，于是声明变为这样：

    IntArray(IntArray *p);

    只作为一般的构造函数，它应该可以运行得很好，但别忘了我们要提供的是复制构造函数，它要求能够接受一个同类型对象，像这样：

    IntArray a;

    ... // 对a操作

    IntArray b(a);

    而不是接受指针：

    IntArray a;

    ... // 对a操作

    IntArray b(&a);  // 还要取地址？当然，它可以正确运行，但...

    否则，虽然在初始化对象时可以像上面一样人为加一个取址符，但在函数参数表中(或者函数返回)进行值传递时，编译器可不知道在找不着合适定义的情况下牵就选择你的指针版本。

    既然复制构造函数括号里放的必须是某个对象，但又不能通过值传递，也不能通过传址代替，解决的方案，我想你一定早想到了。没错，就是使用引用：

    IntArray(IntArray& a);

    由于引用产生的只是一个别名，而实质上使用的还是“原来的”被引用的对象，所以，当然，嗯，也就不会存在什么参数复制的问题，从而不会再去调用复制构造函数--也就是它自己！

    成功之后我们再来看看能不能再做一些改进：我们在复制对象的过程中，当然，从语义上说，一般不会改变被复制的“母体对象”的值。我们难以想象，诸如：

    Complex b(a);

的语句过后，会使复数a 变得面目全非；同时，假如“母体对象”是const类型，将意味着我们不能用它来初始化其它对象：因为参数IntArray& a不能保证a不会被修改！将const常量传给非const引用会导致编译出错，但这个限制显然并非我们所要的；并且，我们有可能不小心的情况在复制构造 函数中修改了本不希望改动的“母体对象”，而这一切将很难在今后查出。综上所述，我们通常会给复制构造函数的引用参数前加上const进行修饰：

    IntArray(const IntArray& a);

    这样一来就更完美了，它避免了上述的问题；而且即使是非const的对象也可以作为const型的引用(如前文所分析，反过来就不可以)。

    3.定义的实现

    好， 我们已经找到了复制构造函数的一个合适的参数，对于声明的讨论也就告一段落了。现在我们还是以IntArray为例，来看看它的实现应当是什么样子。如果 你读过《构造函数(上)》，那么还记得上一节开头我所给出的有关IntArray的声明么？如果你的回答是Yes，那么我很佩服你的用心，不过我自己是记 不得了，为了我自己，以及那些同我一样的朋友和暂时没有读过上节内容的朋友，我把上一节的IntArray主要部分声明粘贴如下(其实很简单)：

class IntArray

{

public:

    ... // others

private:

    int *_p;

    int _size;

};

    如 你所推测，IntArray使用整型指针_p存储在自由存储区上以new表达式分配得来的内存空间的首地址，而_size则存放该空间可以容纳的整型元素 的个数，换句话说，它也就代表了数组的尺寸。以机器的观点，在IntArray中，_p和_size是标识两个IntArray对象是否相同的特征变量 (我们假设pulic区段所声明的都是成员函数，而没有成员变量)，但从我们对数组概念上的理解，_size和_p所指的内存中元素是否均对应相同，才是 数组相同的意义；换言之，_size和_p所指的内存的内容(而不是_p存储的地址值)才是构成我们“概念理解上”的数组的信息。因而在进行复制的时候， 基于尊重“概念抽象”的观点，应当对_p所指的内存空间进行复制，而不是简单地复制_p本身。这就是我们在自定义的复制构造函数中所要表明的；下面是一个 可能的定义，我把分析放在注释部分：

    IntArray(const IntArray& a)

    {

        _size = a._size;  // 我们显示定义了复制构造函数之后，默认构造函数就不存在了，

                          // 所以必须自己实现所有必要的成员变量的复制

        if (_size > 0)    // 只有a的尺寸大于0，也就是a有内容时，才需要复制

        {

             _p = new int[_size];  // 构造函数总是在创建新对象时调用，所以别忘了分配内存

             for (int i = 0; i < _size; ++i)  // 逐个复制a中的内容

                 _p[i] = a._p[i];

         }

         else

             _p = 0;     // 安全起见，我们把零内容数组的指针设为0

    }

    嗯， 再补充一点。如果你的程序非常在意效率，那么你可以用诸如memcopy()的内存拷贝函数把整块a._p所指的内存复制过来，一般这样会比使用循环快一 些。不过在C++中对这个函数的使用不是不需要经过慎重考虑的：和相当部分的默认复制构造函数一样，它只是简单机械地拷贝内存，所以你如果将此函数应用在 诸如IntArray的对象上，以希望“有效率地”拷贝多个IntArray对象，那么几乎一定会出现问题：它不会知道应该拷贝_p所指的内容，因而将产 生前面所说的种种问题；甚至我们显式定义了IntArray的复制构造函数，它也不会调用--因为你使用它就意味着你要求的是“位拷贝”，而不是“复制构 造”。所以，在C++中，只有当memcopy应用在内置基本类型上时，我才敢保证它是安全的。当然，如果你把握不准，那么在C++中把这个C时代遗留下 来的函数忘了不失为一个很好的对策。

    4.组合或继承情况下的复制构造

    不知你注意到没有，我刚刚说memcopy()的机械拷贝只是和“相当部分”的默认复制构造函数一样，呃，应当反过来说，只是“相当部分”的默认复制构造函数采用“位拷贝”模式。咦，难道还有某种神秘的力量在控制着另一种默认复制构造函数？

    先考虑以下例子：假如我现在要设计一个类，不妨叫A，它包含了一个IntArray对象作为其中一个成员，当然，这是不奇怪的，像这样：

class A

{

public:

    ... // others

private:

    IntArray _array; // that's it

    ... // others

};

    然后我的代码中出现了A的对象的复制构造，这也是很有可能的，像这样一个函数：

A dosomething(A a)

{

    ...      // 一些操作

    A b(a);  // 以a复制构造出b

    ...

    return b;

}

    以 上的片断就隐含了三个关于A对象的复制构造(你看得出来吗？)，但如果我没有为A定义复制构造函数，如前面所说，编译器当然就会建立一个默认复制构造函 数，然后在需要的时候调用它。问题在于，这个默认复制构造函数假如还是傻呵呵地采用简单的位拷贝，那至少可以断定我们的_array成员将遭遇不测。当 然，你或许会责怪我没有为A添置一个复制构造函数，但我可以说，而且是很有理由地辩解说，class A的其余成员并不需要提供复制构造函数，至于IntArray类型成员，我只是这个类的用户，它封装好的内部机制不应当由我负责，事实上我也无从负责：即 使我真的愿意专门为之设计一个复制构造函数，我又该怎么实现呢？作为用户，我得到的只是IntArray的接口，也就是说我只有权利使用它，而无法关心也 不该它内部是怎样运作的，而复制构造函数通常需要涉及上述内容。

    作 为一门成功的语言，C++当然不能允许存在上述的尴尬。事实上，假如一个类存在需要调用(用户定义的，可能是间接的)复制构造函数的成员对象，而类本身又 没有提供复制构造函数，则其默认构造函数不是简单地采用位拷贝模式，而是将其对象“逐一”分别拷贝，对于需要调用复制构造函数的对象，则进行相应的调用， 以保持复制构造的概念上的意义。

    对于继承的情况也是类似，假如有一个SuperIntArray类继承至IntArray：

class SuperIntArray: public IntArray

{

public:

    ... // something

private:

    ... // something

};

    即使SuperIntArray本身没有提供复制构造函数，在其对象需要复制构造时，对基类IntArray部分的构造，同样也会调用IntArray(const IntArray&)来实现。

    嗯，如果前面所提到的组成与继承的情况中，新的类型显示提供了复制构造函数，则相应成员，或者基类的复制构造函数也同样会被调用。实际上前一节我们提到构造函数时已经就这个问题讨论过了，所以这一部分基本上没有太多的新意：别忘了，复制构造函数只不过是构造函数的一种。

						
						
						
						#include"global.h"

/* Initialisation du module DEBUG pour les environnements
   ne permettant pas de consulter la ligne de commande  
   travers CLP.
*/
#defineDEBUGLINELENGTH 256

voiddbInit()
{
charbuffer[DEBUGLINELENGTH];
FILE *db;

stdebug=stderr;
memset(buffer,0,DEBUGLINELENGTH);

db=fopen(".dbfile","r");
if (db) {
/* open the debug output device */
fgets(buffer,DEBUGLINELENGTH,db);
buffer[strlen(buffer)-1]=0;
if (!(stdebug=fopen(buffer,"w"))) 
stdebug=fopen("/dev/null","w");
/* open the debug INPUT device */
fgets(buffer,DEBUGLINELENGTH,db);
buffer[strlen(buffer)-1]=0;
if (!(stdbin=fopen(buffer,"r"))) 
stdbin=fopen("/dev/null","r");

fclose(db);
  }
elsestdebug=fopen("/dev/null","w");


db=fopen(".dblevel","r");
if(db) {
fgets(buffer,DEBUGLINELENGTH,db);
DbLvl=atoi(buffer);
fclose(db);
  }


db=fopen(".dbmask","r");
if(db) {
fgets(buffer,DEBUGLINELENGTH,db);
DbMsk=atoi(buffer);
fclose(db);
  }