• <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只影響當前結構體的變量的對齊情況,并不會影響結構體內部的結構體變量的排列情況。或者說#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字節對齊。  回復  更多評論   

            統計

            久久久久久一区国产精品| 久久播电影网| 久久久久国产一级毛片高清板| 国产精品久久久天天影视| 久久亚洲欧美国产精品| 波多野结衣中文字幕久久| 国产AV影片久久久久久| 中文精品久久久久人妻| 精品少妇人妻av无码久久| 亚洲国产精品一区二区久久hs| 久久精品国产99久久无毒不卡| 亚洲成色999久久网站| 美女久久久久久| 久久天天躁狠狠躁夜夜躁2O2O| 亚洲综合精品香蕉久久网| 久久99毛片免费观看不卡| 久久久久久亚洲精品无码| 色狠狠久久综合网| 久久99精品国产| 久久久久18| 久久SE精品一区二区| 99久久精品国产一区二区蜜芽| 国产91久久综合| 2021国产精品午夜久久| 国产精品嫩草影院久久| 国产毛片欧美毛片久久久| 国产亚洲美女精品久久久久狼| 久久国产精品免费一区| 亚洲精品乱码久久久久久蜜桃图片| 久久精品国内一区二区三区| 亚洲?V乱码久久精品蜜桃| 999久久久免费国产精品播放| 亚洲日本va午夜中文字幕久久 | 亚洲香蕉网久久综合影视| 国产精品99久久99久久久| 亚洲а∨天堂久久精品9966| 人妻丰满AV无码久久不卡| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 思思久久99热只有频精品66| 久久久av波多野一区二区| 亚洲国产成人久久一区久久|