- //爲了和DSP兼容,TSint64和TUint64設置成TSint40和TUint40一樣的數
- //結果VC中還是認爲是32位的,顯然不合適
- //typedef signed long int TSint64;
- //typedef unsigned long int TUint64;
- //ANSI C中規定long long才能表示64位
- //參見:http://msdn.microsoft.com/en-us/library/s3f49ktz.aspx
- //可惜VC++ 6.0 不認識 long long,會報error C2632: 'long' followed by 'long' is illegal
- typedef signed long long TSint64;//It's illegal in C90. It's legel in C99.
- typedef unsigned long long TUint64;
- //typedef LONGLONG TSint64;//VC不認
- //typedef ULONGLONG TUint64;
zz from http://www.byvoid.com/blog/c-int64/
在C/C++中,64爲整型一直是一種沒有確定規範的數據類型。現今主流的編譯器中,對64爲整型的支持也是標準不一,形態各異。一般來說,64位整型的定義方式有long long和__int64兩種(VC還支持_int64),而輸出到標準輸出方式有printf(“%lld”,a),printf(“%I64d”,a),和cout << a三種方式。
本文討論的是五種常用的C/C++編譯器對64位整型的支持,這五種編譯器分別是gcc(mingw32),g++(mingw32),gcc(linux i386),g++(linux i386),Microsoft Visual C++ 6.0。可惜的是,沒有一種定義和輸出方式組合,同時兼容這五種編譯器。爲徹底弄清不同編譯器對64位整型,我寫了程序對它們進行了評測,結果如下表。
變量定義 | 輸出方式 | gcc(mingw32) | g++(mingw32) | gcc(linux i386) | g++(linux i386) | MicrosoftVisual C++ 6.0 |
---|---|---|---|---|---|---|
long long | “%lld” | 錯誤 | 錯誤 | 正確 | 正確 | 無法編譯 |
long long | “%I64d” | 正確 | 正確 | 錯誤 | 錯誤 | 無法編譯 |
__int64 | “lld” | 錯誤 | 錯誤 | 無法編譯 | 無法編譯 | 錯誤 |
__int64 | “%I64d” | 正確 | 正確 | 無法編譯 | 無法編譯 | 正確 |
long long | cout | 非C++ | 正確 | 非C++ | 正確 | 無法編譯 |
__int64 | cout | 非C++ | 正確 | 非C++ | 無法編譯 | 無法編譯 |
long long | printint64() | 正確 | 正確 | 正確 | 正確 | 無法編譯 |
上表中,正確指編譯通過,運行完全正確;錯誤指編譯雖然通過,但運行結果有誤;無法編譯指編譯器根本不能編譯完成。觀察上表,我們可以發現以下幾點:
- long long定義方式可以用於gcc/g++,不受平臺限制,但不能用於VC6.0。
- __int64是Win32平臺編譯器64位長整型的定義方式,不能用於Linux。
- “%lld”用於Linux i386平臺編譯器,”%I64d”用於Win32平臺編譯器。
- cout只能用於C++編譯,在VC6.0中,cout不支持64位長整型。
表中最後一行輸出方式中的printint64()是我自己寫的一個函數,可以看出,它的兼容性要好於其他所有的輸出方式,它是一段這樣的代碼:
- void printint64(long long a)
- {
- if (a<=100000000)
- printf("%d/n",a);
- else
- {
- printf("%d",a/100000000);
- printf("%08d/n",a%100000000);
- }
- }
這種寫法的本質是把較大的64位整型拆分爲兩個32位整型,然後依次輸出,低位的部分要補0。看似很笨的寫法,效果如何?我把它和cout輸出方式做了比較,因爲它和cout都是C++支持跨平臺的。首先printint64()和cout(不清空緩衝區)的運行結果是完全相同的,不會出現錯誤。我的試驗是分別用兩者輸出1000000個隨機數,實際結果是,printint64()在1.5s內跑完了程序,而cout需要2s。cout要稍慢一些,所以在輸出大量數據時,要儘量避免使用。
zz from http://blog.csdn.net/zhlynn/archive/2009/03/28/4032152.aspx
64位整數全解(增補板)
64位整形引起的混亂主要在兩方面,一是數據類型的聲明,二是輸入輸出。
首先是如果我們在自己機器上寫程序的話,情況分類如下:
(1) 在win下的VC6.0裏面,聲明數據類型的時候應該寫作
__int64 a;
輸入輸出的時候用 %I64d
scanf(”%I64d”,&a);
printf(”%I64d”,a);
(2) 在linux下的gcc/g++裏面,數據類型聲明寫作
long long a;
輸入輸出時候用 %lld
(3) 在win下的其它IDE裏面[包括高版本Visual Studio],數據類型聲明用上面兩種均可
輸入輸出用 %I64d
================== 以下可無視 =========================
以下是對這種混亂情況的解釋,如無興趣可以跳過
首先要說的是,和Java等語言不同,C/C++本身並沒有規定各數據類型的位數,只是限定了一個大小關係,也就是規定從所佔的bit數來說,short <= int <= long <= long long。至於具體哪種類型佔用多少位,是由你所用的開發平臺的編譯器決定的。在現在的PC上一個通常的標準是,int和long同爲32位,long long爲64位。但是如果換到其它平臺(如ARM)上,這個數字可能會有不同,類型所佔的大小可以用sizeof()運算符查看。
long long是C99標準中新引進的數據類型,在古老的VC6.0中並沒有這個類型,所以在VC6.0中用”long long”會發生編譯錯誤。爲了表示64位整數,VC6裏採用的是微軟自己搞出來的一個數據類型,叫做__int64,所以如果你是在VC6.0下編譯的話,應該用__int64定義64位整型。新版的Visual Studio已經支持long long了。GCC是支持long long的,我們在win系統中使用的其它IDE如Dev-Cpp, Code::Blocks等等大多是採用的MinGW編譯環境,它是與GCC兼容的,所以也支持long long(另外爲了與MS兼容,也支持__int64)。如果是在純的linux下,就只能使用long long了。
關於使用printf的輸入輸出,這裏就有一個更囧的情況。實際上只要記住,主要的區分在於操作系統:如果在win系統下,那麼無論什麼編譯器,一律用%I64d;如果在linux系統,一律用%lld。這是因爲MS提供的msvcrt.dll庫裏使用的就是%I64d的方式,儘管Dev-Cpp等在語法上支持標準,但也不得不使用MS提供的dll庫來完成IO,所以就造成了這種情況。
==================== 無視至此 ===========================
那麼對ACMer來說,最爲關心的就是在各個OJ上交題應分別使用哪種方式了。其實方式只有有限的幾種:
如果服務器是linux系統,那麼定義用long long,IO用%lld
如果服務器是win系統,那麼聲明要針對編譯器而定:
+ 如果用MS系列編譯器,聲明用__int64 [現在新版的Visual Studio也支持long long了]
+ 如果用MinGW環境,聲明用long long
+ 無論什麼編譯器,IO一律%I64d
下面把各大OJ情況列表如下:
1. TOJ : Linux系統
2. ZOJ : Linux系統
3. POJ : Win系統,語言如選擇C/C++,則用MS編譯器[支持兩種聲明],如選擇GCC/G++,則爲MinGW
4. UVa : Linux系統
5. Ural: Win系統,MS編譯器[支持兩種聲明]
6. SPOJ: Linux系統
7. SGU : Win系統,MS編譯器[支持兩種聲明]
如果有不太清楚的情況可以先看看各OJ上的FAQ,通常會有說明。
另外,爲了避免混亂,當數據量不大時,用cin, cout進行輸入輸出也是一種選擇