安装向导
0. 下载 CPPUnitProjectWizard
    http://cppunit.sourceforge.net/cppunit-wiki/CppUnitVisualStudio2005Wizard?action=AttachFile&do=get&target=CPPUnitProjectWizard.7z

1. 复制文件
     CPPUnitProjectWizard.vsdir  - 为向导命名
     CPPUnitProjectWizard.vsz    - 让VS8知道从哪里找到向导
    到您的Visual Studio 8安装目录下的 VSProjects 文件夹中。
   
2. 把整个CPPUnitProjectWizard解决方案文件夹复制到您的Visual Studio 8安装目录下的VCWizards文件夹中。
   比如，我放在c:\Program Files\Microsoft Visual Studio 8\VC\VCWizards\CPPUnitProjectWizard\CPPUnitProjectWizard
   或者，也可以放在你想放置的其它地方，然后编译CPPUnitProjectWizard.vsz，定义参数 ABSOLUTE_PATH
   Param="ABSOLUTE_PATH = c:\Program Files\Microsoft Visual Studio 8\VC\VCWizards\CPPUnitProjectWizard\CPPUnitProjectWizard"
  
3. 该项目需要定义环境变量 CPPUNITDIR
   比如，我的环境变量  %CPPUNITDIR% = D:\cppunit-1.12.0
   最后，修改 环境变量 %PATH%,在PATH路径中，增加 %CPPUNITDIR%/lib，以便程序加载时能找到 cppunit_dll.dll
4. 在开发环境中，设置好Include/Lib路径
    %CPPUNITDIR%\Include
    %CPPUNITDIR%\LIB
   

以塌实编码为荣 以心浮气躁为耻

以详细注释为荣 以注释残缺为耻

以勤于测试为荣 以懒于测试为耻

以简明文档为荣 以冗余文档为耻

以注重团队为荣 以孤傲自大为耻

以刻苦钻研为荣 以敷衍了事为耻

以善于总结为荣 以不思进取为耻

以质效并进为荣 以单取其一为耻

这里，以流水帐的方式，作一起笔录。

关于用例：

1. 用例即是需求，但需求并不是用例。
   用例是描述讨论的系统(SuD)功能性需求的，所以可以说用例就是需求。但需求除了功能性需求，还有非功能性需求。所以，不能说需求就是用例。

2. 用例不等于功能
   用例是描述系统功能的，但用例不是功能。功能是系统要达到或满足的目标，用例是用例的执行者(Actor)与系统交互的操作序列。两者是有差异的。

3. 用例是文本而不是图形
   用例是描述执行者与系统交互的操作序列，要体现它的执行者在与系统交互产生的可观查的价值。图形仅仅是用例的概述，只画图是不够的。由于这一点，用例建模是撰写文档的过程，而不是画图的过程。

4. 用例模型不仅仅是小人加随圆
   用例模型不仅是需求方面的工件(artifact)，它还包括补充说明(描述非功能需求的)，词汇表，愿景和业务规则。这些合在一起才是需求分析的产物。

5. 用例技术无须对象技术，在通过用例发现，描述，管理需求的时候，用不到对象技术。但是，用例是面向对象的分析和设计的关键需求。

6. 用例必须有一个主执行者 (Primary actor)
   主执行者确定了用例的名称。用例命令通常是以主执行者视角的主动语态的运宾结构的短语。因为只有这样的短语才能充分的描述出系统的价值。用例建模的核心就是要描述出系统的价值。

7. 三种类型的执行者
   基本执行者 (Primary actor)  :这种用例通过与系统交互能达到目标
   支持执行者 (Supporting actor ) : 为讨论的系统（SuD)提供服务
   幕后执行者 (Offstage actor ) :除了上述两种，又对上述两种执行者与系统交互过程和结果感兴趣的人或物。

