青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

colorful

zc qq:1337220912

 

關于跨平臺數據類型的幾篇博文 有些矛盾

c++ 中關于int,unsigned int , short的跨平臺移植

int類型比較特殊,具體的字節數同機器字長和編譯器有關。如果要保證移植性,盡量用__int16 __int32 __int64吧
__int16、__int32這種數據類型在所有平臺下都分配相同的字節。所以在移植上不存在問題。
所謂的不可移植是指:在一個平臺上編寫的代碼無法拿到另一個平臺上運行時,不能達到期望的運行結果
例如:在32為平臺上(所謂32位平臺是指通用寄存器的數據寬度是32)編寫代碼,int 類型分配4個字節,而在16位平臺是則分配2個字節,那么在16位上編譯出來的exe,
其中是為int分配2字節,而在32位平臺上運行時,會按照4個字節來解析,顯然會出錯誤的!!

而對于非int行,目前為止,所有的類型分配的字節數都是兼容的,即不同平臺對于同一個類型分配相同的字節數!!

建議:在代碼中盡量避免使用int類型,根據不同的需要可以用short,long,unsigned int 等代替。

下面是各個類型一覽表【轉】

64位指的是cpu通用寄存器的數據寬度是64位的。

數據類型名稱字節數別名取值范圍
int*signed,signed int操作系統決定,即與操作系統的"字長"有關
unsigned int*unsigned由操作系統決定,即與操作系統的"字長"有關
__int81char,signed char–128 到 127
__int162short,short int,signed short int–32,768 到 32,767
__int324signed,signed int–2,147,483,648 到 2,147,483,647
__int648–9,223,372,036,854,775,808 到 9,223,372,036,854,775,807
bool1false 或 true
char1signed char–128 到 127
unsigned char10 到 255
short2short int,signed short int–32,768 到 32,767
unsigned short2unsigned short int0 到 65,535
long4long int,signed long int–2,147,483,648 到 2,147,483,647
long long8none (but equivalent to __int64)–9,223,372,036,854,775,808 到 9,223,372,036,854,775,807
unsigned long4unsigned long int0 到 4,294,967,295
enum*由操作系統決定,即與操作系統的"字長"有關
float43.4E +/- 38 (7 digits)
double81.7E +/- 308 (15 digits)
long double81.7E +/- 308 (15 digits)
wchar_t2__wchar_t0 到 65,535
類型標識符類型說明長度
(字節)
范圍備注
char字符型1-128 ~ 127-27 ~ (27 -1)
unsigned char無符字符型10 ~ 2550 ~ (28 -1)
short int短整型2-32768 ~ 327672-15 ~ (215 - 1)
unsigned short int無符短整型20 ~ 655350 ~ (216 - 1)
int整型4-2147483648 ~ 2147483647-231 ~ (231 - 1)
unsigned int無符整型40 ~ 42949672950 ~ (232-1)
float實型(單精度)41.18*10-38 ~ 3.40*10387位有效位
double實型(雙精度)82.23*10-308 ~ 1.79*1030815位有效位
long double實型(長雙精度)103.37*10-4932 ~ 1.18*10493219位有效位


發表于 2011-04-15 14:02 阿π 閱讀(1812) 評論(4)  編輯 收藏 引用 所屬分類: 其它
 
評論
# re: c++ 中關于int,unsigned int , short的跨平臺移植
C99應該用int**_t
空明流轉 評論于 2011-04-15 16:14  回復  更多評論    
# re: c++ 中關于int,unsigned int , short的跨平臺移植
我也做過移植.
影響中16位平臺,多用C來開來,多是嵌入式開發.
32、64位在PC、服務器級較多,目前16位已很少.
我個人認為int型相于對long類型要安全.
long類型在windows-64下,仍是32字節;
但在LINUX-64下long和指針是相當的,已升級到了64字節,
如果結構體中使用long,結果大小有變,windows64下做的資源在linux下64處理,會有問題,
最常見的資源頭大小就一致.
如果是大型項目,還是建立自己的一套低層基本數據類型封裝方為上策.
bbxyard 評論于 2011-04-15 23:33  回復  更多評論    
# re: c++ 中關于int,unsigned int , short的跨平臺移植[未登錄]
lz說的不對,應該用int8_t, int16_t,int32_t, int64_t, uintXX_t 等等。而以兩個下劃線開頭的那種類型是微軟自己的東西,是不可以移植的。
Alex 評論于 2011-04-16 23:52  回復  更多評論    
# re: c++ 中關于int,unsigned int , short的跨平臺移植
原來這么復雜啊,分析的好詳細,頂!
free keylogger 評論于 2011-09-08 22:46  回復  更多評論    
 

============================================================

C/C++ 32位機器和64位機器 差異問題總結 跨平臺 移植問題 語言編程需要注意的64位和32機器的區別  

2011-09-28 22:39:45|  分類: C++ |  標簽:c++  64位機  數據類型   |字號 訂閱

