TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Summary of C/C++ integer rules

112 点作者 dmulholl大约 4 年前

9 条评论

MaxBarraclough大约 4 年前
[Dons language lawyer hat]<p>&gt; floating-point number types will not be discussed at all, because that mostly deals with how to analyze and handle approximation errors that stem from rounding. By contrast, integer math is a foundation of programming and computer science, and all calculations are always exact in theory (ignoring implementations issues like overflow).<p>Integer overflow is no mere implementation issue, any more than errors are an implementation issue with floating-point.<p>&gt; Unqualified char may be signed or unsigned, which is implementation-defined.<p>&gt; Unqualified short, int, long, and long long are signed. Adding the unsigned keyword makes them unsigned.<p>There&#x27;s an additional point here that&#x27;s not mentioned: <i>char</i>, <i>signed char</i>, and <i>unsigned char</i> are distinct types, but that&#x27;s only true of <i>char</i>. That is, <i>signed int</i> describes the same type as <i>int</i>. You can see this using the <i>std::is_same</i> type-trait with a conforming compiler. Whether <i>char</i> behaves like a signed integer type or an unsigned integer type, depends on the platform.<p>&gt; Signed numbers may be encoded in binary as two’s complement, ones’ complement, or sign-magnitude; this is implementation-defined.<p>This is no longer true of C++. As of C++20, signed integer types are defined to use two&#x27;s complement. [0] I don&#x27;t think C intends to do the same.<p>&gt; Character literals (in single quotes) have the type (signed) int in C, but (signed or unsigned) char in C++.<p>That&#x27;s not correct. In C++, the type of a character literal is simply <i>char</i>, never <i>signed char</i> nor <i>unsigned char</i>. As I mentioned above, whether <i>char</i> is signed depends on the platform, but it&#x27;s always a distinct type.<p>&gt; Signed division can overflow – e.g. INT_MIN &#x2F; -1.<p>This isn&#x27;t just overflow, it&#x27;s undefined behaviour.<p>&gt; Counting down<p>&gt; Whereas an unsigned counter would require code like:<p>&gt; for (unsigned int i = len; i &gt; 0; i--) { process(array[i - 1]); }<p>That&#x27;s one solution, but it might be a good place for a <i>do&#x2F;while</i> loop.<p>[0] <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;57363324&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;57363324&#x2F;</a>
评论 #26670586 未加载
评论 #26670440 未加载
评论 #26673785 未加载
评论 #26670470 未加载
评论 #26672466 未加载
saagarjha大约 4 年前
&gt; Having signed and unsigned variants of every integer type essentially doubles the number of options to choose from. This adds to the mental burden, yet has little payoff because signed types can do almost everything that unsigned ones can.<p>Unsigned types are quite useful when doing bit twiddling because they don&#x27;t overflow or have a bit taken up by the sign.
评论 #26670559 未加载
评论 #26670441 未加载
flohofwoe大约 4 年前
In the myths section:<p>&gt; char is always 8 bits wide. int is always 32 bits wide<p>&gt; Signed overflow is guaranteed to be wrap around. (e.g. INT_MAX + 1 == INT_MIN.)<p>Are there any current, relevant hardware architectures where this is not true (e.g. bytes are not 8 bits, and integers are not 2&#x27;s complement)?<p>E.g. what&#x27;s the point of &quot;portability&quot; if there is no physical hardware around anymore where those restrictions would apply?
评论 #26671369 未加载
评论 #26670607 未加载
评论 #26670758 未加载
评论 #26671049 未加载
评论 #26670581 未加载
评论 #26672946 未加载
评论 #26673464 未加载
评论 #26670599 未加载
评论 #26672996 未加载
评论 #26670664 未加载
RMPR大约 4 年前
What a coincidence this gets posted today, I posted something[0] a couple of hours ago about how specifically a combination of these rules can bite you very hard.<p>0: <a href="https:&#x2F;&#x2F;rmpr.xyz&#x2F;Integers-in-C&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rmpr.xyz&#x2F;Integers-in-C&#x2F;</a>
lifthrasiir大约 4 年前
&gt; Signed numbers may be encoded in binary as two’s complement, ones’ complement, or sign-magnitude; this is implementation-defined.<p>Thankfully, in addition to what MaxBarraclough helpfully pointed out, every (u)intN_t type provided by &lt;stdint.h&gt; is guaranteed to use two&#x27;s complement even in C99.
dahfizz大约 4 年前
One thing I think should have been mentioned: size_t is guaranteed to be large enough to index all of memory, which is why it is the return type of size of.
评论 #26671931 未加载
dreinhardt大约 4 年前
It’s funny that you would end up with a similar conclusion for other parts of the language (e.g. operators) as well. Just a gigantic set of inane rules everywhere causing you to constantly be in danger of introducing bugs and portability issues.
评论 #26670436 未加载
评论 #26670406 未加载
评论 #26670624 未加载
评论 #26670421 未加载
criddell大约 4 年前
This is one of the misconceptions:<p>&gt; sizeof(T) represents the number of 8-bit bytes (octets) needed to store a variable of type T.<p>That&#x27;s a misconception I had and I&#x27;ve never run into a problem. What&#x27;s a platform where sizeof works differently?<p>Also, what&#x27;s the reasoning for sizeof to be an operator rather than a function?
评论 #26670775 未加载
dvfjsdhgfv大约 4 年前
&gt; Python only has one integer type, which is a signed bigint. Compared to C&#x2F;C++, this renders moot all discussions about bit widths, signedness, and conversions – one type rules all the code. But the price to pay includes slow execution and inconsistent memory usage.<p>Well, the beauty of C is that you can have that too, if you wish, and you have many options to choose from.