本系列文章中的前兩部分,我們探討管道及信號(hào)兩種通信機(jī)制,本文將深入第三部分,介紹系統(tǒng) V 消息隊(duì)列及其相應(yīng) API。
消息隊(duì)列(也叫做報(bào)文隊(duì)列)能夠克服早期unix通信機(jī)制的一些缺點(diǎn)。作為早期unix通信機(jī)制之一的信號(hào)能夠傳送的信息量有限,后來(lái)雖然 POSIX 1003.1b在信號(hào)的實(shí)時(shí)性方面作了拓廣,使得信號(hào)在傳遞信息量方面有了相當(dāng)程度的改進(jìn),但是信號(hào)這種通信方式更像"即時(shí)"的通信方式,它要求接受信號(hào) 的進(jìn)程在某個(gè)時(shí)間范圍內(nèi)對(duì)信號(hào)做出反應(yīng),因此該信號(hào)最多在接受信號(hào)進(jìn)程的生命周期內(nèi)才有意義,信號(hào)所傳遞的信息是接近于隨進(jìn)程持續(xù)的概念 (process-persistent),見(jiàn)附錄 1;管道及有名管道及有名管道則是典型的隨進(jìn)程持續(xù)IPC,并且,只能傳送無(wú)格式的字節(jié)流無(wú)疑會(huì)給應(yīng)用程序開發(fā)帶來(lái)不便,另外,它的緩沖區(qū)大小也受到限制。
消息隊(duì)列就是一個(gè)消息的鏈表。可以把消息看作一個(gè)記錄,具有特定的格式以及特定的優(yōu)先級(jí)。對(duì)消息隊(duì)列有寫權(quán)限的進(jìn)程可以向中按照一定的規(guī)則添加新消息;對(duì)消息隊(duì)列有讀權(quán)限的進(jìn)程則可以從消息隊(duì)列中讀走消息。消息隊(duì)列是隨內(nèi)核持續(xù)的(參見(jiàn)附錄 1)。
目前主要有兩種類型的消息隊(duì)列:POSIX消息隊(duì)列以及系統(tǒng)V消息隊(duì)列,系統(tǒng)V消息隊(duì)列目前被大量使用。考慮到程序的可移植性,新開發(fā)的應(yīng)用程序應(yīng)盡量使用POSIX消息隊(duì)列。
在本系列專題的序(深刻理解Linux進(jìn)程間通信(IPC))中,提到對(duì)于消息隊(duì)列、信號(hào)燈、以及共享內(nèi)存區(qū)來(lái)說(shuō),有兩個(gè)實(shí)現(xiàn)版本:POSIX的以 及系統(tǒng)V的。Linux內(nèi)核(內(nèi)核2.4.18)支持POSIX信號(hào)燈、POSIX共享內(nèi)存區(qū)以及POSIX消息隊(duì)列,但對(duì)于主流Linux發(fā)行版本之一 redhad8.0(內(nèi)核2.4.18),還沒(méi)有提供對(duì)POSIX進(jìn)程間通信API的支持,不過(guò)應(yīng)該只是時(shí)間上的事。
因此,本文將主要介紹系統(tǒng)V消息隊(duì)列及其相應(yīng)API。在沒(méi)有聲明的情況下,以下討論中指的都是系統(tǒng)V消息隊(duì)列。
一、消息隊(duì)列基本概念
從上圖可以看出,全局?jǐn)?shù)據(jù)結(jié)構(gòu) struct ipc_ids msg_ids 可以訪問(wèn)到每個(gè)消息隊(duì)列頭的第一個(gè)成員:struct kern_ipc_perm;而每個(gè)struct kern_ipc_perm能夠與具體的消息隊(duì)列對(duì)應(yīng)起來(lái)是因?yàn)樵谠摻Y(jié)構(gòu)中,有一個(gè)key_t類型成員key,而key則唯一確定一個(gè)消息隊(duì)列。 kern_ipc_perm結(jié)構(gòu)如下:
|
二、操作消息隊(duì)列
對(duì)消息隊(duì)列的操作無(wú)非有下面三種類型:
1、 打開或創(chuàng)建消息隊(duì)列
消息隊(duì)列的內(nèi)核持續(xù)性要求每個(gè)消息隊(duì)列都在系統(tǒng)范圍內(nèi)對(duì)應(yīng)唯一的鍵值,所以,要獲得一個(gè)消息隊(duì)列的描述字,只需提供該消息隊(duì)列的鍵值即可;
注:消息隊(duì)列描述字是由在系統(tǒng)范圍內(nèi)唯一的鍵值生成的,而鍵值可以看作對(duì)應(yīng)系統(tǒng)內(nèi)的一條路經(jīng)。
2、 讀寫操作
消息讀寫操作非常簡(jiǎn)單,對(duì)開發(fā)人員來(lái)說(shuō),每個(gè)消息都類似如下的數(shù)據(jù)結(jié)構(gòu):
|
mtype成員代表消息類型,從消息隊(duì)列中讀取消息的一個(gè)重要依據(jù)就是消息的類型;mtext是消息內(nèi)容,當(dāng)然長(zhǎng)度不一定為1。因此,對(duì)于發(fā)送消息 來(lái)說(shuō),首先預(yù)置一個(gè)msgbuf緩沖區(qū)并寫入消息類型和內(nèi)容,調(diào)用相應(yīng)的發(fā)送函數(shù)即可;對(duì)讀取消息來(lái)說(shuō),首先分配這樣一個(gè)msgbuf緩沖區(qū),然后把消息 讀入該緩沖區(qū)即可。
3、 獲得或設(shè)置消息隊(duì)列屬性:
消息隊(duì)列的信息基本上都保存在消息隊(duì)列頭中,因此,可以分配一個(gè)類似于消息隊(duì)列頭的結(jié)構(gòu)(struct msqid_ds,見(jiàn)附錄 2),來(lái)返回消息隊(duì)列的屬性;同樣可以設(shè)置該數(shù)據(jù)結(jié)構(gòu)。
消息隊(duì)列API
1、文件名到鍵值
|
它返回與路徑pathname相對(duì)應(yīng)的一個(gè)鍵值。該函數(shù)不直接對(duì)消息隊(duì)列操作,但在調(diào)用ipc(MSGGET,…)或msgget()來(lái)獲得消息隊(duì)列描述字前,往往要調(diào)用該函數(shù)。典型的調(diào)用代碼是:
|
2、linux為操作系統(tǒng)V進(jìn)程間通信的三種方式(消息隊(duì)列、信號(hào)燈、共享內(nèi)存區(qū))提供了一個(gè)統(tǒng)一的用戶界面:int ipc(unsigned int call, int first, int second, int third, void *ptr, long fifth);
第一個(gè)參數(shù)指明對(duì)IPC對(duì)象的操作方式,對(duì)消息隊(duì)列而言共有四種操作:MSGSND、MSGRCV、MSGGET以及MSGCTL,分別代表向消息 隊(duì)列發(fā)送消息、從消息隊(duì)列讀取消息、打開或創(chuàng)建消息隊(duì)列、控制消息隊(duì)列;first參數(shù)代表唯一的IPC對(duì)象;下面將介紹四種操作。
注:本人不主張采用系統(tǒng)調(diào)用ipc(),而更傾向于采用系統(tǒng)V或者POSIX進(jìn)程間通信API。原因如下:
3.系統(tǒng)V消息隊(duì)列API
系統(tǒng)V消息隊(duì)列API共有四個(gè),使用時(shí)需要包括幾個(gè)頭文件:
|
1)int msgget(key_t key, int msgflg)
參數(shù)key是一個(gè)鍵值,由ftok獲得;msgflg參數(shù)是一些標(biāo)志位。該調(diào)用返回與健值key相對(duì)應(yīng)的消息隊(duì)列描述字。
在以下兩種情況下,該調(diào)用將創(chuàng)建一個(gè)新的消息隊(duì)列:
參數(shù)msgflg可以為以下:IPC_CREAT、IPC_EXCL、IPC_NOWAIT或三者的或結(jié)果。
調(diào)用返回:成功返回消息隊(duì)列描述字,否則返回-1。
注:參數(shù)key設(shè)置成常數(shù)IPC_PRIVATE并不意味著其他進(jìn)程不能訪問(wèn)該消息隊(duì)列,只意味著即將創(chuàng)建新的消息隊(duì)列。
2)int msgrcv(int msqid, struct msgbuf *msgp, int msgsz, long msgtyp, int msgflg);
該系統(tǒng)調(diào)用從msgid代表的消息隊(duì)列中讀取一個(gè)消息,并把消息存儲(chǔ)在msgp指向的msgbuf結(jié)構(gòu)中。
msqid為消息隊(duì)列描述字;消息返回后存儲(chǔ)在msgp指向的地址,msgsz指定msgbuf的mtext成員的長(zhǎng)度(即消息內(nèi)容的長(zhǎng)度),msgtyp為請(qǐng)求讀取的消息類型;讀消息標(biāo)志msgflg可以為以下幾個(gè)常值的或:
msgrcv手冊(cè)中詳細(xì)給出了消息類型取不同值時(shí)(>0; <0; =0),調(diào)用將返回消息隊(duì)列中的哪個(gè)消息。
msgrcv()解除阻塞的條件有三個(gè):
調(diào)用返回:成功返回讀出消息的實(shí)際字節(jié)數(shù),否則返回-1。
3)int msgsnd(int msqid, struct msgbuf *msgp, int msgsz, int msgflg);
向msgid代表的消息隊(duì)列發(fā)送一個(gè)消息,即將發(fā)送的消息存儲(chǔ)在msgp指向的msgbuf結(jié)構(gòu)中,消息的大小由msgze指定。
對(duì)發(fā)送消息來(lái)說(shuō),有意義的msgflg標(biāo)志為IPC_NOWAIT,指明在消息隊(duì)列沒(méi)有足夠空間容納要發(fā)送的消息時(shí),msgsnd是否等待。造成msgsnd()等待的條件有兩種:
調(diào)用返回:成功返回0,否則返回-1。
4)int msgctl(int msqid, int cmd, struct msqid_ds *buf);
該系統(tǒng)調(diào)用對(duì)由msqid標(biāo)識(shí)的消息隊(duì)列執(zhí)行cmd操作,共有三種cmd操作:IPC_STAT、IPC_SET 、IPC_RMID。
調(diào)用返回:成功返回0,否則返回-1。
三、消息隊(duì)列的限制
每個(gè)消息隊(duì)列的容量(所能容納的字節(jié)數(shù))都有限制,該值因系統(tǒng)不同而不同。在后面的應(yīng)用實(shí)例中,輸出了redhat 8.0的限制,結(jié)果參見(jiàn)附錄 3。
另一個(gè)限制是每個(gè)消息隊(duì)列所能容納的最大消息數(shù):在redhad 8.0中,該限制是受消息隊(duì)列容量制約的:消息個(gè)數(shù)要小于消息隊(duì)列的容量(字節(jié)數(shù))。
注:上述兩個(gè)限制是針對(duì)每個(gè)消息隊(duì)列而言的,系統(tǒng)對(duì)消息隊(duì)列的限制還有系統(tǒng)范圍內(nèi)的最大消息隊(duì)列個(gè)數(shù),以及整個(gè)系統(tǒng)范圍內(nèi)的最大消息數(shù)。一般來(lái)說(shuō),實(shí)際開發(fā)過(guò)程中不會(huì)超過(guò)這個(gè)限制。
四、消息隊(duì)列應(yīng)用實(shí)例
消息隊(duì)列應(yīng)用相對(duì)較簡(jiǎn)單,下面實(shí)例基本上覆蓋了對(duì)消息隊(duì)列的所有操作,同時(shí),程序輸出結(jié)果有助于加深對(duì)前面所講的某些規(guī)則及消息隊(duì)列限制的理解。
|
小結(jié):
消息隊(duì)列
與管道以及有名管道相比,具有更大的靈活性,首先,它提供有格式字節(jié)流,有利于減少開發(fā)人員的工作量;其次,消息具有類型,在實(shí)際應(yīng)用中,可作為優(yōu)先級(jí)使
用。這兩點(diǎn)是管道以及有名管道所不能比的。同樣,消息隊(duì)列可以在幾個(gè)進(jìn)程間復(fù)用,而不管這幾個(gè)進(jìn)程是否具有親緣關(guān)系,這一點(diǎn)與有名管道很相似;但消息隊(duì)列
是隨內(nèi)核持續(xù)的,與有名管道(隨進(jìn)程持續(xù))相比,生命力更強(qiáng),應(yīng)用空間更大。
附錄 1:在參考文獻(xiàn)[1]中,給出了IPC隨進(jìn)程持續(xù)、隨內(nèi)核持續(xù)以及隨文件系統(tǒng)持續(xù)的定義:
附錄 2:
結(jié)構(gòu)msg_queue用來(lái)描述消息隊(duì)列頭,存在于系統(tǒng)空間:
|
結(jié)構(gòu)msqid_ds用來(lái)設(shè)置或返回消息隊(duì)列的信息,存在于用戶空間;
|
附錄 3:消息隊(duì)列實(shí)例輸出結(jié)果:
|
參考文獻(xiàn):
在
time_t time(time_t *timer);
double difftime(time_t time1,time_t time2);
struct tm *gmtime(const time_t *timer);
struct tm *localtime(const time_t *timer);
char *asctime(const struct tm *timeptr);
char *ctime(const time_t *timer);
size_t strftime(char *s,size_t maxsize,const char *format,const struct tm *timeptr);
time_t mktime(struct tm *timeptr);
clock_t clock(void);
下面是我從網(wǎng)上收集到的時(shí)間函數(shù)集
TinyXML是一個(gè)簡(jiǎn)單小巧,可以很容易集成到其它程序中的C++ XML解析器。
它能做些什么
簡(jiǎn)單地說(shuō),TinyXML解析一個(gè)XML文檔并由此生成一個(gè)可讀可修改可保存的文檔對(duì)象模型(DOM)。
XML的意思是“可擴(kuò)展標(biāo)記語(yǔ)言“(eXtensible Markup Language)。它允許你創(chuàng)建你自己的文檔標(biāo)記。在為瀏覽器標(biāo)記文檔方面HTML做得很好,然而XML允許你定義任何文檔標(biāo)記,比如可以為一個(gè)組織者 應(yīng)用程序定義一個(gè)描述“to do”列表的文檔。 XML擁有一個(gè)結(jié)構(gòu)化并且方便的格式,所有為存儲(chǔ)應(yīng)用程序數(shù)據(jù)而創(chuàng)建的隨機(jī)文件格式都可以用XML代替,而這一切只需要一個(gè)解析器。
最全面正確的說(shuō)明可以在http://www.w3.org/TR/2004/REC-xml-20040204/找到,但坦白地說(shuō),它很晦澀難懂。事實(shí)上我喜歡http://skew.org/xml/tutorial上關(guān)于XML的介紹。
有不同的方法可以訪問(wèn)和與XML數(shù)據(jù)進(jìn)行交互。TinyXML使用文檔對(duì)象模型(DOM),這意味著XML數(shù)據(jù)被解析成一個(gè)可被瀏覽和操作的C++ 對(duì)象,然后它可以被寫到磁盤或者另一個(gè)輸出流中。你也可以把C++對(duì)象構(gòu)造成一個(gè)XML文檔然后把它寫到磁盤或者另一個(gè)輸出流中。
TinyXML被設(shè)計(jì)得容易快速上手。它只有兩個(gè)頭文件和四個(gè)cpp文件。只需要把它們簡(jiǎn)單地加到你的項(xiàng)目中就行了。有一個(gè)例子文件——xmltest.cpp來(lái)引導(dǎo)你該怎么做。
TinyXML以Zlib許可來(lái)發(fā)布,所以你可以在開源或者商業(yè)軟件中使用它。許可證更具體的描述在每個(gè)源代碼文件的頂部可以找到。
TinyXML在保證正確和恰當(dāng)?shù)腦ML輸出的基礎(chǔ)上嘗試成為一個(gè)靈活的解析器。TinyXML可以在任何合理的C++適用系統(tǒng)上編譯。它不依賴于 異常或者運(yùn)行時(shí)類型信息,有沒(méi)有STL支持都可以編譯。TinyXML完全支持UTF-8編碼和前64k個(gè)字符實(shí)體(<i>譯注:如果你不明 白這句譯文,可能你需要了解一下Unicode編碼</i>)。
它無(wú)法做些什么
TinyXML不解析不使用DTDs(文檔類型定義)或者XSLs(可擴(kuò)展樣式表語(yǔ)言)。有其它解析器(到www.sourceforge.org 搜索一下XML)具有更加全面的特性,但它們也就更大,需要花更長(zhǎng)的時(shí)間來(lái)建立你的項(xiàng)目,有更陡的學(xué)習(xí)曲線,而且經(jīng)常有一個(gè)更嚴(yán)格的許可協(xié)議。如果你是用 于瀏覽器或者有更復(fù)雜的XML需要,那么TinyXML不適合你。
下面的DTD語(yǔ)法在TinyXML里是不做解析的:
<!DOCTYPE Archiv [
<!ELEMENT Comment (#PCDATA)>
]>
因?yàn)門inyXML把它看成是一個(gè)帶著非法嵌入!ELEMENT結(jié)點(diǎn)的!DOCTYPE結(jié)點(diǎn)。或許這在將來(lái)會(huì)得到支持。
指南
有耐性些,這是一份能很好地指導(dǎo)你怎么開始的指南,它(非常短小精悍)值得你花時(shí)間完整地讀上一遍。
代碼狀況
TinyXML是成熟且經(jīng)過(guò)測(cè)試的代碼,非常健壯。如果你發(fā)現(xiàn)了漏洞,請(qǐng)?zhí)峤宦┒磮?bào)告到sourcefore網(wǎng)站上 (www.sourceforge.net/projects/tinyxml)。 我們會(huì)盡快修正。
有些地方可以讓你得到提高,如果你對(duì)TinyXML的工作感興趣的話可以上sourceforge查找一下。
相關(guān)項(xiàng)目
你也許會(huì)覺(jué)得TinyXML很有用!(簡(jiǎn)介由項(xiàng)目提供)
特性
使用STL
TinyXML可以被編譯成使用或不使用STL。如果使用STL,TinyXML會(huì)使用std::string類,而且完全支持 std::istream,std::ostream,operator<<和operator>>。許多API方法都有 ‘const char*’和’const std::string&’兩個(gè)版本。
如果被編譯成不使用STL,則任何STL都不會(huì)被包含。所有string類都由TinyXML它自己實(shí)現(xiàn)。所有API方法都只提供’const char*’傳入?yún)?shù)。
使用運(yùn)行時(shí)定義:
TIXML_USE_STL
來(lái)編譯成不同的版本。這可以作為參數(shù)傳給編譯器或者在“tinyxml.h”文件的第一行進(jìn)行設(shè)置。
注意:如果在Linux上編譯測(cè)試代碼,設(shè)置環(huán)境變量TINYXML_USE_STL=YES/NO可以控制STL的編譯。而在Windows上, 項(xiàng)目文件提供了STL和非STL兩種目標(biāo)文件。在你的項(xiàng)目中,在tinyxml.h的第一行添加"#define TIXML_USE_STL"應(yīng)該是最簡(jiǎn)單的。
UTF-8
TinyXML支持UTF-8,所以可以處理任何語(yǔ)言的XML文件,而且TinyXML也支持“legacy模式”——一種在支持UTF-8之前使用的編碼方式,可能最好的解釋是“擴(kuò)展的ascii”。
正常情況下,TinyXML會(huì)檢測(cè)出正確的編碼并使用它,然而,通過(guò)設(shè)置頭文件中的TIXML_DEFAULT_ENCODING值,TinyXML可以被強(qiáng)制成總是使用某一種編碼。
除非以下情況發(fā)生,否則TinyXML會(huì)默認(rèn)使用Legacy模式:
如果編碼設(shè)置錯(cuò)誤或者檢測(cè)到錯(cuò)誤會(huì)發(fā)生什么事呢?TinyXML會(huì)嘗試跳過(guò)這些看似不正確的編碼,你可能會(huì)得到一些奇怪的結(jié)果或者亂碼,你可以強(qiáng)制TinyXML使用正確的編碼模式。
通過(guò)使用LoadFile( TIXML_ENCODING_LEGACY )或者LoadFile( filename, TIXML_ENCODING_LEGACY ), 你可以強(qiáng)制TinyXML使用Legacy模式。你也可以通過(guò)設(shè)置TIXML_DEFAULT_ENCODING = TIXML_ENCODING_LEGACY來(lái)強(qiáng)制一直使用Legacy模式。同樣的,你也可以通過(guò)相同的方法來(lái)強(qiáng)制設(shè)置成 TIXML_ENCODING_UTF8。
對(duì)于使用英文XML的英語(yǔ)用戶來(lái)說(shuō),UTF-8跟low-ASCII是一樣的。你不需要知道UTF-8或者一點(diǎn)也不需要修改你的代碼。你可以把UTF-8當(dāng)作是ASCII的超集。
UTF-8并不是一種雙字節(jié)格式,但它是一種標(biāo)準(zhǔn)的Unicode編碼!TinyXML當(dāng)前不使用或者直接支持wchar,TCHAR,或者微軟的 _UNICODE。"Unicode"這個(gè)術(shù)語(yǔ)被普遍地認(rèn)為指的是UTF-16(一種unicode的寬字節(jié)編碼)是不適當(dāng)?shù)模@是混淆的來(lái)源。
對(duì)于“high-ascii”語(yǔ)言來(lái)說(shuō)——幾乎所有非英語(yǔ)語(yǔ)言,只要XML被編碼成UTF-8, TinyXML就能夠處理。說(shuō)起來(lái)可能有點(diǎn)微妙,比較舊的程序和操作系統(tǒng)趨向于使用“默認(rèn)”或者“傳統(tǒng)”的編碼方式。許多應(yīng)用程序(和幾乎所有現(xiàn)在的應(yīng)用 程序)都能夠輸出UTF-8,但是那些比較舊或者難處理的(或者干脆不能使用的)系統(tǒng)還是只能以默認(rèn)編碼來(lái)輸出文本。
比如說(shuō),日本的系統(tǒng)傳統(tǒng)上使用SHIFT-JIS編碼,這種情況下TinyXML就無(wú)法讀取了。但是一個(gè)好的文本編輯器可以導(dǎo)入SHIFT-JIS的文本然后保存成UTF-8編碼格式的。
Skew.org link上關(guān)于轉(zhuǎn)換編碼的話題做得很好。
測(cè)試文件“utf8test.xml”包含了英文、西班牙文、俄文和簡(jiǎn)體中文(希望它們都能夠被正確地轉(zhuǎn)化)。“utf8test.gif”文件是 從IE上截取的XML文件快照。請(qǐng)注意如果你的系統(tǒng)上沒(méi)有正確的字體(簡(jiǎn)體中文或者俄文),那么即使你正確地解析了也看不到與GIF文件上一樣的輸出。同 時(shí)要注意在一個(gè)西方編碼的控制臺(tái)上(至少我的Windows機(jī)器是這樣),Print()或者printf()也無(wú)法正確地顯示這個(gè)文件,這不關(guān) TinyXML的事——這只是操作系統(tǒng)的問(wèn)題。TinyXML沒(méi)有丟掉或者損壞數(shù)據(jù),只是控制臺(tái)無(wú)法顯示UTF-8而已。
實(shí)體
TinyXML認(rèn)得預(yù)定義的特殊“字符實(shí)體”,即:
& &
< <
> >
" "
' ‘
這些在XML文檔讀取時(shí)都會(huì)被辨認(rèn)出來(lái),并會(huì)被轉(zhuǎn)化成等價(jià)的UTF-8字符。比如下面的XML文本:
Far & Away
從TiXmlText 對(duì)象查詢出來(lái)時(shí)會(huì)變成"Far & Away"這樣的值,而寫回XML流/文件時(shí)會(huì)以“&”的方式寫回。老版本的TinyXML“保留”了字符實(shí)體,而在新版本中它們會(huì)被轉(zhuǎn)化成字符串。
另外,所有字符都可以用它的Unicode編碼數(shù)字來(lái)指定, " "和" "都表示不可分的空格字符。
打印
TinyXML有幾種不同的方式來(lái)打印輸出,當(dāng)然它們各有各的優(yōu)缺點(diǎn)。
流
設(shè)置了TIXML_USE_STL,TinyXML就能支持C++流(operator <<,>>)和C(FILE*)流。但它們之間有些差異你需要知道:
C風(fēng)格輸出:
生成具有很多空格的格式化過(guò)的輸出,這是為了盡可能讓人看得明白。它們非常快,而且能夠容忍XML文檔中的格式錯(cuò)誤。例如一個(gè)XML文檔包含兩個(gè)根元素和兩個(gè)聲明仍然能被打印出來(lái)。
C風(fēng)格輸入:
速度快,容錯(cuò)性好。當(dāng)你不需要C++流時(shí)就可以使用它。
C++風(fēng)格輸出:
生成壓縮過(guò)的輸出,目的是為了便于網(wǎng)絡(luò)傳輸而不是為了可讀性。它可能有些慢(可能不會(huì)),這主要跟你系統(tǒng)上ostream類的實(shí)現(xiàn)有關(guān)。無(wú)法容忍格式錯(cuò)誤的XML:此文檔只能包含一個(gè)根元素。另外根級(jí)別的元素?zé)o法以流形式輸出。
C++風(fēng)格輸入:
從流中讀取XML使其可用于網(wǎng)絡(luò)傳輸。通過(guò)些小技巧,它知道當(dāng)XML文檔讀取完畢時(shí),流后面的就一定是其它數(shù)據(jù)了。TinyXML總假定當(dāng)它讀取到 根結(jié)點(diǎn)后XML數(shù)據(jù)就結(jié)束了。換句話說(shuō),那些具有不止一個(gè)根元素的文檔是無(wú)法被正確讀取的。另外還要注意由于STL的實(shí)現(xiàn)和TinyXML的限 制,operator>>會(huì)比Parse慢一些。
空格
對(duì)是保留還是壓縮空格這一問(wèn)題人們還沒(méi)達(dá)成共識(shí)。舉個(gè)例子,假設(shè)‘_’代表一個(gè)空格,對(duì)于"Hello____world",HTML和某些XML 解析器會(huì)解釋成"Hello_world",它們壓縮掉了一些空格。而有些XML解析器卻不會(huì)這樣,它們會(huì)保留空格,于是就是 “Hello____world”(記住_表示一個(gè)空格)。其它的還建議__Hello___world__應(yīng)該變成Hello___world 。
這是一個(gè)解決得不能讓我滿意的問(wèn)題。TinyXML一開始就兩種方式都支持。調(diào)用TiXmlBase::SetCondenseWhiteSpace( bool )來(lái)設(shè)置你想要的結(jié)果,默認(rèn)是壓縮掉多余的空格。
如果想要改變默認(rèn)行為,你應(yīng)該在解析任何XML數(shù)據(jù)之前調(diào)用TiXmlBase::SetCondenseWhiteSpace( bool ) ,而且我不建議設(shè)置之后再去改動(dòng)它。
句柄
想要健壯地讀取一個(gè)XML文檔,檢查方法調(diào)用后的返回值是否為null是很重要的。一種安全的檢錯(cuò)實(shí)現(xiàn)可能會(huì)產(chǎn)生像這樣的代碼:
TiXmlElement* root = document.FirstChildElement( "Document" );
if ( root )
{
TiXmlElement* element = root->FirstChildElement( "Element" );
if ( element )
{
TiXmlElement* child = element->FirstChildElement( "Child" );
if ( child )
{
TiXmlElement* child2 = child->NextSiblingElement( "Child" );
if ( child2 )
{
// Finally do something useful.
用句柄的話就不會(huì)這么冗長(zhǎng)了,使用TiXmlHandle類,前面的代碼就會(huì)變成這樣:
TiXmlHandle docHandle( &document );
TiXmlElement* child2 = docHandle.FirstChild( "Document" ).FirstChild( "Element" ).Child( "Child", 1 ).ToElement();
if ( child2 )
{
// do something useful
這處理起來(lái)容易多了。 查閱TiXmlHandle可以得到更多的信息。
行列追蹤
對(duì)于某些應(yīng)用程序來(lái)說(shuō),能夠追蹤節(jié)點(diǎn)和屬性在它們?cè)次募械脑嘉恢檬呛苤匾摹A硗猓澜馕鲥e(cuò)誤在源文件中的發(fā)生位置可以節(jié)省大量時(shí)間。
TinyXML能夠追蹤所有結(jié)點(diǎn)和屬性在文本文件中的行列原始位置。TiXmlBase::Row() 和 TiXmlBase::Column() 方法返回結(jié)點(diǎn)在源文件中的原始位置。正確的制表符號(hào)可以經(jīng)由TiXmlDocument::SetTabSize() 來(lái)配置。
使用與安裝
編譯與運(yùn)行xmltest:
提供了一個(gè)Linux Makefile和一個(gè)Windows Visual C++ .dsw 文件。只需要簡(jiǎn)單地編譯和運(yùn)行,它就會(huì)在你的磁盤上生成demotest.xml文件并在屏幕上輸出。它還嘗試用不同的方法遍歷DOM并打印出結(jié)點(diǎn)數(shù)。
那個(gè)Linux makefile很通用,可以運(yùn)行在很多系統(tǒng)上——它目前已經(jīng)在mingw和MacOSX上測(cè)試過(guò)。你不需要運(yùn)行 ‘make depend’,因?yàn)槟切┮蕾囮P(guān)系已經(jīng)硬編碼在文件里了。
用于VC6的Windows項(xiàng)目文件
Makefile
在makefile的頂部你可以設(shè)置:
PROFILE,DEBUG,和TINYXML_USE_STL。makefile里有具體描述。
在tinyxml目錄輸入“make clean”然后“make”,就可以生成可執(zhí)行的“xmltest”文件。
在某一應(yīng)用程序中使用:
把tinyxml.cpp,tinyxml.h, tinyxmlerror.cpp, tinyxmlparser.cpp, tinystr.cpp, 和 tinystr.h 添加到你的項(xiàng)目和makefile中。就這么簡(jiǎn)單,它可以在任何合理的C++適用系統(tǒng)上編譯。不需要為TinyXML打開異常或者運(yùn)行時(shí)類型信息支持。
TinyXML怎么工作
舉個(gè)例子可能是最好的辦法,理解一下:
<?xml version="1.0" standalone=no>
<!– Our to do list data –>
<ToDo>
<Item priority="1"> Go to the <bold>Toy store!</bold></Item>
<Item priority="2"> Do bills</Item>
</ToDo>
它稱不上是一個(gè)To Do列表,但它已經(jīng)足夠了。像下面這樣讀取并解析這個(gè)文件(叫“demo.xml”)你就能創(chuàng)建一個(gè)文檔:
TiXmlDocument doc( "demo.xml" );
doc.LoadFile();
現(xiàn)在它準(zhǔn)備好了,讓我們看看其中的某些行和它們?cè)趺磁cDOM聯(lián)系起來(lái)。
<?xml version="1.0" standalone=no>
第一行是一個(gè)聲明,它會(huì)轉(zhuǎn)化成TiXmlDeclaration 類,同時(shí)也是文檔結(jié)點(diǎn)的第一個(gè)子結(jié)點(diǎn)。
這是TinyXML唯一能夠解析的指令/特殊標(biāo)簽。一般來(lái)說(shuō)指令標(biāo)簽會(huì)保存在TiXmlUnknown 以保證在它保存回磁盤時(shí)不會(huì)丟失這些命令。
<!– Our to do list data –>
這是一個(gè)注釋,會(huì)成為一個(gè)TiXmlComment對(duì)象。
<ToDo>
"ToDo"標(biāo)簽定義了一個(gè)TiXmlElement 對(duì)象。它沒(méi)有任何屬性,但包含另外的兩個(gè)元素。
<Item priority="1">
生成另一個(gè)TiXmlElement對(duì)象,它是“ToDo”元素的子結(jié)點(diǎn)。此元素有一個(gè)名為“priority”和值為“1”的屬性。
Go to the
TiXmlText ,這是一個(gè)葉子結(jié)點(diǎn),它不能再包含其它結(jié)點(diǎn),是"Item" TiXmlElement的子結(jié)點(diǎn)。
<bold>
另一個(gè)TiXmlElement, 這也是“Item”元素的子結(jié)點(diǎn)。
等等
最后,看看整個(gè)對(duì)象樹:
TiXmlDocument "demo.xml"
TiXmlDeclaration "version=’1.0′" "standalone=no"
TiXmlComment " Our to do list data"
TiXmlElement "ToDo"
TiXmlElement "Item" Attribtutes: priority = 1
TiXmlText "Go to the "
TiXmlElement "bold"
TiXmlText "Toy store!"
TiXmlElement "Item" Attributes: priority=2
TiXmlText "Do bills"
文檔
本文檔由Doxygen使用‘dox’配置文件生成。
許可證
TinyXML基于zlib許可證來(lái)發(fā)布:
本軟件按“現(xiàn)狀”提供(即現(xiàn)在你看到的樣子),不做任何明確或隱晦的保證。由使用此軟件所引起的任何損失都決不可能由作者承擔(dān)。
只要遵循下面的限制,就允許任何人把這軟件用于任何目的,包括商業(yè)軟件,也允許修改它并自由地重新發(fā)布:
1. 決不能虛報(bào)軟件的來(lái)源;你決不能聲稱是你是軟件的第一作者。如果你在某個(gè)產(chǎn)品中使用了這個(gè)軟件,那么在產(chǎn)品文檔中加入一個(gè)致謝辭我們會(huì)很感激,但這并非必要。
2. 修改了源版本就應(yīng)該清楚地標(biāo)記出來(lái),決不能虛報(bào)說(shuō)這是原始軟件。
3. 本通告不能從源發(fā)布版本中移除或做修改。
參考書目
萬(wàn)維網(wǎng)聯(lián)盟是定制XML的權(quán)威標(biāo)準(zhǔn)機(jī)構(gòu),它的網(wǎng)頁(yè)上有大量的信息。
權(quán)威指南:http://www.w3.org/TR/2004/REC-xml-20040204/
我還要推薦由OReilly出版由Robert Eckstein撰寫的"XML Pocket Reference"……這本書囊括了入門所需要的一切。
捐助者,聯(lián)系人,還有簡(jiǎn)史
非常感謝給我們建議,漏洞報(bào)告,意見(jiàn)和鼓勵(lì)的所有人。它們很有用,并且使得這個(gè)項(xiàng)目變得有趣。特別感謝那些捐助者,是他們讓這個(gè)網(wǎng)站頁(yè)面生機(jī)勃勃。
有很多人發(fā)來(lái)漏洞報(bào)告和意見(jiàn),與其在這里一一列出來(lái)不如我們?cè)囍阉鼈儗懙?#8220;changes.txt”文件中加以贊揚(yáng)。
TinyXML的原作者是Lee Thomason(文檔中還經(jīng)常出現(xiàn)“我”這個(gè)詞) 。在Yves Berquin,Andrew Ellerton,和tinyXml社區(qū)的幫助下,Lee查閱修改和發(fā)布新版本。
我們會(huì)很感激你的建議,還有我們想知道你是否在使用TinyXML。希望你喜歡它并覺(jué)得它很有用。請(qǐng)郵寄問(wèn)題,評(píng)論,漏洞報(bào)告給我們,或者你也可登錄網(wǎng)站與我們?nèi)〉寐?lián)系:
www.sourceforge.net/projects/tinyxml
Lee Thomason, Yves Berquin, Andrew Ellerton
2) 結(jié)構(gòu)體每個(gè)成員相對(duì)于結(jié)構(gòu)體首地址的偏移量都是成員大小的整數(shù)倍,如有需要編譯器會(huì)在成員之間加上填充字節(jié);例如上面第二個(gè)結(jié)構(gòu)體變量的地址空間。
3) 結(jié)構(gòu)體的總大小為結(jié)構(gòu)體最寬基本類型成員大小的整數(shù)倍,如有需要編譯器會(huì)在最末一個(gè)成員之后加上填充字節(jié)。例如上面第一個(gè)結(jié)構(gòu)體變量。
現(xiàn)代計(jì)算機(jī)中內(nèi)存空間都是按照byte劃分的,從理論上講似乎對(duì)任何類型的變量的訪問(wèn)可以從任何地址開始,但實(shí)際情況是在訪問(wèn)特定類型變量的時(shí)候經(jīng)常在特
定的內(nèi)存地址訪問(wèn),這就需要各種類型數(shù)據(jù)按照一定的規(guī)則在空間上排列,而不是順序的一個(gè)接一個(gè)的排放,這就是對(duì)齊。
對(duì)齊的作用和原因:各個(gè)硬件平臺(tái)對(duì)存儲(chǔ)空間的處理上有很大的不同。一些平臺(tái)對(duì)某些特定類型的數(shù)據(jù)只能從某些特定地址開始存取。比如有些架構(gòu)的CPU在訪問(wèn)
一個(gè)沒(méi)有進(jìn)行對(duì)齊的變量的時(shí)候會(huì)發(fā)生錯(cuò)誤,那么在這種架構(gòu)下編程必須保證字節(jié)對(duì)齊.其他平臺(tái)可能沒(méi)有這種情況,但是最常見(jiàn)的是如果不按照適合其平臺(tái)要求對(duì)
數(shù)據(jù)存放進(jìn)行對(duì)齊,會(huì)在存取效率上帶來(lái)?yè)p失。比如有些平臺(tái)每次讀都是從偶地址開始,如果一個(gè)int型(假設(shè)為32位系統(tǒng))如果存放在偶地址開始的地方,那
么一個(gè)讀周期就可以讀出這32bit,而如果存放在奇地址開始的地方,就需要2個(gè)讀周期,并對(duì)兩次讀出的結(jié)果的高低字節(jié)進(jìn)行拼湊才能得到該32bit數(shù)
據(jù)。顯然在讀取效率上下降很多。
先讓我們看幾個(gè)例子吧(32bit,x86環(huán)境,gcc編譯器):
設(shè)結(jié)構(gòu)體如下定義:
struct A
{
int a;
char b;
short c;
};
struct B
{
char b;
int a;
short c;
};
現(xiàn)在已知32位機(jī)器上各種數(shù)據(jù)類型的長(zhǎng)度如下:
char:1(有符號(hào)無(wú)符號(hào)同)
short:2(有符號(hào)無(wú)符號(hào)同)
int:4(有符號(hào)無(wú)符號(hào)同)
long:4(有符號(hào)無(wú)符號(hào)同)
float:4 double:8
那么上面兩個(gè)結(jié)構(gòu)大小如何呢?
結(jié)果是:
sizeof(strcut A)值為8
sizeof(struct B)的值卻是12
結(jié)構(gòu)體A中包含了4字節(jié)長(zhǎng)度的int一個(gè),1字節(jié)長(zhǎng)度的char一個(gè)和2字節(jié)長(zhǎng)度的short型數(shù)據(jù)一個(gè),B也一樣;按理說(shuō)A,B大小應(yīng)該都是7字節(jié)。
之所以出現(xiàn)上面的結(jié)果是因?yàn)榫幾g器要對(duì)數(shù)據(jù)成員在空間上進(jìn)行對(duì)齊。上面是按照編譯器的默認(rèn)設(shè)置進(jìn)行對(duì)齊的結(jié)果,那么我們是不是可以改變編譯器的這種默認(rèn)對(duì)齊設(shè)置呢,當(dāng)然可以.例如:
#pragma pack (2) /*指定按2字節(jié)對(duì)齊*/
struct C
{
char b;
int a;
short c;
};
#pragma pack () /*取消指定對(duì)齊,恢復(fù)缺省對(duì)齊*/
sizeof(struct C)值是8。
修改對(duì)齊值為1:
#pragma pack (1) /*指定按1字節(jié)對(duì)齊*/
struct D
{
char b;
int a;
short c;
};
#pragma pack () /*取消指定對(duì)齊,恢復(fù)缺省對(duì)齊*/
sizeof(struct D)值為7。
后面我們?cè)僦v解#pragma pack()的作用.
先讓我們看四個(gè)重要的基本概念:
1.數(shù)據(jù)類型自身的對(duì)齊值:
對(duì)于char型數(shù)據(jù),其自身對(duì)齊值為1,對(duì)于short型為2,對(duì)于int,float,double類型,其自身對(duì)齊值為4,單位字節(jié)。
2.結(jié)構(gòu)體或者類的自身對(duì)齊值:其成員中自身對(duì)齊值最大的那個(gè)值。
3.指定對(duì)齊值:#pragma pack (value)時(shí)的指定對(duì)齊值value。
4.數(shù)據(jù)成員、結(jié)構(gòu)體和類的有效對(duì)齊值:自身對(duì)齊值和指定對(duì)齊值中小的那個(gè)值。
有
了這些值,我們就可以很方便的來(lái)討論具體數(shù)據(jù)結(jié)構(gòu)的成員和其自身的對(duì)齊方式。有效對(duì)齊值N是最終用來(lái)決定數(shù)據(jù)存放地址方式的值,最重要。有效對(duì)齊N,就是
表示“對(duì)齊在N上”,也就是說(shuō)該數(shù)據(jù)的"存放起始地址%N=0".而數(shù)據(jù)結(jié)構(gòu)中的數(shù)據(jù)變量都是按定義的先后順序來(lái)排放的。第一個(gè)數(shù)據(jù)變量的起始地址就是數(shù)
據(jù)結(jié)構(gòu)的起始地址。結(jié)構(gòu)體的成員變量要對(duì)齊排放,結(jié)構(gòu)體本身也要根據(jù)自身的有效對(duì)齊值圓整(就是結(jié)構(gòu)體成員變量占用總長(zhǎng)度需要是對(duì)結(jié)構(gòu)體有效對(duì)齊值的整數(shù)
倍,結(jié)合下面例子理解)。這樣就不能理解上面的幾個(gè)例子的值了。
例子分析:
分析例子B;
struct B
{
char b;
int a;
short c;
};
假
設(shè)B從地址空間0x0000開始排放。該例子中沒(méi)有定義指定對(duì)齊值,在筆者環(huán)境下,該值默認(rèn)為4。第一個(gè)成員變量b的自身對(duì)齊值是1,比指定或者默認(rèn)指定
對(duì)齊值4小,所以其有效對(duì)齊值為1,所以其存放地址0x0000符合0x0000%1=0.第二個(gè)成員變量a,其自身對(duì)齊值為4,所以有效對(duì)齊值也為4,
所以只能存放在起始地址為0x0004到0x0007這四個(gè)連續(xù)的字節(jié)空間中,復(fù)核0x0004%4=0,且緊靠第一個(gè)變量。第三個(gè)變量c,自身對(duì)齊值為
2,所以有效對(duì)齊值也是2,可以存放在0x0008到0x0009這兩個(gè)字節(jié)空間中,符合0x0008%2=0。所以從0x0000到0x0009存放的
都是B內(nèi)容。再看數(shù)據(jù)結(jié)構(gòu)B的自身對(duì)齊值為其變量中最大對(duì)齊值(這里是b)所以就是4,所以結(jié)構(gòu)體的有效對(duì)齊值也是4。根據(jù)結(jié)構(gòu)體圓整的要求,
0x0009到0x0000=10字節(jié),(10+2)%4=0。所以0x0000A到0x000B也為結(jié)構(gòu)體B所占用。故B從0x0000到0x000B
共有12個(gè)字節(jié),sizeof(struct B)=12;其實(shí)如果就這一個(gè)就來(lái)說(shuō)它已將滿足字節(jié)對(duì)齊了,
因?yàn)樗钠鹗嫉刂肥?,因此肯定是對(duì)齊的,之所以在后面補(bǔ)充2個(gè)字節(jié),是因?yàn)榫幾g器為了實(shí)現(xiàn)結(jié)構(gòu)數(shù)組的存取效率,試想如果我們定義了一個(gè)結(jié)構(gòu)B的數(shù)組,那
么第一個(gè)結(jié)構(gòu)起始地址是0沒(méi)有問(wèn)題,但是第二個(gè)結(jié)構(gòu)呢?按照數(shù)組的定義,數(shù)組中所有元素都是緊挨著的,如果我們不把結(jié)構(gòu)的大小補(bǔ)充為4的整數(shù)倍,那么下一
個(gè)結(jié)構(gòu)的起始地址將是0x0000A,這顯然不能滿足結(jié)構(gòu)的地址對(duì)齊了,因此我們要把結(jié)構(gòu)補(bǔ)充成有效對(duì)齊大小的整數(shù)倍.其實(shí)諸如:對(duì)于char型數(shù)據(jù),其
自身對(duì)齊值為1,對(duì)于short型為2,對(duì)于int,float,double類型,其自身對(duì)齊值為4,這些已有類型的自身對(duì)齊值也是基于數(shù)組考慮的,只
是因?yàn)檫@些類型的長(zhǎng)度已知了,所以他們的自身對(duì)齊值也就已知了.
同理,分析上面例子C:
#pragma pack (2) /*指定按2字節(jié)對(duì)齊*/
struct C
{
char b;
int a;
short c;
};
#pragma pack () /*取消指定對(duì)齊,恢復(fù)缺省對(duì)齊*/
第
一個(gè)變量b的自身對(duì)齊值為1,指定對(duì)齊值為2,所以,其有效對(duì)齊值為1,假設(shè)C從0x0000開始,那么b存放在0x0000,符合0x0000%1=
0;第二個(gè)變量,自身對(duì)齊值為4,指定對(duì)齊值為2,所以有效對(duì)齊值為2,所以順序存放在0x0002、0x0003、0x0004、0x0005四個(gè)連續(xù)
字節(jié)中,符合0x0002%2=0。第三個(gè)變量c的自身對(duì)齊值為2,所以有效對(duì)齊值為2,順序存放
在0x0006、0x0007中,符合
0x0006%2=0。所以從0x0000到0x00007共八字節(jié)存放的是C的變量。又C的自身對(duì)齊值為4,所以C的有效對(duì)齊值為2。又8%2=0,C
只占用0x0000到0x0007的八個(gè)字節(jié)。所以sizeof(struct C)=8.
1.在VC IDE中,可以這樣修改:[Project]|[Settings],c/c++選項(xiàng)卡Category的Code Generation選項(xiàng)的Struct Member Alignment中修改,默認(rèn)是8字節(jié)。
2.在編碼時(shí),可以這樣動(dòng)態(tài)修改:#pragma pack .注意:是pragma而不是progma.
如果在編程的時(shí)候要考慮節(jié)約空間的話,那么我們只需要假定結(jié)構(gòu)的首地址是0,然后各個(gè)變量按照上面的原則進(jìn)行排列即可,基本的原則就是把結(jié)構(gòu)中的變量按照
類型大小從小到大聲明,盡量減少中間的填補(bǔ)空間.還有一種就是為了以空間換取時(shí)間的效率,我們顯示的進(jìn)行填補(bǔ)空間進(jìn)行對(duì)齊,比如:有一種使用空間換時(shí)間做
法是顯式的插入reserved成員:
struct A{
char a;
char reserved[3];//使用空間換時(shí)間
int b;
}
reserved成員對(duì)我們的程序沒(méi)有什么意義,它只是起到填補(bǔ)空間以達(dá)到字節(jié)對(duì)齊的目的,當(dāng)然即使不加這個(gè)成員通常編譯器也會(huì)給我們自動(dòng)填補(bǔ)對(duì)齊,我們自己加上它只是起到顯式的提醒作用.
代碼中關(guān)于對(duì)齊的隱患,很多是隱式的。比如在強(qiáng)制類型轉(zhuǎn)換的時(shí)候。例如:
unsigned int i = 0x12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;
p=&i;
*p=0x00;
p1=(unsigned short *)(p+1);
*p1=0x0000;
最后兩句代碼,從奇數(shù)邊界去訪問(wèn)unsignedshort型變量,顯然不符合對(duì)齊的規(guī)定。
在x86上,類似的操作只會(huì)影響效率,但是在MIPS或者sparc上,可能就是一個(gè)error,因?yàn)樗鼈円蟊仨氉止?jié)對(duì)齊.
如果出現(xiàn)對(duì)齊或者賦值問(wèn)題首先查看
1. 編譯器的big little端設(shè)置
2. 看這種體系本身是否支持非對(duì)齊訪問(wèn)
3. 如果支持看設(shè)置了對(duì)齊與否,如果沒(méi)有則看訪問(wèn)時(shí)需要加某些特殊的修飾來(lái)標(biāo)志其特殊訪問(wèn)操作。
八.相關(guān)文章:轉(zhuǎn)自http://blog.csdn.net/goodluckyxl/archive/2005/10/17/506827.aspx
ARM下的對(duì)齊處理
from DUI0067D_ADS1_2_CompLib
3.13 type qulifiers
有部分摘自ARM編譯器文檔對(duì)齊部分
對(duì)齊的使用:
1.__align(num)
這個(gè)用于修改最高級(jí)別對(duì)象的字節(jié)邊界。在匯編中使用LDRD或者STRD時(shí)
就要用到此命令__align(8)進(jìn)行修飾限制。來(lái)保證數(shù)據(jù)對(duì)象是相應(yīng)對(duì)齊。
這個(gè)修飾對(duì)象的命令最大是8個(gè)字節(jié)限制,可以讓2字節(jié)的對(duì)象進(jìn)行4字節(jié)
對(duì)齊,但是不能讓4字節(jié)的對(duì)象2字節(jié)對(duì)齊。
__align是存儲(chǔ)類修改,他只修飾最高級(jí)類型對(duì)象不能用于結(jié)構(gòu)或者函數(shù)對(duì)象。
2.__packed
__packed是進(jìn)行一字節(jié)對(duì)齊
1.不能對(duì)packed的對(duì)象進(jìn)行對(duì)齊
2.所有對(duì)象的讀寫訪問(wèn)都進(jìn)行非對(duì)齊訪問(wèn)
3.float及包含float的結(jié)構(gòu)聯(lián)合及未用__packed的對(duì)象將不能字節(jié)對(duì)齊
4.__packed對(duì)局部整形變量無(wú)影響
5.強(qiáng)制由unpacked對(duì)象向packed對(duì)象轉(zhuǎn)化是未定義,整形指針可以合法定
義為packed。
__packed int* p; //__packed int 則沒(méi)有意義
6.對(duì)齊或非對(duì)齊讀寫訪問(wèn)帶來(lái)問(wèn)題
__packed struct STRUCT_TEST
{
char a;
int b;
char c;
} ; //定義如下結(jié)構(gòu)此時(shí)b的起始地址一定是不對(duì)齊的
//在棧中訪問(wèn)b可能有問(wèn)題,因?yàn)闂I蠑?shù)據(jù)肯定是對(duì)齊訪問(wèn)[from CL]
//將下面變量定義成全局靜態(tài)不在棧上
static char* p;
static struct STRUCT_TEST a;
void Main()
{
__packed int* q; //此時(shí)定義成__packed來(lái)修飾當(dāng)前q指向?yàn)榉菍?duì)齊的數(shù)據(jù)地址下面的訪問(wèn)則可以
p = (char*)&a;
q = (int*)(p+1);
*q = 0x87654321;
/*
得到賦值的匯編指令很清楚
ldr r5,0x20001590 ; = #0x12345678
[0xe1a00005] mov r0,r5
[0xeb0000b0] bl __rt_uwrite4 //在此處調(diào)用一個(gè)寫4byte的操作函數(shù)
[0xe5c10000] strb r0,[r1,#0] //函數(shù)進(jìn)行4次strb操作然后返回保證了數(shù)據(jù)正確的訪問(wèn)
[0xe1a02420] mov r2,r0,lsr #8
[0xe5c12001] strb r2,[r1,#1]
[0xe1a02820] mov r2,r0,lsr #16
[0xe5c12002] strb r2,[r1,#2]
[0xe1a02c20] mov r2,r0,lsr #24
[0xe5c12003] strb r2,[r1,#3]
[0xe1a0f00e] mov pc,r14
*/
/*
如果q沒(méi)有加__packed修飾則匯編出來(lái)指令是這樣直接會(huì)導(dǎo)致奇地址處訪問(wèn)失敗
[0xe59f2018] ldr r2,0x20001594 ; = #0x87654321
[0xe5812000] str r2,[r1,#0]
*/
在APUE 14.7節(jié)對(duì)消息隊(duì)列的講解中,最后一段說(shuō)“我們得出的結(jié)論是:在新的應(yīng)用程式中不應(yīng)當(dāng)再使用他們。”
雖然在新的應(yīng)用程式中不應(yīng)該再使用消息隊(duì)列,我也沒(méi)有怎么使用過(guò)System V IPC總覺(jué)得在UNIX/Linux編程中少了什么,也許學(xué)習(xí)一下System V IPC對(duì)我的自信心會(huì)有相當(dāng)大的幫助,從此我也敢講我知道如何使用IPC了。
先把各個(gè)函數(shù)原形列出。
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/msg.h>
int msgget(key_t key, int msgflag);
int msgsnd(int msgid, struct msgbuf *msgp, size_t msgsz, int msgflag);
ssize_t msgrcv(int msgid, struct msgbuf *msgp, size_t msgsz, long msgtype, int msgflag);
int msgctl(int msgid, int cmd, struct msqid_ds *buf);
msgget()用來(lái)創(chuàng)建Message Queue(服務(wù)端)或和一個(gè)已建立的Message
Queue連接(客戶端)。key,指定用來(lái)生成message
id的關(guān)鍵字,msgflag和open()的flags很相似,可用IPC_CREAT, IPC_EXECL, S_IRUSR等。
在服務(wù)端,可用IPC_PRIVATE(或0)來(lái)指定key值,來(lái)生成一個(gè)新的Message Queue,或使用指定的key值(32位的無(wú)符號(hào)數(shù)),或使用ftok()來(lái)生成一個(gè)key。
#include <sys/types.h>
#include <sys/ipc.h>
key_t ftok(const char *pathname, int proj_id);
在客戶端,能夠直接使用服務(wù)端生成的message
id(通過(guò)某些途徑傳送,如文檔,父子進(jìn)程),也能夠用msgget通過(guò)和服務(wù)端使用相同的key值來(lái)生成相同的message
id,但不能使用IPC_PRIVATE(或0),msgflag也不能使用IPC_CREAT。
Return Value: Sucess return value is the message id(non-negative integer), otherwise -1 return.
msgsnd()用來(lái)發(fā)送消息。
struct msgbuf {
long mtype;
char mtext[1];
};
msgsz的計(jì)算方法: msgsz = sizeof(msgbuf) - sizeof(long);
msgflag有一個(gè)標(biāo)志:IPC_NOWAIT。當(dāng)消息隊(duì)列已滿(可能是消息總數(shù)達(dá)到了限制值,也可能是隊(duì)列中字節(jié)總數(shù)達(dá)到了限制值),立即出錯(cuò)返回,假如沒(méi)有指定,則阻塞。
msgrcv()用來(lái)接收消息。msgtype用來(lái)指定讀取的消息類型。msgtype == 0, 返回第一個(gè)消息; msgtype >
0, 返回消息類型為msgtype的消息;msgtype < 0, 返回隊(duì)列中類型值小于msgtype的絕對(duì)值的消息集中最小的消息。
msgflag有兩個(gè)值:MSG_NOERROR, IPC_NOWAIT。當(dāng)MSG_NOERROR被指定的時(shí)候,若消息太長(zhǎng)就被截?cái)啵駝t返回錯(cuò)誤;IPC_NOWAIT用于需要讀取的消息不存在時(shí)則阻塞。
msgctl用于控制消息隊(duì)列。cmd有三種值:IPC_STAT,IPC_SET,IPC_RMID。
IPC_STAT用于取出消息隊(duì)列的 msqid_ds結(jié)構(gòu)并保存到buf中。
IPC_SET用來(lái)把buf指向的msqid_ds,配置成消息隊(duì)列的msqid_ds。只有四個(gè)值能夠更改:msg_perm.uid, msg_perm.gid,msg_perm.mode, msg_qbytes。
IPC_RMID用來(lái)刪除消息隊(duì)列。
struct msqid_ds
{
struct ipc_perm msg_perm;
ulong msg_qbytes; //max of bytes of queue
...
};
struct ipc_perm
{
uid_t uid; //owner's effective user id
gid_t gid; //owner's effective group id
uid_t cuid; //creator's effective user id
gid_t cgid; //creator's effective group id
mode_t mode; //access modes
ulong seq; //slot usage sequence number
key_t key;
};