【二】 Symbian对象构造
C++的纯手工内存管理，确实是一个万恶之源。在对象构造时，有一个著名的内存泄漏隐患问题。比如一个类如下：
class A
{
public:
A()
{
a1 = new T1();
a2 = new T2();
...
an = new Tn();
}
private:
T1 * a1;
T2 * a2;
...
Tn * an;
}
{
public:
A()
{
a1 = new T1();
a2 = new T2();
...
an = new Tn();
}
private:
T1 * a1;
T2 * a2;
...
Tn * an;
}
当你调用 new A() 进行分配的时候，一旦失败，可能导致内存的泄露。比如系统正吭哧吭哧分配到了a18，失败了，抛出异常了，或者返回空值了，前面a1 - a17个对象，就彻底成了没娘管的娃，一并泄漏了出去。一个解决策略是，管好每一个分配过的对象，一旦有问题，清空一切。比如 a18分配失败了，delete掉a1 - a17。且不说这么做有没有其他问题，但是这份苦力，估计就没多少人能够承受。
二阶段构造
为了解决对象分配的问题，Symbian琢磨了所谓的二阶段构造法，它是一个pattern，关键在于将对象中栈数据的初始化和堆对象的分配过程隔离开来。一个标准的二阶段构造类如下：
class A
{
public:
~A();
static A * NewL();
static A * NewLC();
private:
A();
void ConstructL();
}
{
public:
~A();
static A * NewL();
static A * NewLC();
private:
A();
void ConstructL();
}
其中内容，自动构造的每个Symbian C++类中都会有。在构造函数中，只能够执行赋值等操作，就是初始化栈中内容，整个操作不会涉及到堆中对象的分配。所有需要分配的堆中对象，推迟到ConstructL函数中进行。NewL和NewLC提供一个封装，将构造函数和二阶段构造函数封装一起。当然，仅通过这样的方式，无法解决内存泄漏的问题，一个核心机制，是清理栈，即CleanupStack。
清理栈
CleanupStack是单件的形式呈现在程序中，GUI的程序系统为你构造好了，Console的需要人肉一个。当你在一个函数中，new了一个对象，你需要先把它push到CleanupStack中，才能调用其带L的方法，并在调用完成后将它pop出CleanupStack。一旦L函数执行失败，Leave了，并在上层用TRAP宏抓到这个Leave错误，系统会自动释放存放在CleanupStack中，还没来得及pop的对象，以保证所有资源都不会泄漏。要做到这点，有两个需要解决的问题，一是如何不在人肉delete的情形下自动析构，第二个是如何知道析构栈中多少个对象。
解决第一个问题，关键就是利用栈对象的析构函数，每个push到CleanupStack中的对象，都被一个栈对象TCleanupItem封装了一下，作为一个成员变量TAny* iPtr存放起来。当这个栈对象被释放，会调用其析构函数，析构函数中包含delete iPtr的调用，如此，自动析构得以完成。当然，为了保持其通用性，TCleanupItem其实不是直接delete，而是通过一个TCleanupOperation的对象来实现的，这个对象负责在其析构函数中delete iPtr，当然，除了delete，不同的TCleanupOperation还可以是iPtr->close，iPtr->release之类的，这样可以将其机制轻松的扩展开来。
#define TRAP(_r, _s) \
{ \
TInt& __rref = _r; \
__rref = 0; \
{ TRAP_INSTRUMENTATION_START; } \
try { \
__WIN32SEHTRAP \
TTrapHandler* ____t = User::MarkCleanupStack(); \
_s; \
User::UnMarkCleanupStack(____t); \
{ TRAP_INSTRUMENTATION_NOLEAVE; } \
__WIN32SEHUNTRAP \
} \
catch (XLeaveException& l) \
{ \
__rref = l.GetReason(); \
{ TRAP_INSTRUMENTATION_LEAVE(__rref); } \
} \
catch (...) \
{ \
User::Invariant(); \
} \
{ TRAP_INSTRUMENTATION_END; } \
}
{ \
TInt& __rref = _r; \
__rref = 0; \
{ TRAP_INSTRUMENTATION_START; } \
try { \
__WIN32SEHTRAP \
TTrapHandler* ____t = User::MarkCleanupStack(); \
_s; \
User::UnMarkCleanupStack(____t); \
{ TRAP_INSTRUMENTATION_NOLEAVE; } \
__WIN32SEHUNTRAP \
} \
catch (XLeaveException& l) \
{ \
__rref = l.GetReason(); \
{ TRAP_INSTRUMENTATION_LEAVE(__rref); } \
} \
catch (...) \
{ \
User::Invariant(); \
} \
{ TRAP_INSTRUMENTATION_END; } \
}
另一个问题解决之道，就是记录一个level，在函数执行前放入一个标记，一旦有错误，就消除在此标记后push进来的对象。这个机制的维系，隐藏在TRAP宏中。当你写TRAP(err, DoitL())时，TRAP会在调用DoitL()前，调用User::MarkCleanupStack()加入一个标记，并在调用结束后利用User::UnMarkCleanupStack检查并且消除该标记。放一个标记在这里，一旦你多push了少pop了，或者少push了多Pop了，都会触发异常，谨防顺手写错。而在执行函数DoitL()过程中，一旦发生Leave错误，在User::Leave()之类的函数中，都会找到最后标记的位置，清除标记后push的所有对象。
由于栈和函数调用都属于先进先出的，整个机制是可以嵌套进行的。只要你TRAP了Leave错误，所有资源都会被保证析构（如果没有TRAP，天皇老子都帮不了你...）。这种半自动半人肉的内存管理方式，虽然不能帮助复杂的内存对象生命周期的维护，但至少可以保证每一个资源在异常时正常释放，这一点在嵌入式系统中比一般系统显得更为重要（因为内存紧张，分配不成功是常态...）。但人肉方式总归是要人来解决的，不论CleanupStack多么的好，它只是一个pattern，它不能自动去做一些事情，还是需要开发人员主动的push，pop，leave，以及TRAD，少了哪一样，整个机制全部白搭。
Symbian的异常处理
Symbian的异常处理，就是著名的Leave机制，如果你打开TRAP宏，便惊奇的发现，所谓Leave，只不过老瓶装新酒，它只是给C++的异常机制，穿了个丁字裤，还是超节约布料型的。你可以将所谓的TRAD看成是catch，将Leave看成throw，将带L的函数，看成是throw exception的函数，再将err code当作是异常类型，整个Leave机制，就和C++的异常匹配上了。
当然，之所以称为老瓶装新酒，那么就有一些可以称为新的琐碎事。首先，就是对CleanupStack的维系。在TRAP宏和User::Leave中，包含了对CleanupStack的标记的管理和资源清理，没有它们，CleanupStack这套东东，就该另辟蹊径了。
而另一方面，就是对标准异常和无法估量的异常进行了分门别类的处理。C++和.Net不一样，异常都是不同根的，我们往往需要用catch(...)去处理一些杂类的状况。在TRAD中，对所以Symbian中的异常进行了分类。一类是派生自XLeaveException的异常，它们是整个Symbian的Cleanup以及Leave的管辖范围，只有在触发此类异常的时候，所谓的自动释放内存、Leave才能发挥作用；而其他所有的异常，都被归类异类，一旦发生，直接User::Invariant()来安乐死。所以，你明明是TRAP了，在读到空指针等错误发生的时候，它完全不起作用，程序直接崩溃，因为，这超出了它的能力范畴。
除此之外，Symbian开始支持标准的C++异常了，但对于一个合格的Symbian开发者而言，了解这些，还是有益无害的。。。
本文转自 duguguiyu 51CTO博客，原文链接：http://blog.51cto.com/duguguiyu/362831，如需转载请自行联系原作者
