C語(yǔ)言中longlong的用法http://www.awuit.com/c-language-the-usage-of-long-long/阿吳 |
C/C++ | 十一月, 03 2009 |
5 Comments在分析BT代碼的過(guò)程中，遇到了這樣的定義:long longline_position;很是納悶，在C語(yǔ)言中我還沒(méi)有見(jiàn)過(guò)這樣的寫(xiě)法，網(wǎng)上搜了，資料也很少，最后在C語(yǔ)言標準與實(shí)現這本書(shū)中找到了關(guān)于longlong的說(shuō)法。在C語(yǔ)言的C99標準擴展了新的整數類(lèi)型 long long，long是32位寬，占4個(gè)字節，long long通常被定義成 64位寬，也就可以實(shí)現了在32位機器上可以擴展8字節的數據，GUNC也支持，當然在64位平臺上就存在這個(gè)問(wèn)題了。C99標準并沒(méi)有硬性規定具體到某種平臺上的某種整數類(lèi)型究竟占用多少字節、能夠表示多大范圍的數值等，只是給出一條原則和一個(gè)參考數值集合，只要同時(shí)滿(mǎn)足這兩方面條件就算是符合 C 標準。
之后，我查看了C99標準：
—The rank of long long int shallbe greater than the rank of long int,which
shall be greater than the rank of int,which shall be greater than therank of short
int,which shall be greater than the rank of signed char.
意思是說(shuō)：
long long 的級別高于 long ，long 的級別高于 int ，int 的級別高于 short ，short 的級別高于 char。（另外有 _Bool 永遠是最低級別）。級別高的整數類(lèi)型的寬度大于等于級別較低的整數類(lèi)型。
編譯long long需要支持C99標準的編譯器才行，VC并不支持，但有對應的類(lèi)型__int64
C++ __int64用法
http://341871.blog.51cto.com/331871/71253轉自：[url]http://www.cnitblog.com/cockerel/archive/2006/08/16/15356.html[/url]C++的64位整數［原］by 赤兔在做ACM題時(shí)，經(jīng)常都會(huì )遇到一些比較大的整數。而常用的內置整數類(lèi)型常常顯得太小了：其中long 和int 范圍是[-2^31,2^31)，即-2147483648~2147483647。而unsigned范圍是[0,2^32)，即0~4294967295。也就是說(shuō)，常規的32位整數只能夠處理40億以下的數。
那遇到比40億要大的數怎么辦呢？這時(shí)就要用到C++的64位擴展了。不同的編譯器對64位整數的擴展有所不同?；贏(yíng)CM的需要，下面僅介紹VC6.0與g++編譯器的擴展。
VC的64位整數分別叫做__int64與unsigned __int64，其范圍分別是[-2^63, 2^63)與[0,2^64)，即-9223372036854775808~9223372036854775807與0~18446744073709551615(約1800億億)。對64位整數的運算與32位整數基本相同，都支持四則運算與位運算等。當進(jìn)行64位與32位的混合運算時(shí)，32位整數會(huì )被隱式轉換成64位整數。但是，VC的輸入輸出與__int64的兼容就不是很好了，如果你寫(xiě)下這樣一段代碼：
1 __int64 a;
2 cin >> a;
3 cout << a;
那么，在第2行會(huì )收到“errorC2679: binary '>>' : no operator defined which takes a right-handoperand of type '__int64' (or there is no acceptable conversion)”的錯誤；在第3行會(huì )收到“error C2593: 'operator<<' is ambiguous”的錯誤。那是不是就不能進(jìn)行輸入輸出呢？當然不是，你可以使用C的寫(xiě)法：
scanf("%I64d",&a);
printf("%I64d",a);
就可以正確輸入輸出了。當使用unsigned __int64時(shí)，把"I64d"改為"I64u"就可以了。
OJ通常使用g++編譯器。其64位擴展方式與VC有所不同，它們分別叫做longlong 與 unsigned long long。處理規模與除輸入輸出外的使用方法同上。對于輸入輸出，它的擴展比VC好。既可以使用
1 long long a;
2 cin>>a;
3cout<<a;
也可以使用
scanf("%lld",&a);
printf("%lld",a);
使用無(wú)符號數時(shí)，將"%lld"改成"%llu"即可。
最后我補充一點(diǎn)：作為一個(gè)特例，如果你使用的是Dev-C++的g++編譯器，它使用的是"%I64d"而非"%lld"。
__int64的printf問(wèn)題！
http://blog.chinaunix.net/u/19782/showart_403061.html把Linux的東西移植到Windows 下， 問(wèn)題真是多， 有時(shí)候感覺(jué)很是奇怪！ 今天有遇到了一個(gè)！
__int64在 Windows下怎么輸出的問(wèn)題？ 我還以為是強制轉換的時(shí)候出問(wèn)題了， 查了好長(cháng)時(shí)間！
下面是測試代碼， 已經(jīng)通過(guò)Windws, Linux兩個(gè)平臺的測試了！
#include <stdio.h>
#ifdef _WIN32
typedef unsigned __int64 uint64_t;
#else
typedef unsigned long long uint64_t;
#endif
typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
int main(int argc, char *argv[])
{
uint32_t t321, t322, t323;
uint64_t t641, t642, t643;
uint8_t *p;
uint8_t t[64] =
{
0x4E, 0x7C, 0x00, 0x00, 0x00, 0x00,
0x4E, 0x7C, 0x00, 0x00, 0x00, 0x00,
0x04, 0x00, 0x00, 0x00, 0x00, 0x00
};
printf(
"sizeof(uint64_t) = %d\n"
"sizeof(uint32_t) = %d\n"
, sizeof(uint64_t), sizeof(uint32_t));
p = t;
t321 = *(uint32_t *)p; p += 6;
t322 = *(uint32_t *)p; p += 6;
t323 = *(uint32_t *)p; p += 6;
printf("t321[%X].%d t322[%X].%d t323[%X].%d\n"
, t321, t321, t322, t322, t323, t323);
p = t;
t641 = *(uint32_t *)p; p += 6;
t642 = *(uint32_t *)p; p += 6;
t643 = *(uint32_t *)p; p += 6;
#ifdef _WIN32
printf("t641[%I64X].%I64d t642[%I64X].%I64d t643[%I64X].%I64d\n"
, t641, t641, t642, t642, t643, t643);
#else
printf("t641[%llX].%lld t642[%llX].%lld t643[%llX].%lld\n"
, t641, t641, t642, t642, t643, t643);
#endif
t641 = 0x1122334455667788;
#ifdef _WIN32
printf("%I64X %I64d \n", t641, t641);
#else
printf("%llX %lld \n", t641, t641);
#endif
return 0;
}
/*
Test Env:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Microsoft Windows 2000 [Version 5.00.2195]
Result:
sizeof(uint64_t) = 8
sizeof(uint32_t) = 4
t321[7C4E].31822 t322[7C4E].31822 t323[4].4
t641[7C4E].31822 t642[7C4E].31822 t643[4].4
1122334455667788 1234605616436508552
--------------------------------------
Test Env:
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3)
Result:
sizeof(uint64_t) = 8
sizeof(uint32_t) = 4
t321[7C4E].31822 t322[7C4E].31822 t323[4].4
t641[7C4E].31822 t642[7C4E].31822 t643[4].4
1122334455667788 1234605616436508552
*/
在進(jìn)行移植的時(shí)候可能用的上的：
#ifdef _WIN32
# define APR_UINT64_T_HEX_FMT "llx"
#else
# define APR_UINT64_T_HEX_FMT "I64x"
#endif
example:
sprintf(buf, "%" APR_UINT64_T_HEX_FMT, var);
#define HOST_WIDEST_INT_PRINT_DEC "%I64d"
#define HOST_WIDEST_INT_PRINT_UNSIGNED "%I64u"
#define HOST_WIDEST_INT_PRINT_HEX "0x%I64x"
TAG
__int64printfuint64_t發(fā)表于： 2007-10-18，修改于： 2007-10-18 16:21
（#）
