今天接到电话面试，被问到几个问题，汗颜之余，小结一下

1、      多态是如何实现绑定的

多态的绑定可以分为运行是多态和编译时多态

● 编译时的多态性

编译时的多态性是通过重载来实现的。对于非虚的成员来说，系统在编译时，根据传递的参数、返回的类型等信息决定实现何种操作。

● 运行时的多态性

运行时的多态性就是指直到系统运行时，才根据实际情况决定实现何种操作。C#中，运行时的多态性通过虚成员实现。

编译时的多态性为我们提供了运行速度快的特点，而运行时的多态性则带来了高度灵活和抽象的特点。

今天才正式弄清楚原来虚函数是可以实现运行时多态的，以前只知道虚函数可以使得基类对象的的方法调用派生类的方法。

2、      析构函数是虚函数的优点是什么

用C++开发的时候，用来做基类的类的析构函数一般都是虚函数。可是，为什么要这样做呢？下面用一个小例子来说明：

有下面的两个类：

class ClxBase

{

public:

    ClxBase() {};

    virtual ~ClxBase() {};

    virtual void DoSomething() { cout << "Do something in class ClxBase!" << endl; };

};

class ClxDerived : public ClxBase

{

public:

    ClxDerived() {};

    ~ClxDerived() { cout << "Output from the destructor of class ClxDerived!" << endl; };

    void DoSomething() { cout << "Do something in class ClxDerived!" << endl; };

};

代码

ClxBase *pTest = new ClxDerived;

pTest->DoSomething();

delete pTest;

输出结果是：

Do something in class ClxDerived!

Output from the destructor of class ClxDerived!

这个很简单，非常好理解。

但是，如果把类ClxBase析构函数前的virtual去掉，那输出结果就是下面的样子了：

Do something in class ClxDerived!

也就是说，类ClxDerived的析构函数根本没有被调用！一般情况下类的析构函数里面都是释放内存资源，而析构函数不被调用的话就会造成内存泄漏。我想所有的C++程序员都知道这样的危险性。当然，如果在析构函数中做了其他工作的话，那你的所有努力也都是白费力气。

所以，文章开头的那个问题的答案就是－－这样做是为了当用一个基类的指针删除一个派生类的对象时，派生类的析构函数会被调用。

当然，并不是要把所有类的析构函数都写成虚函数。因为当类里面有虚函数的时候，编译器会给类添加一个虚函数表，里面来存放虚函数指针，这样就会增加类的存储空间。所以，只有当一个类被用来作为基类的时候，才把析构函数写成虚函数。

说实话，这个也是今天才深刻认识到的。

当然还问到很多数据结构和算法方面（空间复杂度和时间复杂度之类的东东，说真的也是基础性的）的问题，至于那些东西，自己说实话抛开没用他们已经很长时间了，真可以说忘的差不多了，考这种真的很怕，也怪平时没怎么用到。不知道大家用的多不？

好久没有正式参加过面试了，今天突然来一次觉得自己基础还是不够扎实。

EasyDgm是一个用于拦截短消息，发送短信的插件代码。用该插件拦截短信没有提示音，发送也不提示用户。但是本身该代码是老外开发的，只是针对8位编码的字符，没有根据我们中文的编码来做成完全Unicode版本的，为此以下改写就是实现Unicode字符串的发送。

1、  修改DatagramService工程中的代码，将其内用到的8位描述符修改为16位，具体修改的描述罗列如下：

//修改前内容

       IMPORT_C static CDatagram* NewL(TDesC8& aBuf);

       IMPORT_C static CDatagram* NewL(const TDesC8& aBuf,const TDesC8& aAddress);              IMPORT_C virtual const TDesC8& GetData();

       IMPORT_C virtual void  SetDataL(const TDesC8& aData);

       void ConstructL(const TDesC8& aBuf);

       HBufC8* iData;

//修改后内容

       IMPORT_C static CDatagram* NewL(TDesC& aBuf);

       IMPORT_C static CDatagram* NewL(const TDesC& aBuf, const TDesC8& aAddress);              IMPORT_C virtual const TDesC& GetData();

       IMPORT_C virtual void  SetDataL(const TDesC& aData);

       void ConstructL(const TDesC& aBuf);

       HBufC* iData;

