一本久久综合亚洲鲁鲁五月天,久久久久亚洲AV成人网,亚洲乱码精品久久久久..

christanxw — Sun, 09 Apr 2006 12:38:00 GMT

http://blog.csdn.net/christanxw/archive/2006/04/09/656484.aspx

christanxw 2006-04-09 20:38 发表评论

A* 寻�\��法

christanxw — Fri, 07 Apr 2006 01:51:00 GMT

摘要: 原文地址�Q? http://www.gamedev.net/reference/articles/article2003.asp 概述虽然掌握�? A* ��法的�h认�ؓ它容易，但是对于初学者来��_�� A* ��法�q�是很复杂的�?... 阅读全文

christanxw 2006-04-07 09:51 发表评论

如何在编译时��d��可判断type T 是否包含member type X

christanxw — Wed, 30 Nov 2005 10:30:00 GMT

http://blog.csdn.net/christanxw/archive/2005/11/30/540364.aspx

christanxw 2005-11-30 18:30 发表评论

变态之MEMCPY

christanxw — Tue, 11 Oct 2005 03:02:00 GMT

void* mymemcpy( void* dest, const void* src, size_t count )
{
    char* d = (char*)dest;
    const char* s = (const char*)src;
    int n = (count + 7) / 8; // count > 0 assumed

    switch( count & 7 )
    {
    case 0: do { *d++ = *s++;
    case 7:        *d++ = *s++;
    case 6:        *d++ = *s++;
    case 5:        *d++ = *s++;
    case 4:        *d++ = *s++;
    case 3:        *d++ = *s++;
    case 2:        *d++ = *s++;
    case 1:        *d++ = *s++;
               } while (--n > 0);
    }

return dest;
}
�q�样也行�Q�真是长见识了~_~

int n = (count + 7) / 8;计算要复制的轮数�Q�每轮复�?位）�Q�剩下的余数位数也要复制�q�去�?BR>count & 7控制要复制余��C��敎ͼ�while (--n > 0)控制轮数�?BR>比如count = 9�Q�则n = 2�Q�count & 7 = 1�Q�要复制2轮，�E�序跛_��case1执行�Q�复制一位之后，再��@环一轮，复制8�?/P>

christanxw 2005-10-11 11:02 发表评论

Eric Raymond对于几大开发语�a�的评��P��转）

christanxw — Wed, 28 Sep 2005 01:04:00 GMT

Eric Raymond是开源运动的领袖人物�Q�对�?SPAN lang=EN-US>UNIX开发有很深的造诣�Q�主持开发了fetchmail。他的《大教堂与集市》被奉�ؓ开源运动的�l�典之作。下面对几大开发语�a�的评价非�怸�肯，是我�q�年来看到的比较��的评论。特别是他评价中抱有的那�U?SPAN lang=EN-US>�?/SPAN>��单就是好�?/SPAN>的思想�Q�很值得我们深思。我特别选译��Z��些段落，供大安��L��考。原文参见：http://www.catb.org/~esr/writings/taoup/html/ch14s04.html#c_language

