我知道長之間的區別和int 但與「長長」和「長整型」什麼是很長很長和長整型
回答
有幾種內置類型的簡寫。
short
是(signed
)short int
long
是(signed
)long int
long long
是(signed
)long long int
。
在許多系統中,short
是16位的,是long
32位和long long
是64位。但是,請記住,該標準只要求
sizeof(char) == 1
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
而這樣做的結果是,一個奇特的系統上,sizeof(long long) == 1
是可能的。
你有這個標準的更多保證:sizeof(long long)* CHAR_BITS> = 64而sizeof(long)* CHAR_BITS> = 32 –
我沒有一個標準的方便副本,只是查看它[The C++ Programming Language](http://www.amazon.com/Programming-Language-3rd-Bjarne-Stroustrup/dp/0201889544)。 –
@LokiAstari:我認爲這些保證基本上只是源於鴿巢原則,對吧?對於任何可能的long值,都必須有一些'unsigned char'類型的sizeof(long)'值的序列, (1 <<(CHAR_BITS * sizeof(long)))個可能的字符序列必須至少能夠識別出'(1LL << 32)'這樣的值。 – supercat
在16位系統上的int
是16位。 「long
」是作爲32位整數引入的,但在32位系統上,long
和int
意味着相同的事物(都是32位)。因此在32和64位系統上,long long
和long int
都是64位。例外是64位UNIX,其中long
是64位。
有關更詳細的表格,請參見the integer Wikipedia article。
無法保證在64位系統上int大於32.實際上,在Windows中,它可以取決於操作系統的編譯方式。即操作系統編譯爲64位平臺的32/64位? –
@Martin:「系統」我的意思是包括操作系統在內的整個配置,我現在意識到這一點並不清楚。 – richardolsson
你可能會說Windows例外。具有32位int和64位長和指針的系統稱爲「LP64」。帶有32位int和long和64位指針的系統稱爲「LLP64」(因爲Long Long和Pointer是64位)。 AFAIK所有主要的類Unix系統都使用LP64,Windows是唯一在64位機器上使用LLP64的主要系統。我不知道任何32位系統,其中'long int'與'long long'大小相同。長整型與長整型同義。 –
long int
是long的同義詞。 long long int
是long long int
的同義詞。
標準C++的唯一保證是long long
至少與long
一樣大,但可以更長。這在最新公佈的n3242標準草案的§3.9.1.2中有詳細說明。
C標準沒有對類型需要能夠表示的最小值範圍以外的整型類型提出任何特定的寬度要求,而且寬度也是非遞減的:short <= int <= long int <= long long int
(類似於無符號類型)。順便說一下,long long
僅成爲C99和C++ 0x標準的一部分。最低要求範圍可以在this Wikipedia article中找到。
按照C
標準的積分類型被定義以提供至少下列範圍內:
int -32767 to +32767 representable in 16 bits
long -2147483647 to +2147483647 representable in 32 bits
long long -9223372036854775807 to +9223372036854775807 representable in 64 bits
每一個都可以被表示爲以支持更寬範圍。在常見的32位系統上,int
和long
具有相同的32位表示。
請注意,負邊界與它們的正對稱對稱,以允許符號和大小表示形式:C語言標準不會施加二進制補碼。
@BaneOfSerenity這些值是從C語言標準的舊副本中引用的,正如我的答案中所述,並不是要描述整型是如何被普遍表示的。除非這些改變是我無法訪問的最新標準,否則您的更正是錯誤的* –
您提到的是什麼C標準文檔使得這些範圍保證? –
它們在ISO/IEC 9989:1999第5.2.4.2.1段中有規定。 「它們的實現定義的值應該等於或大於所示的數值(絕對值),具有相同的符號。」 –
我認爲:
「長」雙打分配給數據類型的位數。 這麼長(32位?)變爲64位。 Int(16位?)變爲32位。
在64位系統上,它們的大小沒有任何區別。在長的32位系統上,保證64位範圍的存儲值。
爲了避免所有這些混淆,最好使用標準積分類型:(u)int16_t, (u)int32_t and (u)int64_t
可通過stdint.h
提供,它提供了透明度。
唉,像'uint32_t'這樣的類型並不一定有幫助,因爲編譯器可以自由地使用更大的'int'類型並向其提升'uint32_t'。因此,(uint32_t)0xFFFFFFFF *(uint32_t)0xFFFFFFFF可能會產生1,或-8589934591或18446744065119617025(或者,因爲它可能會產生未定義的行爲,因此無論如何)。 – supercat
- 1. 的作用是什麼很長很長的常量
- 2. C++雙待很長很長
- 3. C/C++很長很長到Java長
- 4. 爲什麼Int64.MaxValue很長?
- 5. 爲什麼Serialrialuid在java中很長?
- 6. 爲什麼IIS7需要很長時間
- 7. XmlSerializer.Serialize需要很長時間...爲什麼?
- 8. 爲什麼字符長度很長時會出現在底部?
- 9. 很長的雙倍
- 10. 比Long.MAX_VALUE長很多
- 11. URL很長的UrlFetchApp.fetch
- 12. 很長的類名
- 13. 不能打印很長很長的雙輸出
- 14. RTU工具,很長很長(64位)的原始測試
- 15. 轉換雙待很長很長的目標C
- 16. ç無符號很長很長的失算
- 17. 爲什麼這會導致很長的整數溢出
- 18. CUDA atomicAdd()長長整型
- 19. 返回類型很長的表達
- 20. Node.js:很長的延遲
- 21. 爲很長的字符串
- 22. Rscript - 執行時間很長
- 23. MySQL的很長的查詢
- 24. 很長的部署時間
- 25. heroku部署時間很長
- 26. 模數真的很長(fmod)
- 27. 在.vimrc中換行很長
- 28. KnownFolders.VideosLibrary.GetFilesAsync()需要很長時間
- 29. 尋找很長的評論
- 30. HTTPURLConnection.getInputStream()需要很長時間?
[C++中int和long的區別是什麼?](http://stackoverflow.com/questions/271076/what-is-the-difference-between-an-int-and- a-long-in-c) –
@Martin:不完全相同。這個問題與'long int'語法與'long'有關。 –
@Andr:足夠接近那個問題的答案也可以回答這個問題。沒有必要重複的答案 –