2、  修改SMSDatagramService工程中CSMSSender类的代码，将其内用到的8位描述符修改为16位，具体修改的描述罗列如下：

//修改前

void CreateSMSMessageL(const TDesC8& aText, const TDesC8& aAddress);

void SendSMSL(const TDesC8& aText, const TDesC8& aAddress, TRequestStatus& aStatus);

//修改后

void CreateSMSMessageL(const TDesC& aText, const TDesC8& aAddress);

void SendSMSL(const TDesC& aText, const TDesC8& aAddress, TRequestStatus& aStatus);

3、  修改SMSDatagramService工程中CSMSSender类内创建短信的函数CreateSMSMessageL内，将原来的代码

smsSettings.SetAlphabet(TSmsDataCodingScheme::ESmsAlphabet7Bit);

改成适合unicode的通道值

smsSettings.SetAlphabet(TSmsDataCodingScheme::ESmsAlphabetUCS2);

4、  删除原有的def，重新为两份工程定稿dll，这个具体参看如何编写dll。

以上操作已经将EasyDgm插件修改成适合Unicode的代码类型了，当然该代码中还有可以进行优化的部分，在这里就不多做赘述。

具体使用的时候，可以参考S60v3_EasyDgmTest的例子，一般都是将里面的两份代码smsdatagramreceiver.cpp和smsdatagramsender.cpp直接拿来用的，但是也要改成16位描述符。

考虑到有些网友问我要修改后的EasyDgm代码，先特给出下载地址 http://www.cppblog.com/Files/franksunny/EasyDgm.rar

DLL（Dynamic Link Library）是一段特殊的代码，它能够被外部程序在程序运行的时候调用。在DLL里面的代码可以同时被许多外部程序共享，而且不会引起手机内存的重复分配。

DLL根据接口的类型Symbian系统支持两种类型的DLL:静态接口DLL和多态接口DLL

静态接口DLL在主调程序启动的时候被系统自动载入到手机内存里面（唯一的例外是如果该DLL是在ROM只读存储器里面，那么可以直接通过它的地址进行调用）。并且如果没有外部程序使用它了，它将被自动的从内存中卸载。静态接口DLL在系统内提供了一系列唯一的函数（例如，两个具有相同导出函数的DLL在系统中也不会混淆）。静态接口DLL具有.dll文件后缀，通常用于在Symbian系统中实现应用程序引擎（例如，与UI无关的代码）。

多态接口DLL只有明确的通过调用RLibrary::Load()函数才能被载入到内存中，而且在卸载的时候，也最好通过RLibrary::Close()函数进行卸载。多个多态接口DLL可以为外部程序导出多个相同的函数名的函数。所以，这种DLL通常情况下被广泛应用于实现某个应用程序框架功能扩展时候的插件。在Symbian系统中，多态接口DLL可以有多种不同的文件后缀。其中最著名的一个就是.app结尾的（应用程序），.ldd（逻辑设备驱动），.tsy和.csy（电话和通信服务模块）等等。。。

在本文中，我们将只关注静态接口DLL技术，它是你我在开发中最最常用的DLL类型。我们将以通用DLL的继续我们的内容。

静态接口的DLL

从DLL调用者的角度来看，DLL有三个文件组成：

（1）头文件：.h的文件后缀，可以#include到主调程序的代码中去，只有在编译

的时候有用。

（2）导出文件：.lib的文件后缀，可以由主调程序进行链接，这个文件记载了DLL的提供的所有接口函数名称和地址。（在arm版本中应该是dso后缀）

（3）DLL文件本身：.dll的文件后缀包括所有.lib文件记载的接口函数的具体实现，主调函数在运行的时候实际调用和执行的部分。

从DLL编写者的角度来看，DLL可以被看成是一个完整的Symbian项目。它由以下几部分组成：

（1）项目自己的MMP文件（在bld.inf文件中列出的）

（2）一个头文件，指定了该DLL需要导出的接口

（3）源代码文件，具体导出函数的实现

头文件

DLL的头文件与其它类的头文件的头文件非常类似。不同的地方在于使用了IMPORT_C宏来定义所有导出函数：

class CMyEngine : public CBase

{

public:

   // These functions are visible by the

   // clients of the DLL and needs to have

