• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

                  最近調試網絡的服務端程序,自己寫了一個小客戶端程序來測試,發現服務程序解包錯誤。經調試發現客戶端的協議頭大小和服務器端的協議頭大小不一致。原因是服務器端加了#pragma pack(1),而客戶端沒加。

                之前沒接觸過這個編譯宏,現在來認真學習之。

                首先google~~

                原來#pragma pack有幾種形式,我所接觸到的是#pragma pack(n),即變量以n字節對齊。

                變量對齊在每個系統中是不一樣的,默認的對齊方式能有效的提高cpu取指取數的速度,但是可能會浪費一定的空間。在網絡程序中采用#pragma pack(1),即變量緊縮,不但可以減少網絡流量,還可以兼容各種系統,不會因為系統對齊方式不同而導致解包錯誤。

                了解了概念和優點,現在我們就來測試之~

             

                平臺:CPU—Pentium E5700 內存—2G

                 1.操作系統:ubuntu 11.04 32bit   編譯器:G++ 4.5.2

                 2.操作系統:windows xp              編譯器:VS2010

             

                先看第一個測試。

                結構體在正常情況和緊縮情況在以上不同環境下占用的內存大小。

            1 struct pack {
            2   int i;
            3   short s;
            4   double d;
            5   char c;
            6   short f;
            7 }

              
               測試結果為:

                1
               

             

                2
                
              
                測試結果分析:

             

             

                可以看出緊縮后結構體的大小為15,是結構體內置類型大小的和。但是在默認情況下,結構體的大小都是對齊字節數的倍數。ubuntupack只需要20個字節,而windows24個字節。這是因為ubuntu是以4字節對齊,而windows則是以最大的內置類型的字節數對齊,在結構體內最大的內置類型為double,其大小為8個字節。他們在內存中的對齊方式如下圖:

                1

                

                2

                

               還需注意的是,在對齊類型的內部都是以2字節對齊的。

               結論:在默認情況下,linux操作系統是以4字節對齊,windows操作系統則是以最大的內置類型對齊。

             

               第二個測試

               一個結構體內包含另外一個結構體,其大小的情況。

               內部的結構體為

            1 struct pack {
            2   short s;
            3   double d;
            4 }

               外部的結構體為

               1 struct complex _pack{

            2   char c;
            3   struct pack s;
            4   double d;
            5 };

                我們有四種情況:

                 1.      pack緊縮,complex _pack緊縮

                 2.      pack緊縮,complex _pack默認

                 3.      pack默認,complex _pack緊縮

                 4.      pack默認,complex _pack默認

                以下的排列均按此順序。

                 測試的結果

                  1

                  

                 2

                  

                測試結果分析:

                在兩個操作系統下,除了第一種情況----內結構體和外結構體都緊縮----相同之外,其他三種情況都不相同。我們可以根據偏移畫出結構體在內存中的情況。第一種情況省略。

                 1

                 

                 2

                 

                結論:#pragma pack只影響當前結構體的變量的對齊情況,并不會影響結構體內部的結構體變量的排列情況?;蛘哒f#pragma pack的作用域只是一層。我們由第三種情況,內部結構體正常,外部結構體緊縮,可以得出結構體的對齊是按偏移計算的。

                這里還有一個問題沒解決,為什么第二種情況內部結構體的偏移都是1?不是4或者8?

             

            posted on 2011-07-15 20:36 Range 閱讀(6227) 評論(6)  編輯 收藏 引用
            評論
            • # re: #pragma pack學習
              13174115@qq.com
              Posted @ 2011-07-16 12:50
              樓主你的畫圖工具不錯啊,是什么呢?
                回復  更多評論   
            • # re: #pragma pack學習
              johnnie
              Posted @ 2011-07-20 12:50
              我覺得pack(4)已經OK了,沒必要pack(1),畢竟對齊是為了方便自己的CPU。
              要減少網絡流量的話,可以在發數據前將其壓縮一下,收之前再解壓一次。  回復  更多評論   
            • # re: #pragma pack學習
              Range
              Posted @ 2011-07-21 16:37
              @johnnie

              pack(4)的確是很好的建議,但是具體的情況還需要應用。

              IM,bittorrent 這種網絡程序一般都是IO-bound。CPU的消耗不是很大吧。  回復  更多評論   
            • # re: #pragma pack學習
              Range
              Posted @ 2011-07-21 16:38
              @13174115@qq.com

              visio  回復  更多評論   
            • # re: #pragma pack學習
              劉明杰
              Posted @ 2011-07-21 17:35
              這個15怎么來的,4+2+8+1+2=17,而且我vs2008上跑了也是17。。。。。  回復  更多評論   
            • # re: #pragma pack學習
              Range
              Posted @ 2011-07-22 10:29
              @劉明杰

              謝謝你的提醒,我回頭看了下代碼,pack(1)時候的代碼,沒加short f。

              short f是我后來加上去的,為的是看出在默認情況下,內部會以2字節對齊。  回復  更多評論   

            統計

            久久精品亚洲男人的天堂| 久久www免费人成看片| 久久精品中文字幕久久| 久久精品国产亚洲欧美| 久久久久国色AV免费观看| 日韩人妻无码一区二区三区久久99| 亚洲欧美成人综合久久久| 国内精品久久久久久麻豆| 精品人妻伦九区久久AAA片69| 久久se精品一区精品二区| 久久99精品国产麻豆宅宅| 久久久久女人精品毛片| 日本久久久精品中文字幕| 久久无码AV中文出轨人妻| 久久久久国产亚洲AV麻豆| 久久这里只有精品首页| 久久综合丁香激情久久| 综合网日日天干夜夜久久| 久久久受www免费人成| 久久99国产精一区二区三区| 99精品国产99久久久久久97| 久久人人爽人人爽AV片| 久久亚洲国产午夜精品理论片| 婷婷久久久亚洲欧洲日产国码AV| 国产精品无码久久久久| 精品一区二区久久久久久久网站| 久久久噜噜噜久久熟女AA片| 久久久久久国产精品美女| 亚洲欧洲中文日韩久久AV乱码| 久久本道久久综合伊人| 精品久久久久久无码人妻热| 色偷偷888欧美精品久久久| 日本精品久久久久中文字幕| 秋霞久久国产精品电影院| 日韩一区二区久久久久久| 青青热久久综合网伊人| 91久久福利国产成人精品| 久久www免费人成精品香蕉| 久久久久亚洲AV综合波多野结衣| 久久久久国色AV免费看图片| 久久性生大片免费观看性|