• <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字節對齊。  回復  更多評論   

            統計

            色综合久久无码五十路人妻| 久久精品国产99久久久古代| 久久99精品国产| 99精品久久久久久久婷婷| 国产成人久久激情91| 99久久精品免费看国产| 久久久久久久综合日本亚洲 | 久久九九久精品国产| 久久国产视频99电影| 中文字幕久久波多野结衣av| 精品久久久久久久久中文字幕| 久久本道久久综合伊人| 亚洲国产精品无码久久久不卡 | 综合久久精品色| 97精品久久天干天天天按摩| 久久精品无码一区二区app| 久久天天躁狠狠躁夜夜躁2O2O| 精品久久久久一区二区三区| 青青草原精品99久久精品66| 久久综合九色综合久99| 亚洲国产成人久久综合一 | 国产成人久久精品麻豆一区 | 久久天天躁狠狠躁夜夜avapp| 久久噜噜电影你懂的| 久久久久久人妻无码| 色婷婷狠狠久久综合五月| 久久99久久99小草精品免视看| 亚洲乱码中文字幕久久孕妇黑人| 久久黄色视频| 香港aa三级久久三级| 精品久久人妻av中文字幕| 久久久久久国产a免费观看黄色大片| 国产高潮国产高潮久久久91 | 国产精品乱码久久久久久软件| 国产综合免费精品久久久| 2022年国产精品久久久久| 久久精品水蜜桃av综合天堂| 香蕉久久av一区二区三区| 亚洲狠狠婷婷综合久久久久| 亚洲精品高清国产一线久久| 亚洲精品乱码久久久久久久久久久久 |