• AFAICS = As far as I can see
• BTW = By the way
• FWIW = For what it's worth
• FYI = For your information
• HAND = Have a nice day
• IMHO = In my humble opinion (egoless)
• IMAO = In my arrogant opinion (oodles of ego)
• IMNSHO = In my not-so humble opinion (a lot of ego)
• IMO = In my opinion (not much ego)
• KUTGW = Keep up the good work
• MYOB = Mind your own business
• OO = Object-oriented
• OTOH = On the other hand
• PEBCAC = Problem exists between chair and computer
• PEBCAK = Problem exists between chair and keyboard
• PMFJI = Pardon me for jumping in
• RTFM = Read the ___ manual
• SO = Significant other (as in, "My SO and I went for a walk...")
• SSO = Small String Optimization (where short strings don't use the heap)
• YHBT = You have been trolled
• YHL = You have lost

译者：小刀人

原文链接：What static_cast<> is actually doing

本文讨论static_cast<> 和 reinterpret_cast<>。

介绍
大多程序员在学C++前都学过C，并且习惯于C风格（类型）转换。当写C++（程序）时，有时候我们在使用static_cast<>和reinterpret_cast<>时可能会有点模糊。在本文中，我将说明static_cast<>实际上做了什么，并且指出一些将会导致错误的情况。

泛型（Generic Types）

        float f = 12.3;

        float* pf = &f;
      
// static cast<>

        // 成功编译, n = 12

        int n = static_cast<int>(f);

        // 错误,指向的类型是无关的（译注：即指针变量pf是float类型，现在要被转换为int类型）
        //int* pn = static_cast<int*>(pf);

        //成功编译

        void* pv = static_cast<void*>(pf);

        //成功编译, 但是 *pn2是无意义的内存（rubbish）

        int* pn2 = static_cast<int*>(pv);
// reinterpret_cast<>

        //错误,编译器知道你应该调用static_cast<>

        //int i = reinterpret_cast<int>(f);

        //成功编译, 但是 *pn 实际上是无意义的内存,和 *pn2一样

        int* pi = reinterpret_cast<int*>(pf);

class CBaseX

      {

      public:

      int x;

      CBaseX() { x = 10; }

      void foo() { printf("CBaseX::foo() x=%d\n", x); }

      };
      
class CBaseY

        {

        public:

        int y;

        int* py;

        CBaseY() { y = 20; py = &y; }

        void bar() { printf("CBaseY::bar() y=%d, *py=%d\n", y, *py); 
        }

        };
class CDerived : public CBaseX, public CBaseY

        {

        public:

        int z;

        };

      // Convert between CBaseX* and CBaseY*

      // CBaseX* 和 CBaseY*之间的转换

      CBaseX* pX = new CBaseX();

      // Error, types pointed to are unrelated

      // 错误， 类型指向是无关的

      // CBaseY* pY1 = static_cast<CBaseY*>(pX);

      // Compile OK, but pY2 is not CBaseX

      // 成功编译, 但是 pY2 不是CBaseX

      CBaseY* pY2 = reinterpret_cast<CBaseY*>(pX);

      // System crash!!

      // 系统崩溃!!

      // pY2->bar();

      1. CDerived* pD = new CDerived();

      2. printf("CDerived* pD = %x\n", (int)pD);

      3. 

      4. // static_cast<> CDerived* -> CBaseY* -> CDerived*

      //成功编译，隐式static_cast<>转换

      5. CBaseY* pY1 = pD;

      6. printf("CBaseY* pY1 = %x\n", (int)pY1);

      // 成功编译, 现在 pD1 = pD

      7. CDerived* pD1 = static_cast<CDerived*>(pY1);

      8. printf("CDerived* pD1 = %x\n", (int)pD1);

      9. 

      10. // reinterpret_cast

      // 成功编译, 但是 pY2 不是 CBaseY*

      11. CBaseY* pY2 = reinterpret_cast<CBaseY*>(pD);

      12. printf("CBaseY* pY2 = %x\n", (int)pY2);

      13. 

      14. // 无关的 static_cast<>

      15. CBaseY* pY3 = new CBaseY();

      16. printf("CBaseY* pY3 = %x\n", (int)pY3);

      // 成功编译,尽管 pY3 只是一个 "新 CBaseY()"

      17. CDerived* pD3 = static_cast<CDerived*>(pY3);

      18. printf("CDerived* pD3 = %x\n", (int)pD3);

      ---------------------- 输出 ---------------------------

      CDerived* pD = 392fb8

      CBaseY* pY1 = 392fbc

      CDerived* pD1 = 392fb8

      CBaseY* pY2 = 392fb8

      CBaseY* pY3 = 390ff0

      CDerived* pD3 = 390fec

注意：在将CDerived*用隐式 static_cast<>转换到CBaseY*（第5行）时，结果是（指向）CDerived*（的指针向后） 偏移了4（个字节）（译注：4为int类型在内存中所占字节数）。为了知道static_cast<> 实际如何，我们不得不要来看一下CDerived的内存布局。

CDerived的内存布局（Memory Layout）



如图所示，CDerived的内存布局包括两个对象，CBaseX 和 CBaseY，编译器也知道这一点。因此，当你将CDerived* 转换到 CBaseY*时，它给指针添加4个字节，同时当你将CBaseY*转换到CDerived*时，它给指针减去4。然而，甚至它即便不是一个CDerived你也可以这样做。
当然，这个问题只在如果你做了多继承时发生。在你将CDerived转换 到 CBaseX时static_cast<> 和 reinterpret_cast<>是没有区别的。

情况3：void*之间的向前和向后转换

因为任何指针可以被转换到void*，而void*可以被向后转换到任何指针（对于static_cast<> 和 reinterpret_cast<>转换都可以这样做），如果没有小心处理的话错误可能发生。

    CDerived* pD = new CDerived();

        printf("CDerived* pD = %x\n", (int)pD);
    CBaseY* pY = pD; // 成功编译, pY = pD + 4

        printf("CBaseY* pY = %x\n", (int)pY);
      void* pV1 = pY; //成功编译, pV1 = pY

        printf("void* pV1 = %x\n", (int)pV1);
         // pD2 = pY, 但是我们预期 pD2 = pY - 4

        CDerived* pD2 = static_cast<CDerived*>(pV1);

        printf("CDerived* pD2 = %x\n", (int)pD2);

        // 系统崩溃

        // pD2->bar();

        ---------------------- 输出 ---------------------------

        CDerived* pD = 392fb8

        CBaseY* pY = 392fbc

        void* pV1 = 392fbc

        CDerived* pD2 = 392fbc

一旦我们已经转换指针为void*，我们就不能轻易将其转换回原类。在上面的例子中，从一个void* 返回CDerived*的唯一方法是将其转换为CBaseY*然后再转换为CDerived*。
但是如果我们不能确定它是CBaseY* 还是 CDerived*，这时我们不得不用dynamic_cast<> 或typeid[2]。

注释：
1. dynamic_cast<>，从另一方面来说，可以防止一个泛型CBaseY* 被转换到CDerived*。
2. dynamic_cast<>需要类成为多态，即包括“虚”函数，并因此而不能成为void*。
参考：
1. [MSDN] C++ Language Reference -- Casting
2. Nishant Sivakumar, Casting Basics - Use C++ casts in your VC++.NET programs
3. Juan Soulie, C++ Language Tutorial: Type Casting

在您维护安全类型和避免集成电路般函数时,你可以使用C++的强大的力量进行消息传递。

Anthony是Just Software Solution有限公司的一位软件开发者和执行管理者。可以通过anthony@justsoftwaresolutions.co.uk与之联系。

使用通用的消息传递方式传递数据在C++程序中很普遍。这种技术经常用于在线程间以及从/到GUI组件间传递数据。但是消息传递仍然很难实现得良好，这是因为在常见的消息传递方式中，暴露出了过多的藕合、缺少类型安全和集成电路般的消息处理函数。

在本文中，我提出了一种技术，这种技术利用C++的强大力量来避免上述缺陷——在消息传递中避免不适当的藕合，维护类型安全，以及消除集成电路般的消息处理函。( The only translation units that need to known the details of a message are those containning the source and handler functions for that specific message type.) 需要转换的单元，即需要知道的消息详细内容是包含了特定消息的类型的源代码和处理函数。

传统技术

大概应用得最为广泛的消息传递技术是使用一个带有特殊成员来表示消息类型的结构体，该消息类型是消息的标识。这种方式被广泛应用归咎于使用了基于C的API，比如X11和Microsoft Windows。在这种方法中，消息结构体中要么有一个通用的字体用于区别不同消息的意义，这个字段可被所有消息重用，或者它是更大结构的第一个成员，它的类型由类型代码来确定。Windows API使用前面的技术，而X11使用后面的方法。无论用哪种方式，处理消息的代码都须检查类型编码，用以决定怎么处理该消息。

这些技术的问题是:缺乏类型安全，集成电路般的处理函数，需要管理类型编码来确保消息唯一性的适当层次。特别的，缺乏类型安全意味着使用之前，使用代码必须把消息数据转换成适当的类型。这一步是极易出错的，尤其在当复制和粘贴代码时(这种非常的手段常发生在为处理相似消息编写代码的时候)，编译器不会在这种错误给出任何警告。

缺乏类型安全还有一个额外的问题——即它不可能简单有效的通过消息系统传递资源或变长的数据， 这是因为消息的发送方总是不能知道何时（或是否）该消息已被处理过了。

在这部分，集成电路般的消息处理函数是必须用于确定消息类型的产物，通过已接收的消息来消息类型，然后得到如何处理它的方式。这种处理函数往往实现为一个很大的switch语句或是一串if eles if。一些框架，如MFC，提供一些宏来减弱这种问题的影响，它这不能完全消除这个问题。

最后的问题是管理类型代码。它必须要求接收消息代码清楚地知道是哪一个消息，以便于正确的处理它。所以，类型代码需要在处理它的相关代码中确保唯一性。比如，在Windows API中，指定范围的消息类型在不同的应用程序中代表不同的意义，并且，在同一个应就用程序中，其它范围的消息类型在不同窗口或GUI组件中代表不同的意义。 通常,需要所有类型代码的列表，该列表要求在给定的范围中保持唯一，以便于检查它们的唯一性。列表常常是以头文件的形式给出，头文件中定义了类型代码，包含在需要知道消息类型的所有地方。这种方式容易导致应用程序不同部分之间的藕合,而这些部分之间却没有任何关系。由于这种过度的藕，简单的变更导致过多的重新编译。

面向对象技术

对象技术的一个常见特征是所有相关消息类派生自一个通用的基类。该特征用编译器能认识的真实类型代替了显式的类型代码。不仅如此，它还有了一个重要的，超越C风格技术的优点——类型安全。它提供的通用基类的析构函数是虚函数，所以派生的消息类能自由地管理资源，如变长的数据，这些数据可以在析构函数中释放。仅有的需求是接受消息的代码能正确地销毁消息对象，无论它们是否被处理。

管理类型代码现在被替换为管理类。这是一个更加简单的任务，由于可能的消息名字的范围是没有限制的，可能存在名字冲突，但这一点可以通过名字空间来解决。

保持简单

最简单的OOP技术就是用dynamic_cast检查实际的消息类型代替检查消息编码。然而，这依然面临着集成电路般地消息处理方式——现在通过包括dynamic_cast的比较链也优于通过类型编码字段比较链。如列表1:

void  handleMessage(Message *  message)
{
     if (Message1 *  m = dynamic_cast < Message1 *> (message))
     {
        handleMessage1(m);
    }
     else   if (Message2 *  m = dynamic_cast < Message2 *> (message))
     {
        handleMessage2(m);
    }
     //  
}

[列表1]

一般而言，由于仅仅是消息的源代码和接受消息的源代码需求知道相关的消息，所以依赖得到降低。然后，集成电路般地处理函数现在需要知道消息的有关细节，所以dynamic_cast需要消息的完整定义——如果分派给另外的函数处理实际的消息，C风格技术的处理函数不需求知道消息的细节。

双重分派

(Direct testing of a class's type using dynamic_cast is generally indicative of a design problem;)类的类型用dynamic_cast的直测试一般可表示为设计问题;然而，简单地把虚函数放在消息类中起不到任何作用——它将把消息处理与消息缠绕在一起，这个消息使在第一个地方发送消息的目的失败。

双重分派的关键点是，在消息类中的虚函数带有一个作为参数的处理器，然后在处理器上把自已作为参数传递传递给另一个函数并完成调用。因为这里的第二次到处理器的回调已经在实际的派生类中完成，所以真实的消息类型已经知道，在处理器上能调用适当的函数，无论这个函数是通过重载的方式实现还是另外独立命名的函数来实现(列表2)。

[列表2]

依赖于重载的方式来区别不同的消息有利于大多数平衡——现在在每个消息类中虚函数的实现方式是相同的，如果需要，可以通过宏来一致地包装，或通过从一个消息到另一个消息中直接复制，不会有出错的机会。

双重分派存在一个缺点——高度藕合。由于通过重载方式在处理器类中的选择处理函数，在消息类中虚函数的实现需要知道处理器类的定义的全部，因此必须注意到在系统中每个其它的类的名字。不光这些，如果要支持不同的处理器类，处理函数必须在通用的处理器的基类中声明为虚函数，所以每个处理器类必须在系统中注意到所有的消息类型(列表3)。增加或删除一个消息类型会引起应用程序大部分代码重新编译。

class  MessageHandler
{
     virtual   void  process(Message1 * ) = 0 ;
     virtual   void  process(Message2 * ) = 0 ;
     virtual   void  process(Message3 * ) = 0 ;
     virtual   void  process(Message4 * ) = 0 ;
     //  overloads of process for other messages
} ;
class  SpecificMessageHandler:
     public  MessageHandler
{
     void  process(Message1 * );
     void  process(Message2 * );
     void  process(Message3 * );
     void  process(Message4 * );
     //  overloads of process for other messages
} ;
class  OtherSpecificMessageHandler:
     public  MessageHandler
{
     void  process(Message1 * );
     void  process(Message2 * );
     void  process(Message3 * );
     void  process(Message4 * );
     //  overloads of process for other messages
} ;

[列表3]

动态双重分派

（It was against this backdrop that I developed the technique I call "Dynamic Double Dispatch."）我开发了一种技术，我称其为“动态双重分派”，这种技术用于解决上述问题。尽管有基本的双重分派技术，但选择的消息处理函数使用的是在编译阶段确定的重载技术(尽管发现在正确的消息处理器类中的实现是使用虚函数机制),而动态双重分派是在运行时检查在处理器上适当的处理函数的。结论是动态双重分派消除了双重分派的依赖问题。消息类型不在需要注意到其它的消息类型，并且处理器类仅需要注意到它的它要处理的消息。

动态检查的关键点是：每一个消息类型有一个独立的基类——处理器类从适当的，设计为处理消息的基类派生。然后在每个消息类中的分派函数能用dynamic_cast来检查从正派基类派生的处理器类，因而实现了正确的处理函数。(列表4)

class  MessageHandlerBase
{};
class  Message1HandlerBase:
     public   virtual  MessageHandlerBase
{
     virtual   void  process(Message1 * ) = 0 ;
};
class  Message1
{
     void  dispatch(MessageHandlerBase *  handler)
    {
        dynamic_cast < Message1HandlerBase &> ( * handler).process( this );
    }
};
class  Message2HandlerBase:
     public   virtual  MessageHandlerBase
{
     virtual   void  process(Message2 * ) = 0 ;
};
class  Message2:
     public  MessageBase
{
     void  dispatch(MessageHandlerBase *  handler)
    {
        dynamic_cast < Message2HandlerBase &> ( * handler).process( this );
    }
};
//  
class  SpecificMessageHandler:
     public  Message1HandlerBase,
     public  Message2HandlerBase
{
     void  process(Message1 * );
     void  process(Message2 * );
};
class  OtherSpecificMessageHandler:
     public  Message3HandlerBase,
     public  Message4HandlerBase
{
     void  process(Message3 * );
     void  process(Message4 * );
};

[列表4]

(Of course, having a completely separate handler base class for each message type would add excessive complication, as the dispatch function for each message type would now be specific to that message type, and the base classes would have to be written separately, despite being fundamentally the same, except for the message type they referenced.)
诚然，为每个消息类型分别编写的处理器基类将增加过多的复杂性，同样地，每个消息类型各自的分派函数现在需要特别指定，基类也需求分别编写,然后除了它们引用的消息类型外基础是相同的。消除这种重复的关键是使基类成为模板，用消息类型作为模板参数——分派函数引用到模板的实现好于指定类型；请看列表5。

[列表5]
出于简化原因，在消息类中的分派函数几乎相同，但也不是完全相同——它们必须明确的指定属于它们的指定消息类，以便于转换为适当的处理器基类。像软件中许多事情一样，这个问题可以增加一个额外的层来解决——分派函数可以委托给单个模板函数，这个模板函数使用模板参数类型来确定消息类型和把处理器转换到适当的类型上。(列表6)

[列表6]

通过进一步抽象在消息对象中分派函数的不同之处,我们把工作集中到一个地方——模板函数的定义；它提供了为修改行为的单一点。在消息类中剩下的分派函数都是相同的，这足以把它们简化到隐藏细节的宏中或在消息类之间中逐字复制。

未处理的消息

迄今为止，我们展示的 dynamicDispach模板函数的代码假定处理的类是从适当的SpecificMessageHandler是派生的；如是不是这样， dynamic_cast将抛出std::bad_cast异常。有时这就足够了，但是有的时候，有更适当的行为——也许更好的做法是抛弃消息，这不能被接受消息的代理处理或调用catch-all处理器。举例来说，dynamicDispatch 函数能被调整，用基于指针的转换代替基于引用的转换，所以结果值可以与NULL进行测试。

缺点(Trade-Off)在哪里？
有如此多的优点，一定存在它的缺点，那它的缺点在哪里呢？在这里，有两个缺点。第一个是：额外的动态转换，两个虚函数调用会影响性能。如果性能上是一个问题，这就是一个疑问，但是，在很多情况下，花销在这里的额外的时间是不值得关注的。可以使用相应的工具来签定到底哪里才是真正的性能瓶颈所在。

第二个缺点是:需要为每个消息处理从指定的基类派生消息处理器。因为处理新的消息类型需要修改两个地方——适当的基类列表入口和处理函数，所以这可能成为错误的来源，遗失处理函数容易被发现，因为这是全局点，但是遗失基类在代码运行时只产生不易查觉的缺陷。因为没有处理函数的时候仅仅是不调用它。这些错误在单元测试的时候是很容易被抓出来的，所以所实话，这些不便之处都成不了大问题。

#pragma once
#include  < iostream >
using   namespace  std;
class  Base
{
public :
  Base( void );
   ~ Base( void );
public :
   virtual   void  print(ostream &  output)  =   0 ;
  friend ostream &   operator   << (ostream &  output,Base &  obj);
private :
   char *  name_;
   int  age_;
} ;

#include "StdAfx.h"
#include ".\base.h"

Base::Base(void)
{
  name_ = "This is data1";
  age_ = 18;
}

Base::~Base(void)
{
}

void Base::print(ostream& output)
{
  output<<"name = " <<name_<<endl;
  output<<"age = "<<age_<<endl;
}

ostream& operator<<(ostream& output,Base& obj)
{
  obj.print(output);
  return output;
}

#pragma once
#include "Base.h"
class Derived :public Base
{
public:
  Derived(int score = 80);
  ~Derived(void);
  virtual void print(ostream& output);
private:
  int score_;
};

#include "StdAfx.h"
#include ".\derived.h"

Derived::Derived(int score):score_(score)
{
  
}

Derived::~Derived(void)
{
}

void Derived::print(ostream& output)
{
  Base::print(output);
  output<<"score = "<<score_<<endl;
}

// Test_VirtualFirendFunction.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <iostream>
#include "Derived.h"
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
  Derived  d;

  Derived  d2(90);
  cout<<d<<endl<<d2<<endl;
    return 0;
}

name = This is data1
age = 18
score = 80

name = This is data1
age = 18
score = 90

结果：
任何从Base派生类的，都可以利用cout<<obj的机制通过流进行输出。

同样道理，也可以利用此方法实现ACE_InputCDR  / ACE_OutputCDR对网络操作序列化操作。
(本文也是回答某网友关于派生类不能重载的问题的回复)

以下是我的回贴:

你这个问题还真有趣,我跟踪了ACE相关代码后才发现,问题原来出在你写的函数中,病因是,使用未完全初始化的结构体变量

timespec_t spec_t;
后面加上语句
memset( &spec_t ,0,sizeof(timespec_t));
即可

局部变量 spec_t 在debug时,各字段均被初始化为0xCCCCCCCC,它是一个负数
在下面的操作中,只修改了tv_sec,而tv_nsec 仍为一个负数
spec_t.tv_sec=mktime( &time_tm ); 


ACE_Time_Value::normalize()默默地为你作了规格化处理，就替你减去了一秒钟。

原代码更严重的错误在于：
原以为 Release版本是“正常”的，其实不然，而是Release隐藏了更严重的错误。
严重是因为它表现出错误的时候很随机，一旦产品发布，很难发现。

// 对象(结构体)timespec有两个公有属性
 typedef  struct  timespec
      {
       time_t tv_sec;  //  Seconds
        long  tv_nsec;  //  Nanoseconds, 十亿分之一秒
     }  timespec_t;
     

在原代码16行
timespec_t spec_t;
构造了一个 timespec_t  临时对象spec_t后,debug版把它各字段初始化为 0xcccccccc,这使得问题一下子得于曝光.而Release版本, spec_t 为一个随机值. 本例程中,不允许 spec_t的tv_nsec为非0的任何数,为正常尽管看上去没有问题,但是这个对应的ACE_Time_Value的值也不可靠.在特定情况下可能产生重大事故.

C++编码规范：
初始化对象时要完全。

声明一个结构体后，如果要对其初始化，建议先把它设为0之后再作后续操作，养成这样一个习惯，就不会出现这样郁闷的事了。


原贴出处:
http://www.huihoo.com/forum/viewthread.php?tid=11016


mooyee