C
    虽说C语言在内存管理方面存在严重的�~�陷�Q�不�q�它�q�是在某些应用领域里�U�王�U�霸。对于那些要求最高的效率�Q�良好的实时性，或者与操作�pȝ��内核紧密兌��的程序来��_��C仍然是很好的选择�?/FONT>
    C良好的可�U�L��性也为它加了分。不�q�现在很多其他的语言可移植性越来越好，C在这斚w��的优势可能会逐渐丧失�?/FONT>
    现有的很多程序可以��生非常棒�?SPAN lang=EN-US>C代码�Q�比如语法分析器�?SPAN lang=EN-US>GUI Builder�{�，�q�时�?SPAN lang=EN-US>C语言也是有吸引力的，因�ؓ你所需要编写的代码只是整个�E�序的一��部分�?/FONT>
    再有�Q�我们当然应该认识道�Q?SPAN lang=EN-US>C语言对于�E�序员来说具有无可替代的价倹{��就我这里讨论的每一�U�语�a�而论�Q�只要你发掘的��够深�Q�到最后你会看到它们的内核都是用纯正的、可�U�L��?SPAN lang=EN-US>C写成的�?/FONT>
    ��C��今天�q�个时候，我们最好把C看成�?SPAN lang=EN-US>UNIX虚拟��Z��的高�U�汇�~�语�a��?/FONT>
    ��q��是其他的高��语言完全可以满��你的工作需要，抽出旉��来学�?SPAN lang=EN-US>C语言也仍然有益，它能帮助你在��g体系的层�ơ上思考问题�?/FONT>
    即��C��今天�Q�最好的C语言教程仍然�?SPAN lang=EN-US>1988�q�出版的K&R�W�二�?/FONT>The C Programming Language.
    �ȝ��Q?SPAN lang=EN-US>C最��的地方在于其高效和脓(chu��ng)�q�机器，最�p�糕的地方在它的内存��理地狱�?/FONT>

    C++
    C++最初发布于1980�q�代中期�Q�当旉��向对象语�a�被认为是解决软�g复杂性问题的银弹�?SPAN lang=EN-US>C++的面向对象特性看相去使其全面��越�?SPAN lang=EN-US>C�Q�支持者认�?SPAN lang=EN-US>C++��迅速把上一代语�a�挤到陈列馆里厅R�?/FONT>
    但是历史�q��如此。究其原因，臛_��有一部分归咎�?SPAN lang=EN-US>C++本��n。�ؓ了与C兼容�Q?SPAN lang=EN-US>C++被迫作出了很多重大的设计妥协�Q�结果导致语�a��q�分华丽�Q�过分复杂。�ؓ了与C兼容�Q?SPAN lang=EN-US>C++�q�没有采用自动内存管理的�{�略�Q�从而��׃��修正C最严重问题的机会�?/FONT>
    另外一部分原因�Q�恐怕要��到面向对象�w�上。看��h��OO�q�没有很好的达成��Z��当年的预期。我��p��个问题调研过�Q�我发现使用OO�Ҏ(gu��)��D��l��g之间出现很厚的粘合层�Q��ƈ且带来了严重的可�l�护性问题。今天让我们来看看开放源码社区，你会发现C++的应用还是集中在 GUI�Q�游戏和多媒体工具包�q�些斚w��Q�在其他地方很少用到。要知道�Q�面向对象也只是在这些领域被证明非常成功�Q�而开放源码社区的选择�Q�很大程度上体现了程序员的自由意志，而不是公司管理层的胡乱指挥�?/FONT>
    也许C++实现OO的方法有问题。有证据表明C++�E�序在整个生命周期的开销高于相应�?SPAN lang=EN-US>C, Fortran�?SPAN lang=EN-US>Ada�E�序。不�q�，�I�竟�q�是否应该归咎与C++�?SPAN lang=EN-US>OO实现上，�q�不清楚�?/FONT>
    最�q�几�q�_��C++加入了很多非OO的思想�Q�其异常思想�c�M��Lisp�Q?SPAN lang=EN-US>STL的出现是非常了不��L��?/FONT>
    其实C++最�Ҏ(gu��)��的问题在于，它基本上只不�q�是另一�U�传�l�的语言�?SPAN lang=EN-US>STL中的内存��理比先前的new/delete�?SPAN lang=EN-US>C的方案要好的多，但是�q�是没有解决问题。对于很多应用程序而言�Q�其OO�Ҏ(gu��)��ƈ不明显，相比�?SPAN lang=EN-US>C�Q�除了增加复杂度之外没有获得很多好处�?/FONT>
    �ȝ��Q?SPAN lang=EN-US>C++优点在于作�ؓ�~�译型语�a��Q�把效率与泛型和面向对象�Ҏ(gu��)��结合�v来，其缺点在于过于华丽复杂，們֐�于鼓��q��q�分复杂的设计�?/FONT>

     Java
    Java的设计很聪明�Q�它采用了自动内存管理，�q�是最大的改进�Q�支�?SPAN lang=EN-US>OO设计带来的好处虽然不那么�H�出�Q�不�q�也很值得赞赏�Q�相�?SPAN lang=EN-US>C++�Q�其OO设计规模��而且��?�?/FONT>
    相对�?SPAN lang=EN-US>Python而言�Q?SPAN lang=EN-US>Java有一些明昄��p��。有些地方设计的�q�是太复杂，甚至有缺陗��?SPAN lang=EN-US>Java的类可见性和隐式scoping规则太复杂了�?SPAN lang=EN-US>Interface机制是�ؓ了避免多�l�承带来的问题而设计的�Q�但是要理解和��用它�q�是挺难。内部类和匿名类��D��令�h困惑的代码。缺乏有效的析构机制�Q��得除了内存之外的其他资源�Q�比如互斥量和锁�Q�管理�v来很困难�?SPAN lang=EN-US>Java的线�E�不可靠�Q�其I/O机制很强大，但是��d��一个文本文件却非常�J�琐�?/FONT>
    Java没有��理库版本的机制�Q�从而�Ş式上重蹈了了Windows DLL地狱的覆辙。在�c�M��应用服务器这��L��环境里，�q�引起了大量的问题�?/FONT>
    ��M��而言�Q�我们可以说除了�pȝ��~�程和对效率要求极高的程序之外，Java在大部分领域优于C++。经验表明，Java�E�序员似乎不太容易象C++�E�序员那��h��造过度的OO层，不过�?SPAN lang=EN-US>Java中这仍然是个严重问题�?/FONT>
    Java是否优于诸如Perl, Python�q�样的语�a��Q�我们还不是很清楚，很大�E�度上似乎跟�E�序规模有关。其擅长的领域基本上�?SPAN lang=EN-US>Python�怼��Q�在效率上无法跟C/C++相提�q�论�Q�在��规模的、大量��用模式匹配和�~�辑的项目里也无法匹�?SPAN lang=EN-US>Perl。在��项目里�Q?SPAN lang=EN-US>Java昑־��q�分强大了。我们猜��?SPAN lang=EN-US>Python更适合��项目，�?SPAN lang=EN-US>Java适合大项目，不过�q�一点�ƈ没有得到有力的证明�?/FONT>

    Python
    Python是一�U�脚本语�a��Q�可以与C紧密整合。它可以与动态加载的C库模块交换数据，也可以作为内嵌脚本语�a�而从C中调用。其语法�c�M��C和模块化语言的杂合，不过有一个独一无二的特征，��是以羃�q�来��定语句块�?/FONT>
    Python语言非常�q�净�Q�设计优雅，��h��的模块化�Ҏ(gu��)��。它提供了面向对象能力，但不��用户�q�行面向对象设计。其�c�d��pȝ��提供了强大的表达能力�Q�类�?SPAN lang=EN-US>Perl�Q�具有匿�?SPAN lang=EN-US>lambda表达式，�q�点又让Lisp黑客们感��C��切�?SPAN lang=EN-US>Python依靠Tk提供方便�?SPAN lang=EN-US>GUI界面开发能力�?/FONT>
    在所有的解释型语�a�里，Python�?SPAN lang=EN-US>Java最适合多名�E�序员以渐进方式协同开发大型项目。在很多斚w��Q?   Python�?SPAN lang=EN-US>Java要简单，它非帔R��合与构造快速原型，�q�一点��得它对于Java有独特优势：对于那些既不很复杂，又不要求高效率的�E�序�Q?SPAN lang=EN-US>Python十分合适�?/FONT>
   Python的速度没法�?SPAN lang=EN-US>C/C++相比�Q�不�q�在今天的高�?SPAN lang=EN-US>CPU上，合理��C��用�؜合语�a��~�程�{�略使得Python的上�q�弱点被有效地��I补。事实上�Q?SPAN lang=EN-US>Python几乎被认为是��L��脚本语言中最慢的一个，因�ؓ它提供了动态多态性。在大量使用正则表达式的��型��目�Q�它逊于Perl。对于微型项目而言�Q?SPAN lang=EN-US>shell�?SPAN lang=EN-US>Tcl可能更好�Q?SPAN lang=EN-US>Python昑־�太过强大了�?/FONT>
    �ȝ��Q?SPAN lang=EN-US>Python最��的地方在于，它鼓励清晰易�ȝ��代码�Q�特别适合以渐�q�开发的方式构造大��目。其�~�陷在于效率不高�Q�太慢，不但跟编译语�a�相比慢，��是跟其他脚本语�a�相比也显得慢�?SPAN lang=EN-US>

christanxw 2005-09-28 09:04 发表评论

christanxw — Sat, 24 Sep 2005 11:36:00 GMT

面向对象的语�a�诸如JAVA提供了Interface来实现接口，但C++却没有这样一个东西，��管C++通过�U�虚基类实现接口�Q�譬如COM的C++实现��是通过�U�虚基类实现的（当然MFC的COM实现用了嵌套�c�）�Q�但我们更愿意看��C��个诸如Interface的东�ѝ��下面就介绍一�U�解军_��法�?BR>
首先我们需要一些宏�Q?BR>

//
// Interfaces.h
//

#define Interface class

#define DeclareInterface(name) Interface name { \
          public: \
          virtual ~name() {}

#define DeclareBasedInterface(name, base) class name :
        public base { \
           public: \
           virtual ~name() {}

#define EndInterface };

#define implements public

有了�q�些宏，我们��可以这样定义我们的接口了：

//
// IBar.h
//

DeclareInterface(IBar)
virtual int GetBarData() const = 0;
virtual void SetBarData(int nData) = 0;
EndInterface

是不是很像MFC消息映射那些宏啊�Q�熟�(zh��n)�MFC的朋友一定不陌生�?BR>
现在我们可以像下面这��h��实现我们的接口了�Q?BR>

//
// Foo.h
//

#include "BasicFoo.h"
#include "IBar.h"

class Foo : public BasicFoo, implements IBar
{
// Construction & Destruction
public:
   Foo(int x) : BasicFoo(x)
   {
   }

   ~Foo();

// IBar implementation
public:
   virtual int GetBarData() const
   {
      // add your code here
   }

   virtual void SetBarData(int nData)
   {
      // add your code here
   }
};

怎么��P��很简单吧�Q��ƈ不需要做很多的努力我们就可以在C++中��用接口了。然而，�׃��q��ƈ不是语言本��n所直接支持的特性，所以我们需要遵循一些规则：
a) 声明一个类的时候，如果你的�c�除了要从接口类�l�承外还要从另一个类�l�承(�l�构上的�l�承�Q�即is a关系)�Q�则把这个类作�ؓ�W�一个基�c�，��像我们�q�x��做的一��P��譬如CFrameWnd从CWnd�l�承�Q?FONT face="Courier New">CBitmapButton从CButton�l�承�Q�CMyDialog从CDialong�l�承。当你要从MFC�c�L��生的时候，�q�尤光��要，把他们声明�ؓ�W�一个基�c�M��避免破坏MFC的RuntimeClass机制�?BR> b) 其他的基�cȝ��跟其后，有多��就跟多��，如果你需要的话。譬如：class Foo : public BasicFoo, implements IBar, implements IOther, implements IWhatever, ...
c) 接口�c�里面不要声明�Q何成员变量。接口类仅用于描�q�行��不是数据。当你要作多重��承时�Q�这样做可以避免数据成员被从同一个接口类多次�l�承�?BR> d) 接口�cȝ��所有成员函数定义�ؓ�U�虚函数。这可以��保你的实现�c�L��实现�q�些函数的全部，当然你也可以在抽象类实现部分函数�Q�只要在你的�z��c�里实现剩下的函数�?BR> e) 不要从除了接口类的其他�Q何类�z��你的接口�c�R�?FONT face="Courier New">DeclareBasedInterface()可以做到�q�个.普通类可以选择实现基接口还是派生的接口�Q�后面一�U�意味着两者都要实现�?BR> f) ��一个指向实现接口的�cȝ��指针赋值给一个指向该接口�cȝ��指针是不需要强制类型�{换的�Q�但反过来将一个接口类的指针赋值给一个实现该接口的类的指针就需要一个显式的强制�c�d��转换。事实上我们可能会��用多重��承，�q�样�q�些转换我们��׃��能��用老式的�{换。不�q��用运行时�c�d��信息(使用/GR选项)和动态类型�{换可以很好的工作当然也更安全�?BR> g) 此外dynamic_cast��Z��提供了一�U�查询一个对象或接口是否实现了一个指定的接口的途径�?BR> h) 你还要非常小心的避免不同接口函数的命名冲�H��?/FONT>

如果你仔�l�观�?FONT face="Courier New">DeclareInterface �?DeclareBasedInterfaca宏你会发现有一个操作是必须的：每个接口�c�都有一个虚析构函数。你可能认�ؓ�q�不重要�Q�但是如果没有这个就可能会导致一些问题，看看下面的例子：

DeclareInterface(IBar)
   virtual LPCTSTR GetName() const = 0;
   virtual void SetName(LPCTSTR name) = 0;
EndInterface

class Foo : implements IBar
{
// Internal data
private:
   char* m_pName;

// Construction & Destruction
public:
   Foo()
   {
      m_pName = NULL;
   }

   ~Foo()
   {
      ReleaseName();
   }

// Helpers
protected:
   void ReleaseName()
   {

      if (m_pName != NULL)
         free(m_pName);
   }

// IBar implementation
public:
   virtual const char* GetName() const
   {
      return m_pName
   }

   virtual void SetName(const char* name)
   {
      ReleaseName();
      m_pName = _strdup(name);
   }
};

class BarFactory
{
public:
   enum BarType {Faa, Fee, Fii, Foo, Fuu};

   static IBar CreateNewBar(BarType barType)
   {
      switch (barType)
      {
         default:
         case Faa:
            return new Faa;
         case Fee:
            return new Fee;
         case Fii:
            return new Fii;
         case Foo:
            return new Foo;
         case Fuu:
            return new Fuu;
      }
   }
};

��像你看到的一��P��q�里有一个类工厂�Q�它�Ҏ(gu��)��BarType来创��Z��个IBar的实玎ͼ�当你使用完以后你当然希望要delete该对象，你会像下面这样做�Q?BR>

int main()
{
   IBar* pBar = BarFactory::CreateBar(Foo);

   pBar->SetName("MyFooBar");
   // Use pBar as much as you want,
   //

   // and then just delete it when it's no longer needed
   delete pBar;    // Oops!
}

delete pBar 做了什么取决于该对象是否有一个虚析构函数。如果Foo没有一个虚析构函数�Q�则只有IBar 的隐式的�I�析构函数被调用�Q�Foo的析构函��C��会被调用�Q�这样就发生了内存泄霌Ӏ�接口类里虚析构函数的声明避免了�q�用状况�Q�它��保每个实现接口的类都有一个虚析构函数�?BR>
当你使用DeclareInterfac的时候，记得使用EndInterface和它匚w��。Interface 宏和 implements宏仅仅是代替了class和public�Q�这看�v来是多余的，但我认�ؓ它们更明��的表达了代码的意图。如果我�q�么写：class Foo : public IBar�Q�你可能认�ؓ�q�只是一个简单的�l�承�Q�但如果我这么写�Q�class Foo: implements IBar�Q�你��׃��看到它实际的价值和意图---�q�是对一个接口的实现�Q�而不是简单的一�ơ��ѝ�?/FONT>

christanxw 2005-09-24 19:36 发表评论

一本久久综合亚洲鲁鲁五月天,久久久久亚洲AV成人网,亚洲乱码精品久久久久..

A* 寻�\���法

如何在编译时��d��可判断type T 是否包含member type X

变态之MEMCPY

Eric Raymond对于几大开发语�a�的评��P��转）

A* 寻�\��法