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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Safe C++

101 点作者 matt_d9 个月前

13 条评论

testrun9 个月前
Not a fan of where this is going. Just use Rust instead. All this is doing is making c++ even more unmanageable. When developers are pressed for time they will revert to what they are used to and know. What you get in the end is a mess of code with different ideas at different parts of the system because they are developed at different times by different people. Or you are going to put down very strict guidelines and redevelop everything according to these guidelines. Then you are back to rather use Rust instead. The guidelines is built in the Rust language.
评论 #41539262 未加载
评论 #41538185 未加载
评论 #41539347 未加载
评论 #41539375 未加载
omoikane9 个月前
I believe this is Circle C++ with a new domain name. See also:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40553709">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40553709</a> - Circle C++ with memory safety (2024-06-02)<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23086227">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23086227</a> - Circle – A C++ compiler with compile-time imperative metaprogramming (2020-05-05)<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19224176">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19224176</a> - Circle: The C++ Automation Language (2019-02-22)
评论 #41555374 未加载
captainmuon9 个月前
I think this is really interesting work, and as others have said it is a herculean undertaking by Sean Baxter to try to rework C++.<p>That being said, I&#x27;m not sure I like the direction. C++ is already more than complicated enough. And I&#x27;m not a big fan of the &quot;mut XOR shared&quot; principle taken from Rust, because I don&#x27;t really have the problem of accidentially mutating something that was shared. Well, maybe I don&#x27;t get the point because I&#x27;m a &quot;Blub programmer&quot; :-).<p>The example that is presented here and in many introductory articles about Rust is mutating a vector while iterating it. But why can&#x27;t we just have a vector type that tolerates that and does something well-defined? What if we actually want to modify the list while iterating, because we are filtering the list for example?<p>I think one forward for C++ would be to define a safe subset. Deprecate a lot of features when using this subset, and make sure with a linter that they are not used. Hide raw pointers as much as possible. Ban UB as much as possible or give it some safe default. If you need some &quot;UB&quot; for optimisations (that is, you need the compiler to be able to make certain assumptions), then I want the compiler to tell me:<p>&gt; &quot;Could optimize further if we assume `a` and `b` are not aliasing, please add annotations to allow optimisation or to suppress this message&quot;.<p>Finally we need a new boring standard lib, closer to Java and Qt than the gnarlyness of the STL. The spirit should be like that of Java or Go, boring, efficient enough, productive for the average developer, not to many ways to shoot yourself in the foot.
评论 #41538863 未加载
评论 #41534273 未加载
评论 #41535964 未加载
Animats9 个月前
It&#x27;s nice, but it&#x27;s about the tenth attempt to make C&#x2F;C++ safe. I&#x27;ve been down that road myself. To succeed, this needs some major organization, something the size of Microsoft, Google, or the U.S. Government, pushing it hard. Someone has to fund retrofits of important trusted code, such as OpenSSL.<p>When you&#x27;re all done, it will be at least as crufty as C++.
评论 #41534903 未加载
评论 #41538240 未加载
netbsdusers9 个月前
&gt; Exceptions are a poor way to signal out-of-memory states. If containers panicked on out-of-memory, we’d enormously reduce the cleanup paths in most functions.<p>What exactly is the difference between a panic and an exception? According to everything I&#x27;ve been able to read about Rust&#x27;s panic mechanism, it&#x27;s just that &quot;panics shouldn&#x27;t be used for normal errors&quot;, which is just a prescription on the normative use of the construct. A pretended difference. Can anyone clarify whether there actually is a real difference? Or when &quot;Panic&quot; is said here, does the author mean something that cannot be meaningfully recovered from? That would be a change most inappropriate!<p>One of the most prominent birthmarks that Rust was stamped with when it was born as an apps (not systems) language was its standard library being designed without regard to the possibility of reacting to out-of-memory conditions by anything other than aborting. Now that it&#x27;s trying to pivot from solely an apps language to a systems language for some time, there seems to be work underway to correct that deficiency.<p>C++ for its part is not burdened with that mistake. There is remarkable attention paid in the STL to the possibility of an out-of-memory condition and allowing a complete recovery from the same. This is a useful feature that systems software often requires.
评论 #41540154 未加载
评论 #41544735 未加载
yosefk9 个月前
why isn&#x27;t this getting traction? it&#x27;s a pretty big deal. it&#x27;s the most safe of proposed C++ safety extensions by far
评论 #41532983 未加载
评论 #41532055 未加载
评论 #41532451 未加载
评论 #41532780 未加载
评论 #41532236 未加载
评论 #41532439 未加载
评论 #41532158 未加载
ijustlovemath9 个月前
Coming into this thread late, but one thing I wished to see in this discussion is the mention of the truism that I first read here:<p>Successor languages must have full (or at least broad) compatibility with the language they&#x27;re replacing. Look at C++ itself; it started as a C transpiler, and has some of the longest running C compat of any extant language. Same goes for TypeScript, which is fairly widely used in production, I think even moreseo than Rust, for all the hype it generates,<p>This is an interesting proposal for that reason alone; it would allow a slow and deliberate conversion process, but also would allow safety standards to include language like &quot;no unsafe blocks allowed unless proven safe&quot;
fuhsnn9 个月前
Aside from &quot;making C++ safe&quot;, the design looks like a good opportunity to have better Rust interop, if a standardized FFI with clear object lifetime semantics can be established between C++ and Rust, it&#x27;s a win for everyone.
评论 #41532797 未加载
xiphias29 个月前
This looks like a huge improvement from the original Circle language that didn&#x27;t look like C++ at all. I love it and would love to have it in C++.
amluto9 个月前
Even without all the safety parts, this is amazing:<p>&gt; The new choice type is a type safe discriminated union. It’s equivalent to Rust’s enum type.
jedisct19 个月前
&quot;safety&quot; != &quot;memory safety&quot;<p>A formally proven implementation could be called &quot;safe&quot;.<p>But code written with checked arrays and without explicit pointers isn&#x27;t magically safe, and promoting a language or a cookbook as something that makes applications &quot;safe&quot; is just abusive and annoying marketing.
sigmaprimus9 个月前
Considering my city Is still running 16 bit Operating systems Off floppy drives For some of the infrastructure... Well I don&#x27;t know, Maybe that makes it more secure? I have no idea How These systems haven&#x27;t been hit yet. Or maybe they have?
fithisux9 个月前
&quot;Over the past two years,&quot;<p>suddenly they remembered to make it safe!!!<p>Seems others used their backdoors.