   // the IMPORT_C tag

   IMPORT_C static CMyEngine* NewL();

   IMPORT_C static CMyEngine* NewLC();

   IMPORT_C void MyPublicMethod();

   IMPORT_C void AnotherPublicMethod();

   ...

private:

   // These functions are not visible by the

   // clients of the DLL and then do not need

   // the IMPORT_C tag

   CMyEngine();

   void ConstructL();

   void SomePrivateMethod();

}

实现文件

编写DLL工作本身没有什么需要复杂的地方，但是有两个重要的地方需要留意：

（1）E32Dll()函数必须实现

（2）另外一个特殊的宏，EXPORT_C，应该加在每个导出函数实现的前面。

例如：

// This function is mandatory for all DLLs

EXPORT_C TInt E32Dll(TDllReason)

{

        return KErrNone;

}

// This function is exported: The EXPORT_C tag shall be used.

EXPORT_C void MyPublicMethod()

{

   ...

}

// This one is not: The EXPORT_C tag shall not be used.

void SomePrivateMethod()

{

  // Do Something

}

MMP文件

DLL的MMP文件应该有以下特点

（1）定义项目(project)的类型是dll

（2）使用正确的UID2的值(0x1000008d)

在开发过程中，你也应该通过EXPORTUNFROZEN告诉编译环境，DLL接口还没有定稿，还可以随时修改。

例如：

TARGET        MyEngine.dll

TARGETTYPE    dll

UID           0x1000008d

...

EXPORTUNFROZEN

把DLL接口定稿（Freezing DLL）

一旦你完成了DLL的开发，在你发行你的DLL版本之前，应该把接口定稿（Freezing）这样可以确定将来发行的DLL可以向下兼容。

通过将项目的MMP文件中的EXPORTUNFROZEN关键字去掉，用常规的方法重新建立DLL，来实现DLL库的定稿。这时候会有“.def文件不存在”的编译警告信息出现，不要紧，继续就建立当前项目，在项目编译完毕以后，你可以用如下命令定稿：

abld freeze [platform]

例如

 1、bldmake   bldfiles;  

 2、abld   build  gcce;  

 3、abld   freeze gcce; 

注意:

这里通常有三个定稿的def文件夹：在二版本中编译armi时，用abld freeze armi产生的是BMARM文件夹和对应的Def；在三版本中编译gcce和armV5时会产生EABI文件夹和对应的Def；而用wins时则编译产生BWINS文件夹和对应的Def。（个人总结）

所有的ARM平台共享一个.def文件，但是对于wins模拟器和winscw CodeWarrior环境来说，他们有不同的.def文件。

一旦项目已经定稿，重新生成makefile，这时候导入的lib会直接通过定稿的.def文件生成。

BYTE hidden = KAppNotHidden;

我们要实现图标隐藏，只需将其值赋为KAppIsHidden即可。具体示例代码如下：

RESOURCE APP_REGISTRATION_INFO

{

       app_file="Hello_Hide_app_0xEC12F4E3";

       localisable_resource_file =  qtn_loc_resource_file_1;

       localisable_resource_id = R_LOCALISABLE_APP_INFO;

       hidden = KAppIsHidden;

       embeddability=KAppNotEmbeddable;

       newfile=KAppDoesNotSupportNewFile;

}

在2nd版本中显得略微复杂些，具体实现如下（本人尚未测试过）：

I installed the application without name (.app only) or in a folder out of \system\apps\<myapp>\, for example, c:\system\data. In that way the app was not in the list.

假设你的应用ID为：ef37946b

1)在data下新建一个文件， [ef37946b].rss（注意加上[]）文件具体代码如下

#include <startupitem.rh>

RESOURCE STARTUP_ITEM_INFO dispatcher

{

    executable_name = "!:\\sys\\bin\\AutoStart.exe";

    recovery = EStartupItemExPolicyNone;

}

此处的AutoStart.exe是你的应用程序文件名。

注：笔者试图通过修改此处为其他应用程序名从而启动指定其他程序，但是没有成功。

2)在mmp文件中增加以下代码

START RESOURCE [ef37946b].rss

TARGETPATH                 \private\101f875a\import

HEADER                                  

END

确保：

LANG              SC

CAPABILITY         ReadUserData

