天天看點

C語言中柔性數組解析

在講述柔性數組之前,我們首先介紹一下不完整類型(incomplete type)。不完整類型是這樣一種類型,它缺乏足夠的資訊例如長度去描述一個完整的對象。

incomplete types ( types that describe objects but lack information needed to determine their sizes).

C與C++關于不完整類型的語義是一樣的。

基本上沒有什麼書介紹過不完整類型,很多人初次遇到這個概念時腦袋會一片空白。事實上,我們在實際的工程設計中經常使用不完整類型,隻不過不知道有這麼個概念而已。前向聲明就是一種常用的不完整類型。

class base;

struct test;           

base和test隻給出了聲明,沒有給出定義。不完整類型必須通過某種方式補充完整,才能使用它們進行執行個體化,否則隻能用于定義指針或引用,大括号形式的初始化就是其中一種方式:

int a[] = { 10, 15 };           

柔性數組成員(flexible array member)也叫做伸縮性數組成員,它的出現反映了C程式員對精煉代碼的極緻追求。這種代碼結構産生于對動态結構體的需求。在日常的程式設計中,有時候需要在結構體中存放一個長度動态的字元串,一般的做法是,在結構體中定義一個指針成員,這個指針成員指向該字元串所在的動态記憶體空間中。例如:

struct testClass
{
    int a;
    double b;
    char *p;
}           

成員變量p指向字元串。但是,這種方法造成字元串與結構體是分離的,不利于操作。如果把字元串與結構體直接連接配接在一起,不是更好嗎?于是,可以把代碼修改為這樣:

char a[] = "Hello world.";
struct testClass *pTC = (struct testClass *)malloc( sizeof(struct testClass) + strlen(a) + 1 );
strcpy( pTC + 1, a );           

這樣一來,(char *)(pTC + 1)就是字元串”Hello world.”的位址了。這時候,p就成了多餘的東西,可以去掉。

但是,這時又産生了另外一個問題:老是使用(char *)(pTC + 1)十分不友善。如果能夠找出一種方法,既能直接引用該字元串,又不占用結構體的空間,那就完美了。符合這種條件的代碼結構應該是一個非對象的符号位址,在結構體的尾部放置一個長度為0的數組是一個絕妙的解決方案。不過,C/C++标準規定不能定義長度為0的數組,是以,有些編譯器就把0長度的數組成員作為自己的非标準擴充。例如:

struct testClass
{
       int a;
       double b;
       char c[0];
};           

其中,c就叫柔性數組成員,如果把pTC指向的動态配置設定記憶體看作一個整體,c就是一個長度可以動态變化的結構體成員,柔性一詞來源于此。c的長度為0,是以它不占用testClass的空間,同時pTC->c就是”Hello world.”的首位址,不需要再使用( char* )( pTC + 1 )這麼醜陋的文法了。

鑒于這種代碼結構所産生的重要作用,C99甚至把它收入了标準中:

As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member.

C99使用不完整類型實作柔性數組成員,标準形式是這樣的:

struct testClass
{
       int a;
       double b;
       char c[];
};           

c同樣不占用testClass的空間,隻作為一個符号位址存在,而且必須是結構體的最後一個成員。柔性數組成員不僅可以用于字元數組,還可以是元素為其它類型的數組,例如:

struct testClass
{
       int a;
       double b;
       float c[];
};           

應當盡量使用标準形式,在非C99的場合,可以使用指針方法。有些人使用char a[1],這是非常不可取的,把這樣的a用作柔性數組成員會發生越界行為,雖然C/C++标準并沒有規定編譯器應當檢查越界,但也沒有規定不能檢查越界,為了一個小小的指針空間而犧牲移植性,是不值得的。

繼續閱讀