轉載自:http://hi.baidu.com/jrckkyy/blog/item/61d7869b264d64aec8eaf411.html

#include <stddef.h>

OS version:Red Hat Enterprise Linux Server release 5.3 (Tikanga) Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

size_t本身一個作用就是避免考慮64還是32。64位下Long和指針是64位的

size_tm_unNo;

sprintf(path,"%u",m_unNo); //這句在32位機器上正常 64位機器上會編譯警告:“警告:格式 ‘%u’ 需要類型 ‘unsigned int’,但實參 4 的類型為 ‘size_t’”

%u 對應 unsigned int在64位機器上還是32位,而size_t已經變成64位了。

char* 指針在64位下是64位

m_pMem = new char[nSize];
int off = (int)m_pMem%nAlign; // 在 32位編譯正常,在64位機器上編譯報錯:“ 錯誤:從 ‘char*’ 到 ‘int’ 的轉換損失精度”

改為就可以達到兼容效果了int off = (uint64_t)m_pMem%nAlign; // 因為int在64位下仍為32位,char×已經變位64位了。

 

 

 

 

一、數據類型特別是int相關的類型在不同位數機器的平臺下長度不同。C99標準并不規定具體數據類型的長度大小,只規定級別。作下比較:

16位平臺

char         1個字節8位

short        2個字節16位

int            2個字節16位

long         4個字節32位

指針         2個字節

32位平臺

char         1個字節8位

short        2個字節16位

int            4個字節32位

long         4個字節

long long 8個字節

指針         4個字節

64位平臺

char         1個字節

short        2個字節

int            4個字節

long         8個字節(區別)

long long 8個字節

指針        8個字節(區別)

二、編程注意事項

為了保證平臺的通用性,程序中盡量不要使用long數據庫型。可以使用固定大小的數據類型宏定義:

typedef signed char       int8_t

typedef short int             int16_t;

typedef int                      int32_t;

# if __WORDSIZE == 64
typedef long int              int64_t;
# else
__extension__
typedef long long int      int64_t;

#endif

三、使用int時也可以使用intptr_t來保證平臺的通用性,它在不同的平臺上編譯時長度不同,但都是標準的平臺長度,比如64位機器它的長度就是8字節,32位機器它的長度是4字節,定義如下:

#if __WORDSIZE == 64
typedef long int                intptr_t;
#else
typedef int                        intptr_t;
#endif
編程中要盡量使用sizeof來計算數據類型的大小

以上類型定義都有相應的無符號類型。

另 外還有ssize_t和size_t分別是unsigned和signed size of computer word size。它們也是表示計算機的字長,在32位機器上是int型,在64位機器上long型,從某種意義上來說它們等同于intptr_t和 uintptr_t。它們在stddef.h里面定義。需要注意的是socket的accept函數在有些操作系統上使用size_t是不正確的,因為 accept接收的int*類型,而size_t可能是long int 類型。后來BSD使用sock_t來替代它。

posted on 2012-05-15 17:00 多彩人生 閱讀(1623) 評論(0)  編輯 收藏 引用 所屬分類: 跨平臺


只有注冊用戶登錄后才能發表評論。
網站導航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


導航

統計

常用鏈接

留言簿(3)

