Microsoft Visual C++ 不支持long long

Microsoft Visual C++ 不支持long long

在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位整型，我寫了程式對它們進行了評測，結果如下表。

這裡註意我標示的藍色部分，大寫的L和大寫的I一定要區分清楚

上表中，正確指編譯通過，運行完全正確；錯誤指編譯雖然通過，但運行結果有誤；無法編譯指編譯器根本不能編譯完成。觀察上表，我們可以發現以下幾點：

1. long long定義方式可以用於gcc/g++，不受平臺限制，但不能用於VC6.0。
2. __int64是Win32平臺編譯器64位長整型的定義方式，不能用於Linux。
3. “%lld”用於Linux i386平臺編譯器，”%I64d”用於Win32平臺編譯器。
4. 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進行輸入輸出也是一種選擇