注意“\private\101f875a\import”不能够变。

3)在pkg文件中增加以下代码

"$(EPOCROOT)epoc32\data\z\private\101f875a\import[ef37946b].rSC"-"!:\private\101f875a\import\[ef37946a].rSC"

如果是采用carbide c++编译，那么使用上述代码就可以了。

如果是使用makesis命令行打包或者使用.Net编译，那么你需要修改成绝对路径，路径名视你的安装目录而定。

例如：

"C:\Symbian\9.1\S60_3rd_MR\Epoc32\Data\z\private\101f875a\import[ef37946b].rSC"-"!:\private\101f875a\import\[ef37946a].rSC"

其次，在获知焦点变化的同时，改变应用程序的焦点，通过TApaTask::SendToBackground()和TApaTask::BringToForeground()两个函数来实现。由于这里用到的TApaTask类，需要包含APGTASK.H和apgrfx.lib。

再次，因为需要在调用其上函数时，必须用我们的应用程序的窗口组id(window  group  id)初始化(Initialise) TApaTask这个对象，这个实现需要用到，获取当前应用程序窗口组id的函数CEikonEnv::Static()->RootWin().Identifier()。刚好以上函数又要包含w32std.h和w32.lib。

l         具体实现代码如下：

void CHelloUIAppUi::HandleForegroundEventL(TBool  aForeground)

{

       if(aForeground)

       {

              TApaTask task ( CEikonEnv::Static()->WsSession() );

              task.SetWgId( CEikonEnv::Static()->RootWin().Identifier() );

              //Foreground run

              task.BringToForeground();

              ActivateLocalViewL(iHelloUIContainerView->Id());

       }

       else

       {

              TApaTask task ( CEikonEnv::Static()->WsSession() );

              task.SetWgId( CEikonEnv::Static()->RootWin().Identifier() );

              //background run

              task.SendToBackground();

       }

}

今天在单位看计算机世界，看到上面一篇文章写得很不错。摘录和总结了几个句子,同时对里面的观点有达人想说些什么的话，也给小弟以更好的见识：

第一点：“以用户体验为中心，站在用户用户的角度、根据用户的理解（而不是程序员的理解）来进行软件开发。关于此有一个基本的原则：就是不能由系统内部的交互来主导涉及，而应该有系统外部的用户与系统的交互进行指导。”

这个其实是软件开发的指导原则，软件行业本身就是服务行业，为此对于这个指导原则，个人非常赞同。

第二点：“重用，介于目前广泛的代码级重用，真正的重用已经开始了核心竞争力的重用，核心竞争力的重用，包括了对业务逻辑重用、业务行为重用乃至最关键的知识的重用。而开源软件的兴起，使得这些基于核心竞争力的高层次重用方式成为可行。”

这点说实话，有点深奥，现在对我来说代码级重用还不是很到家，至于专家所说的核心竞争力重用，知识重用，我还是不能理解到。 如果有哪位高手能够指点迷津一下，那自当心怀感激。

第三点：“软件质量要靠程序员修炼真功夫”

这个是毫无疑问的，怎么说，我们做的也是手艺活，修炼是硬道理。

第四点“个人修炼到团队修炼的三境界（以修复一个bug为例）：

第一境界：不惜努力很有责任心的，修复完这个bug并将其检查过后完事。

第二境界：修复一个后，思考下在项目中是否还有其它地方有过类似操作，并提醒项目团队可能范同样问题的其它同事，由一个bug，解决一类可能存在的bug。

第三境界：如果同类型bug出现三四次，作为项目负责人应该考虑：如果是程序员水平问题，那就应该对其进行必要的培训；如果是需求问题，那就需要与客户（策划）进行确认。”

其实这个说得还比较好的，比较形象，我也赞成，说到底还是一个态度问题，现在有多少程序员是已经达到第一境界的哦，我从事团队工作不算长（以前在小公司一直是单干户），在我觉得，这种人很稀有，更何况后面两个境界的了。

第四点：“作为一个团队，要非常注重用户的满意度，对团队的成功有高度的荣誉和渴望。”

这一点其实还是一个态度问题，跟第一点有点重复，不过层次更高了些，因为第一点可以说是自上而下的君主立宪，这一点是自下而上的，团队内人人都能做到的道德规范。