Need help?
<- Back

Comments (39)

  • judofyr
    Very cool project! Always happy to see more work around static analysis.However, looking at the recent commits it doesn't quite look like the most solid foundation: https://github.com/shuaimu/rusty-cpp/commit/480491121ef9efec... fn is_interior_mutability_type(type_name: &str) -> bool { type_name.starts_with("rusty::Cell<") || type_name.starts_with("Cell<") || type_name.starts_with("rusty::RefCell<") || type_name.starts_with("RefCell<") || // Also check for std::atomic which has interior mutability type_name.starts_with("std::atomic<") || type_name.starts_with("atomic<") } … which then 30 minutes later is being removed again because it turns out to be completely dead code: https://github.com/shuaimu/rusty-cpp/commit/84aae5eff72bb450...There's also quite a lot of dead code. All of these warnings are around unused variable, functions, structs, fields: warning: `rusty-cpp` (bin "rusty-cpp-checker") generated 90 warnings (44 duplicates)
  • minimaxir
    > When I upgraded to Sonnet 4.5, it became less often that it gave phantom answers. But it still sometimes wasn’t able to handle some complex problems. We’d go back and forth and I’d try to give it hints. But with Opus 4.5, that happens much less often now.The real annoying thing about Opus 4.5 is that it's impossible to tell most people "Opus 4.5 is an order of magnitude better than coding LLMs released just months before it" without sounding like a AI hype booster clickbaiting, but it's the counterintuitive truth. To my continual personal frustration.
  • MeetingsBrowser
    > One thing I used to hope for is better interop between C++ and Rust … But after closely following discussions in the Rust committee, I do not think this is likely to happen soon.Interesting. I thought C++ interop was one of the top priorities right now.It’s one of the top items mentioned in recent language progress reports, the Rust foundation received a million dollar grant to work on it, and there was a talk at the most recent RustConf about how Google is doing Rust/C++ interop.Curious to know what discussions led to that conclusion.
  • SkiFire13
    > Then I thought: how hard is it to write this C++ static analyzer? Conceptually, I think it’s not hard. It requires going through the AST. And since the static analysis is mostly statically scoped, it doesn’t require heavy cross-file analysis.How do you handle function lifetimes then? Those are generally non-local to infer, and Rust requires annotating functions with informations for that. I tried taking a look at the mako db's refactor but I didn't see any lifetime annotation being added there.
  • mgaunard
    Wrapping every pointer in a smart pointer is very bad style; that suggests you simply have the bad level of abstraction in your code.That problem seems even more prevalent in Rust, where I see Arc used everywhere, presumably as a cop-out not to have to figure out how to satisfy the borrow checker in smarter ways.
  • anon
    undefined
  • feverzsj
    That must be some bait post, as we all know, C++ and Rust developers hate AI.
  • mgaunard
    unique_ptr/shared_ptr (and box/arc) still need to handle null states due to how moving works in C++.
  • wtetzner
    > C++ has a perfect match for Rust’s mutability: const and non-const.Rust has inherited mutability, while I believe const in C++ is shallow. I don't think it's a perfect match.
  • dash2
    How readable is the code produced by opus, when you try to interact with it manually?
  • jjmarr
    Can we see an example of this on a moderately sized codebase?
  • hu3
    Is it just me or this seems like a quick-win for many C++ codebases?Simple and elegant solution.
  • ChiNutri20
    The pragmatic design choice of using comment-based annotations (// @safe) is brilliant. It successfully bypasses the 'intrusive syntax' trap that killed many previous safety proposals. This tool doesn't just promise safety; it provides a realistic path for legacy C++ codebases to adopt Rust-style borrow checking without a full rewrite. It’s a great example of using modern LLMs to solve deep engineering bottlenecks that previously required a team of compiler experts.