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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

C and C++ prioritize performance over correctness (2023)

93 点作者 endorphine大约 1 个月前

15 条评论

nine_k大约 1 个月前
/* I can't help but remember a joke on the topic. One guy says: "I can operate on big numbers with insane speed!" The other says: "Really? Compute me 97408743 times 738423". The first guy, immediately: "987958749583333". The second guy takes out a calculator, checks the answer, and says: "But it's incorrect!". The first guy objects: "Despite that, it was very fast!" */
评论 #43546373 未加载
meling大约 1 个月前
I love the last sentence: “…, if you set yourself the goal of crossing an 8-lane freeway blindfolded, it does make sense to focus on doing it as fast as you possibly can.”
评论 #43544408 未加载
评论 #43537714 未加载
dang大约 1 个月前
Discussed at the time:<p><i>C and C++ prioritize performance over correctness</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37178009">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37178009</a> - Aug 2023 (543 comments)
gavinhoward大约 1 个月前
As a pure C programmer [1], let me post my full agreement: <a href="https:&#x2F;&#x2F;gavinhoward.com&#x2F;2023&#x2F;08&#x2F;the-scourge-of-00ub&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gavinhoward.com&#x2F;2023&#x2F;08&#x2F;the-scourge-of-00ub&#x2F;</a> .<p>[1]: <a href="https:&#x2F;&#x2F;gavinhoward.com&#x2F;2023&#x2F;02&#x2F;why-i-use-c-when-i-believe-in-memory-safety&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gavinhoward.com&#x2F;2023&#x2F;02&#x2F;why-i-use-c-when-i-believe-i...</a>
评论 #43539291 未加载
ajross大约 1 个月前
This headline is badly misunderstanding things. C&#x2F;C++ date from an era where &quot;correctness&quot; in the sense the author means wasn&#x27;t a feasible feature. There weren&#x27;t enough cycles at build time to do all the checking we demand from modern environments (e.g. building medium-scale Rust apps on a Sparcstation would be literally *weeks* of build time).<p>And more: the problem faced by the ANSI committee wasn&#x27;t something where they were tempted to &quot;cheat&quot; by defining undefined behavior at all. It&#x27;s that <i>there was live C code in the world that did this stuff</i>, for real and valid reasons. And they knew if they published a language that wasn&#x27;t compatible no one would use it. But there were also variant platforms and toolchains that didn&#x27;t do things the same way. So instead of trying to enumerate them all individually (which probably wasn&#x27;t possible anyway), they identified the areas where they knew they could define firm semantics and allowed the stuff outside that boundary to be &quot;undefined&quot;, so existing environments could continue to implement them compatibly.<p>Is that a good idea for a new language? No. But ANSI wasn&#x27;t writing a new language. They were adding features to the language in which Unix was already written.
评论 #43537466 未加载
评论 #43537270 未加载
评论 #43537560 未加载
评论 #43537327 未加载
评论 #43537849 未加载
pcwalton大约 1 个月前
I was disappointed that Russ didn&#x27;t mention the strongest argument for making arithmetic overflow UB. It&#x27;s a subtle thing that has to do with sign extension and loops. The best explanation is given by ryg here [1].<p>As a summary: The most common way given in C textbooks to iterate over an array is &quot;for (int i = 0; i &lt; n; i++) { ... array[i] ... }&quot;. The problem comes from these three facts: (1) i is a signed integer; (2) i is 32-bit; (3) pointers nowadays are usually 64-bit. That means that a compiler that can&#x27;t prove that the increment on &quot;i&quot; won&#x27;t overflow (perhaps because &quot;n&quot; was passed in as a function parameter) has to do a sign extend on every loop iteration, which adds extra instructions in what could be a hot loop, especially since you can&#x27;t fold a sign extending index into an addressing mode on x86. Since this pattern is so common, compiler developers are loath to change the semantics here--even a 0.1% fleet-wide slowdown has a cost to FAANG measured in the millions.<p>Note that the problem goes away if you use pointer-width indices for arrays, which many other languages do. It also goes away if you use C++ iterators. Sadly, the C-like pattern persists.<p>[1]: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;rygorous&#x2F;e0f055bfb74e3d5f0af20690759de5a7" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;rygorous&#x2F;e0f055bfb74e3d5f0af20690759...</a>
评论 #43537702 未加载
评论 #43537976 未加载
评论 #43538348 未加载
评论 #43537771 未加载
评论 #43538237 未加载
评论 #43538026 未加载
netbioserror大约 1 个月前
There&#x27;s a way I like to phrase this:<p>In C and C++, it&#x27;s easy to write incorrect code, and difficult to write correct code.<p>In Rust, it&#x27;s also difficult to write correct code, but near-impossible to write incorrect code.<p>The new crop of languages that assert the inclusion of useful correctness-assuring features such as iterators, fat-pointer collections, and GC&#x2F;RC (Go, D, Nim, Crystal, etc.) make incorrect code hard, but correct code easy. And with a minimal performance penalty! In the best-case scenarios (for example, Nim with its RC and no manual heap allocations, which is very easy to achieve since it defaults to hidden unique pointers), we&#x27;re talking about only paying a 20% penalty for bounds-checking compared to raw C performance. For the ease of development, maintenance, and readability, that&#x27;s easy to pay.
评论 #43537487 未加载
评论 #43545348 未加载
uecker大约 1 个月前
You can implement C in completely different ways. For example, I like that signed overflow is UB because it is trivial to catch it, while unsigned wraparound - while defined - leads to extremely difficult to find bugs.
评论 #43538002 未加载
评论 #43538186 未加载
评论 #43538056 未加载
评论 #43537908 未加载
gblargg大约 1 个月前
The infinite loops example doesn&#x27;t make sense. If count and count2 are volatile, I don&#x27;t see how the compiler could legally merge the loops. If they aren&#x27;t volatile, it can merge the loops because the program can&#x27;t tell the difference (it doesn&#x27;t even have to update count or count2 in memory during the loops). Only code executing after the loops could even see the values in those variables.
indigoabstract大约 1 个月前
After perusing the article, I&#x27;m thinking that maybe Ferraris should be more like Volvos, because crashing at high speed can be dangerous.<p>But if one doesn&#x27;t find that exciting, at least they&#x27;d better blaze through the critical sections as fast as possible. And double check that O2 is enabled (&#x2F;LTCG too if on Windows).
agentultra大约 1 个月前
If you don&#x27;t write a specification then any program would suffice.<p>We&#x27;re at C23 now and I don&#x27;t think that section has changed? Anyone know why the committee won&#x27;t revisit it?<p>Is it purely, &quot;pragmatism,&quot; or dogma? (Are they even distinguishable in our circles...)
dataflow大约 1 个月前
It&#x27;s not really that they prioritize performance over correctness (your code becomes no more correct if out-of-bounds write was well-defined to reboot the machine...), it&#x27;s that they give unnecessary latitude to UB instead of constraining the valid behaviors to the minimal set that are plausibly useful for maximizing performance. E.g. it is just complete insanity to allow signed integer overflow to format your drive. Simply reducing it to &quot;produces an undefined result&quot; would seem plenty adequate for performance.
评论 #43536958 未加载
jurschreuder大约 1 个月前
Already all fixed in C++.<p>And I don&#x27;t know why now everything has to be beginner friendly. Then just use a high level language. C++ is never advertised as a high level language it&#x27;s a mid-level language.<p>Still with that even C++ has never shut down my computer or bricked my computer even once.<p>All these young people are just too spoiled.
评论 #43543418 未加载
on_the_train大约 1 个月前
Honey it&#x27;s time for your daily anti C++ post
评论 #43537623 未加载
评论 #43537508 未加载
Brian_K_White大约 1 个月前
They let the programmer be the ultimate definer of correctness.<p>They don&#x27;t prioritize performance over correctness, they prioritize programmer control over compiler&#x2F;runtime control.
评论 #43536968 未加载
评论 #43537845 未加载