• <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 閱讀(6213) 評論(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综合一区二区| 久久精品国产亚洲5555| 午夜精品久久久久久久久| 久久精品成人免费国产片小草| 久久97久久97精品免视看 | 精品免费久久久久久久| 久久频这里精品99香蕉久| 97久久天天综合色天天综合色hd| 久久精品18| 精品熟女少妇a∨免费久久| 久久男人AV资源网站| 久久天天躁狠狠躁夜夜96流白浆| 久久青青草视频| 99久久精品无码一区二区毛片| 久久久久人妻一区二区三区vr | 久久综合狠狠综合久久97色| 久久精品中文騷妇女内射| 色99久久久久高潮综合影院| 国产精品va久久久久久久| 国产香蕉97碰碰久久人人| 欧美熟妇另类久久久久久不卡| 国内精品久久久久久不卡影院| 色婷婷综合久久久中文字幕| 久久天天躁狠狠躁夜夜2020老熟妇| 亚洲中文字幕无码久久2017| 午夜精品久久久久久久| 中文字幕久久精品| 欧洲精品久久久av无码电影 | 2020国产成人久久精品| 色播久久人人爽人人爽人人片AV| 99久久婷婷国产综合精品草原| 国内精品久久人妻互换| 久久一日本道色综合久久| 一本色道久久综合亚洲精品| 国产色综合久久无码有码| 一本大道久久东京热无码AV| 亚洲七七久久精品中文国产 | 久久99国产精品99久久|