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

            統計

            久久国产精品无码HDAV| 久久精品亚洲乱码伦伦中文| 日韩久久久久中文字幕人妻| 精品午夜久久福利大片| 韩国无遮挡三级久久| 亚洲中文字幕伊人久久无码 | 中文精品久久久久国产网址 | 久久e热在这里只有国产中文精品99| 久久久精品国产sm调教网站| 国产精品久久久99| 丁香狠狠色婷婷久久综合| 久久国产亚洲精品| 免费国产99久久久香蕉| 99久久无色码中文字幕人妻| 手机看片久久高清国产日韩| 国产精品久久久久9999| 久久97精品久久久久久久不卡| 亚洲人成无码网站久久99热国产| 国产精品久久久久影院嫩草| 一本色道久久综合| 丁香色欲久久久久久综合网| 熟妇人妻久久中文字幕| 亚洲精品乱码久久久久久蜜桃图片| 免费精品久久久久久中文字幕| 久久精品国产一区二区三区不卡 | 亚洲精品乱码久久久久久| 久久人妻少妇嫩草AV蜜桃| 97r久久精品国产99国产精| 欧美精品一本久久男人的天堂| 91久久九九无码成人网站| 久久久久国产精品嫩草影院| 色综合久久天天综线观看| 久久夜色精品国产噜噜亚洲AV| 久久精品人人槡人妻人人玩AV| 久久精品午夜一区二区福利| 国内精品久久久久久不卡影院| 亚洲日本久久久午夜精品| 久久91亚洲人成电影网站| 久久精品国产欧美日韩99热| 久久久久无码国产精品不卡| 久久不射电影网|