隨筆分類

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            久久综合亚洲社区| 欧美激情1区2区| 一区免费观看视频| 国产视频精品va久久久久久| 国产精品日韩在线观看| 国产欧美另类| 国产一区二区三区四区五区美女| 久久午夜色播影院免费高清| 中文欧美在线视频| 亚洲图中文字幕| 欧美一区二区高清在线观看| 欧美一区影院| 久久视频在线视频| 欧美日韩另类视频| 国产综合久久| 99视频精品全部免费在线| 亚洲一区二区三区四区中文| 亚洲欧美在线免费观看| 蜜臀va亚洲va欧美va天堂 | 国产欧美在线视频| 亚洲成人自拍视频| 国产精品99久久久久久久女警| 午夜精品在线看| 欧美高清不卡| 亚洲欧美日韩人成在线播放| 久久久久久综合网天天| 欧美日韩一区二区在线| 狠狠色狠狠色综合人人| 夜夜爽夜夜爽精品视频| 久久精品理论片| 99re热这里只有精品视频| 午夜影视日本亚洲欧洲精品| 欧美福利视频一区| 国产综合一区二区| 亚洲永久精品国产| 亚洲人成在线观看网站高清| 亚洲欧美一区二区原创| 欧美黄色免费网站| 亚洲第一色中文字幕| 欧美一区成人| 亚洲视频1区2区| 欧美人在线观看| 亚洲风情在线资源站| 久久成人免费日本黄色| 亚洲人妖在线| 免费一级欧美片在线播放| 国产三区精品| 性欧美暴力猛交69hd| 亚洲精品视频二区| 欧美裸体一区二区三区| 亚洲福利在线看| 鲁大师影院一区二区三区| 午夜精品福利在线| 国产老肥熟一区二区三区| 一区二区三区欧美日韩| 亚洲激情网站| 欧美高清日韩| 一区二区不卡在线视频 午夜欧美不卡在| 久久精品成人一区二区三区蜜臀 | 久久精品国产一区二区电影| 欧美视频日韩视频| 欧美日韩一区二区在线观看| 亚洲国产清纯| 久久全国免费视频| 亚洲精品中文字| 欧美日韩久久久久久| 在线亚洲+欧美+日本专区| 亚洲日本无吗高清不卡| 欧美成在线视频| 99精品99| 亚洲午夜三级在线| 国产亚洲永久域名| 美日韩在线观看| 欧美福利在线| 亚洲自拍偷拍视频| 性欧美办公室18xxxxhd| 国产视频欧美视频| 久久久综合视频| 欧美承认网站| 先锋a资源在线看亚洲| 欧美在线欧美在线| 亚洲激情影院| 一区二区三区导航| 国产偷自视频区视频一区二区| 久久久久久电影| 欧美刺激性大交免费视频| 亚洲图片激情小说| 久久成人资源| 一区二区三区四区五区精品视频| 亚洲午夜激情| 亚洲国产日韩一区| 亚洲一区免费网站| 亚洲激情在线观看视频免费| 日韩亚洲综合在线| 国内视频精品| 亚洲美女少妇无套啪啪呻吟| 国产日韩欧美日韩| 91久久国产综合久久91精品网站| 国产精品美女在线| 欧美波霸影院| 国产欧美 在线欧美| 欧美成人激情视频| 国产精品日韩在线播放| 亚洲大胆视频| 国产一区久久久| 一本色道久久综合亚洲91| 伊人色综合久久天天| 中文日韩欧美| 亚洲精品中文字幕有码专区| 午夜在线精品偷拍| 亚洲视频一起| 欧美国产日韩视频| 另类欧美日韩国产在线| 国产精品国产成人国产三级| 欧美成人精品三级在线观看| 国产精品视频精品视频| 亚洲人成小说网站色在线| 怡红院精品视频| 欧美一区二区福利在线| 亚洲影视在线播放| 欧美日韩精品一区二区在线播放 | 欧美中文字幕在线| 国产婷婷色综合av蜜臀av| 亚洲人线精品午夜| 亚洲第一区在线| 久久av一区二区三区| 午夜视频久久久| 欧美吻胸吃奶大尺度电影| 亚洲国产精品久久精品怡红院| 国产一区二区无遮挡| 亚洲午夜精品久久| 亚洲免费视频观看| 欧美视频在线观看 亚洲欧| 亚洲国产精彩中文乱码av在线播放| 国产婷婷色综合av蜜臀av| 亚洲欧美国产另类| 欧美在线日韩精品| 国产日韩一区在线| 欧美中文字幕精品| 久久视频精品在线| 激情久久久久| 久久久亚洲国产天美传媒修理工| 久久久久久久国产| 好吊一区二区三区| 久久艳片www.17c.com| 免费日韩精品中文字幕视频在线| 一区视频在线播放| 欧美高清hd18日本| 亚洲毛片播放| 羞羞视频在线观看欧美| 国产情侣一区| 久久精品视频播放| 欧美黄在线观看| 亚洲天堂成人在线观看| 国产精品成人一区二区三区夜夜夜 | 亚洲欧美视频在线观看视频| 欧美一区二区三区免费大片| 国产日韩精品一区二区浪潮av| 校园春色国产精品| 欧美激情精品久久久久久久变态| 亚洲日本中文字幕免费在线不卡| 欧美区一区二| 亚洲午夜性刺激影院| 久久久久久噜噜噜久久久精品| 精久久久久久久久久久| 欧美激情精品久久久久久久变态 | 久久婷婷国产综合尤物精品| 很黄很黄激情成人| 欧美激情亚洲自拍| 午夜精品久久久久久久99水蜜桃 | 亚洲欧美日韩在线播放| 国产欧美日韩综合精品二区| 久久国产手机看片| 亚洲精品久久嫩草网站秘色| 午夜一区二区三区不卡视频| 伊人成年综合电影网| 欧美日韩精品一区| 久久久久久夜精品精品免费| 一本一本大道香蕉久在线精品| 欧美激情久久久| 老司机午夜免费精品视频| 激情五月综合色婷婷一区二区| 一区二区欧美日韩| 久久美女性网| 日韩午夜免费视频| 久久久久久欧美| 狠狠狠色丁香婷婷综合久久五月| 亚洲日本va午夜在线电影| 亚洲精品一区二区三区蜜桃久| 久久狠狠亚洲综合| 欧美va天堂| 巨乳诱惑日韩免费av| 国产精品一区久久久久| 亚洲美女黄网| 欧美凹凸一区二区三区视频| 亚洲欧美制服另类日韩| 美女91精品| 日韩一本二本av| 亚洲影院色在线观看免费| 欧美成人性网|