【正文】 來存放數(shù)據(jù)，因為描述符本身有邊界檢查的機制，如果出現(xiàn)了內(nèi)存溢出現(xiàn)象，會產(chǎn)生系統(tǒng)異常。當(dāng)然，您也可能不希望在描述符數(shù)據(jù)區(qū)過短的情況下，描述符的方法會發(fā)生系統(tǒng)異常。這時，您應(yīng)當(dāng)在文檔中說明，如果描述符的長度不夠?qū)绾翁幚?。有時候，一個比較好的方法是，給調(diào)用者返回一個長度值，這樣，調(diào)用者可以采用適當(dāng)?shù)牟襟E來分配一個正確長度的描述符。HBufC* CPoem::DoGetLineL(TInt aLineNumber){// Code omitted for clarity. Allocates and returns a heap buffer// containing the text of aLineNumber (leaves if aLineNumber is// out of range)}void CPoem::GetLineL(TInt aLineNumber, TDesamp。 aDes){HBufC* line = DoGetLineL(aLineNumber)。CleanupStack::PushL(line)。// Is the descriptor large enough (4 bytes or more) to return an// integer representing the length of data required?if (() lineLength()){if (() = sizeof(TInt)){// Writes the length required (TPckg is described later)TPckgTInt length(lineLength())。(length)。}// Leave amp。 indicate that the current length is too shortUser::Leave(KErrOverflow)。 // Leaves are described in Chapter 2}else{(*line)。CleanupStack::PopAndDestroy(line)。}}另一個方案是，在函數(shù)中分配堆緩沖區(qū)，把它返還給調(diào)用者，由調(diào)用者負責(zé)銷毀它。216。 Ptr()基類TDesC 實現(xiàn)了Ptr()方法，用來訪問描述符的數(shù)據(jù)，該方法返回一個指向字符數(shù)組首地址的指針。您可以通過這個指針來直接操作字符串?dāng)?shù)據(jù)。 代碼如下所示：216。 Size() 和 Length()TDesC 實現(xiàn)了 Size() and Length() 方法, 前者返回描述符所占有的字節(jié)數(shù),而后者返回的是描述符的字符長度。對8bit的描述符來講，它們是相等的,而對16bit的描述來說，Size() 返回的數(shù)值是 Length() 的兩倍。216。 MaxLength() 可修改的描述符TDes實現(xiàn)的這個方法返回描述符的最大長度。216。 SetLength()和SetMax()前者用來設(shè)置描述符的長度，這個長度值必須是小于描述符的最大長度的，否則會引起系統(tǒng)異常。后者將描述符的當(dāng)前長度設(shè)置成最大值，注意，它不并不能擴展描述符數(shù)據(jù)區(qū)的長度。216。 Zero()和FillZ()前者將描述符的長度設(shè)置為0，而后者是用0來來填充描述符的內(nèi)容置。如果您要用其它字符填充描述符的內(nèi)容，可用Fill()方法。這個方案類似于C語言中的memset（）函數(shù)。216。 Copy()TDes 實現(xiàn)了一系列的重的Copy() 方法, 下面是其中的兩個：IMPORT_C void Copy(const TDesC8 amp。aDes)。IMPORT_C void Copy(const TDesC16 amp。aDes)。這些方法將參數(shù)描述符中的數(shù)據(jù)拷貝到目標(biāo)描述符中，同時為目標(biāo)描述符設(shè)置新的長度。如可源描述符的長度超過目標(biāo)描述符的最大長度，將會引發(fā)一個系統(tǒng)異常。 使用HBufC 堆描述符我們已經(jīng)討論過描述符的一些特性，現(xiàn)在來關(guān)注一下使用描述符時經(jīng)常容易范的錯誤。 首先，我們將創(chuàng)建和使用堆描述符HBufC。前面提到過，在已有的描述符上調(diào)用Alloc（）或AllocL（）方法，可以產(chǎn)生一個新的HBufC。這里是一個例子：void CSampleClass::UnnecessaryCodeL(const TDesCamp。 aDes){iHeapBuffer = HBufC::NewL(())。TPtr ptr(iHeapBufferDes())。(aDes)。...// 以上代碼完全可以被下面的代替，下面代碼更有效率。iHeapBuffer = ()。}Another mon way to introduce plexity occurs in the oppositedirection, that is, the generation of TDesCamp。 from a heap descriptor. 當(dāng)從一個堆描述符產(chǎn)生一個TDesCamp。的時候，也容易范一個錯誤，這個錯誤同樣為代碼增加了復(fù)雜性。代碼如下所示：const TDesCamp。 CSampleClass::MoreAccidentalComplexity(){return (iHeapBufferDes())。// 以上代碼完全可以寫成return (*iHeapBuffer)。 //這樣更簡潔高效}另外一個比較微妙問題是，當(dāng)您分配一個HBufC以后，然后在它上面調(diào)用Des（），可以返回一個TPtr對象。HBufC* buf ＝ HBufC::NewL(9)。TPtr p = bufDes()?？墒?假如您回憶一下，可以知道在HBufC中，并沒有一個字（word）用來保存最大長度的信息因為HBufC是不可修改的(nonmodifiable)，它不需要最大長度的信息。然而，TPtr需要這個最大長度的信息，這時問題來了，您從哪里得到這個最大長度呢？答案在于：當(dāng)您調(diào)用Des()的時候，系統(tǒng)用HBufC的最大長度來設(shè)置TPtr的最大長度（iMaxLength）。在這個例子中，buf的最大長度是多少呢？它是9嗎？答案是不一定。堆描述符的最大長度有可能并不是您所期望的值（在這個例子中為9）。這是由于您并沒有指定一個字對齊（wordaligned）的最大長度，所以最后的實際的長度可能比您所指定的長度要大一些(但我們不能確定這個值到底是多少)。_LIT(KPanic, TestPointer)。const TInt KBufferLength = 9。void TestPointer(){ // Create a buffer with length KBufferLength = 9 bytesHBufC8* myBuffer = HBufC8::NewMaxL(KBufferLength)。TPtr8 myPtr(myBufferDes())。TInt len = ()。 //len的值為0TInt maxLen = ()。 //得到一個比KBufferLength稍大數(shù)，并不固定(KBufferLength)。 //()。否則下面的語句不起作用(’?’)。 // 用’?’填充描述符char* ptr = （char*)()。//確保已經(jīng)調(diào)用了SetLength()或SetMax()方法。ptr[0] = 39。x39。 HBufC8* buf = HBufC8::NewLC(9)。TPtr8 ptr(bufDes())。TInt maxLength = ()。 // maxLength比9大，但不一定等于12（字的邊界） TFileName的濫用對TFileName 對象的濫用是一個潛在的危險。TFileName是在文件 :const TInt KMaxFileName=0x100。 // = 256 (decimal)typedef TBufKMaxFileName TFileName。由于每個寬字符相當(dāng)于兩個字節(jié)（前面說過，默認情況下，TBuf是16bit寬度的）, 所以，無論文件名的長度為多少，每次您在棧上創(chuàng)建一個TFileName 對象的時候都消耗了524 個字節(jié) (2 256 描述符數(shù)據(jù)字節(jié) + 描述符本身的12字節(jié))。在Symbian OS系統(tǒng)中，標(biāo)準的棧空間的大小為8K字節(jié)，不必要地使用有限的資源是非常浪費的，所以盡量不要使用基于棧的TFileName 對象，也不要用值傳遞的方式使用它們，應(yīng)當(dāng)使用引用傳遞的方式。您可以在堆上使用它們，比如，您可以把它們作為C類（從CBase派生的類）的成員變量。如果，您不需要使用完整的路徑，你也可以用HBufC來存放文件名，盡量少用資源總是好的。您最好不要使用TParse 類()。因為這個類保存了一個描述符的拷貝，在拷貝中包含了要解析的文件名，拷貝會用掉寶貴的?？臻g。您應(yīng)當(dāng)考慮使用TParsePtr 和 TParsePtrC 類；它們提供了同樣的功能，但它們不拷貝文件名，而僅僅保存對文件名的引用。4有用的輔助類在討論了這些普遍的問題之后，我們在這一章的結(jié)尾來看看兩個常用的輔助類。 TLex（TLex8，TLex16）類像描述符一樣，TLex也有8bit和16bit兩種版本，分別是TLex8 and TLex16，一般情況下，你應(yīng)當(dāng)使用TLex，而無需指定特定的版本。該類實現(xiàn)了一般目的詞法分析，和語法成分解析以及從字符串到數(shù)字轉(zhuǎn)換的功能。下面是該類的提供的方法： Pckg類另外一套有用的輔助類分別是：TPckgBuf和TPckg以及TPckgC，它們是分別派生自TBufn, TPtr 和 TPtrC的模板類。打包類（package class）能很方便地將扁平的（flat）數(shù)據(jù)對象存儲到描述符中，這在跨線程或跨進程的數(shù)據(jù)共享的時候很有用。 實際上，能將一個T類對象完整地打包到描述符中，這樣很容易以一種類型安全的方式在線程間共享它。有兩種Package指針類：TPckg，TPckgC，它們分別對應(yīng)于可修改和不可修改的類型，都持有一個指向被包裝對象的指針。class TSample{ public: void SampleFunction()。 void ConstantSampleFunction() const。 private: TInt iSampleData。}。TSample theSample。TPckgTSample packagePtr(theSample)。TPckgCTSample packagePtrC(theSample)。在這個例子中，TPckgTSample表示這是一個模板類，模板參數(shù)為TSample，packagePtr(theSample)定義了一個對象，它持有一個指向theSample的針指?？梢栽诎鼘ο笊险{(diào)用（）方法，返回被包裝對象的引用。代碼如下：packagePtr().SampleFunction()。 //合法packagePtrC().SampleFunction()。//編譯錯誤!只能調(diào)用const方法packagePtrC().ConstantSampleFunction()。//合法TPckgBuf類創(chuàng)建并存儲一個新的被包裝類型的實例（注意，是窗建新的實例而不是保存指針） ，TPckgBuf自己管理這個拷貝的對象；在TPckgBuf對象上調(diào)用（）方法，可以返回對拷貝的引用，然后可以在這個引用上調(diào)用其它的方法。這個TPckgBuf對象所擁有的拷貝可以被修改。代碼如下：TPckgBufTSample packageBuf(theSample)。packageBuf().SampleFunction()。由于TPckgBuf擁有原始數(shù)據(jù)的拷貝，所以，如果在上面調(diào)用了可修改成員變量的方法，那么被修改的只是拷貝的數(shù)據(jù)，而原來的數(shù)據(jù)不受影響（這類似于函數(shù)調(diào)用時的值傳遞方式）。下面的圖示表明了它們的內(nèi)存布局：23 / 2