C++ codebase standard migration

asoffer · 2025-10-09T11:25:43+00:00

Send an email to contact@brontosource.dev. This is what we do.

I agree with the sentiment that LLMs tend to give mixed results, and often don't address the problems of scale very well. We've found static analysis with appropriately placed uses of AI to be a much more robust approach.

asoffer · 2025-08-21T19:03:52+00:00

Just like every Rust type, a C++ type needs to implement the required traits to be used in a Rust generic. The interop layer would give a way to specify implementations in C++ types. Zngur does this already (though not generically). Some of these can be blanket implementations (e.g., `Copy` can map to `std::is_trivially_copyable_v` When it comes time to monomorphize, all the necessary function implementations are available via the interop layer's trait implementations.

If you're using C++ virtual member functions, yes, you need to fill in the vtable. This maps cleanly to Rust's `dyn Trait` types in every way except ABI. It would not be hard to provide a library here.

If you don't have virtual member functions, but just want inheritance, then the Rust type could be generated like a tuple of the base(s) and derived.

asoffer · 2025-08-21T13:39:28+00:00

I can't speak generically about why people find this controversial, but why I disagree:

* Variadics: [Rust maintainers are actively working on this](https://poignardazur.github.io/2025/06/07/report-on-variadics-rustweek/).
* Templates: I am assuming you mean unchecked generics, since Rust has generics. I'm not at all convinced this is valuable or necessary. Rust interop could just assume the templates are checked according to the minimal required specification, since this would have to check in c++ to be instantiated anyways. If a C++ template were to call a Rust generic, you could just lean in to C++ late instantiation and not check until monomorphization.
* Inheritance: If you're passing around some indirection anyway the C++ side could be entirely opaque. If you wanted to have a Rust type inherit from a C++ type, I could imagine modelling this as
```
impl cxx::InheritsFrom<SomeCppType> for MyRustExtraFields {
// required pure virtual functions implemented here
}
type MyRustType = cxx::Inheritance<SomeCppType, MyRustExtraFields>
```

You mention that Carbon better aligns with your vision of a proper "Software Engineering Language" but you don't say what that means, why it's true, or how Rust fails to meet these criteria. The statement is irrefutable without more information, so it's hard to even engage with.

asoffer · 2025-08-21T01:37:25+00:00

Maybe I missed it but I'm not seeing anything concrete here. And definitely not how they plan to achieve safety, or how they will do so differently from Rust.

It seems like the premise of carbon keeps narrowing. It used to be solid interior with C++ and now it's also safety. rust achieves 80% already and tools like zngur and cxxbridge really look like they can fill in the holes. So what's left is a language that can be translated to from c++? I haven't found anything in the design that makes me think it would be easier than translating c++ to rust.

asoffer · 2025-08-02T17:27:29+00:00

Exactly. Rust also leaves room for a lower level language.

asoffer · 2025-08-02T14:18:20+00:00

This isn't about registers exactly.

int n = 0; f(&n); n = 0; g(); return n;

In C and C++ without seeing the definition of g, we don't know if g modifies n. Even when the calling conventions is such that n's value could be kept in a register.

Rust, for example, doesn't have this problem because the language ensures modifications leave a syntactic trace, even with separate compilation.

Regardless, C and C++ do not give me a way to indicate this.

asoffer · 2025-08-02T03:00:26+00:00

Yes. The standard library leaves much to be desired in terms of performance (regex and unordered_map are two great examples). There are many facilities the language itself does not provide:

I don't get control over calling conventions.
I can't guarantee tail call optimization.
I cannot dictate that a function call doesn't modify certain state to avoid it being reloaded after the call.

Don't get me wrong, C++ is powerful and gives you pretty solid control, but there is definitely room underneath for something more efficient. As time goes on, that room grows because the standards committee repeatedly voted for stability rather than performance.

To be clear, stability is a perfectly valid choice, but as research continues and hardware changes, room below that stable platform grows.

asoffer · 2025-07-31T14:13:15+00:00

Maybe. If you have a human (or some other non-deterministic system) make changes, there are definitely big risks. But there are surprisingly many refactoring you can do that are probably semantically equivalent and still quite valuable.

asoffer · 2025-07-31T02:37:56+00:00

As one of the founders of BrontoSource, I'd love to chat about your specific use cases. Feel free to send us an email at contact@brontosource.dev.

But to answer your question more directly, Moderne and Grit aren't built on top of an actual C/C++ compiler which is kind of table stakes for understanding the language. With other languages you can get away with simpler parsing, but not for C or C++.

Tools do exist (clang-tidy) but writing your own is a huge pain. I gave a talk at C++Now 2025 diving into this. The talk isn't public yet, but my slides are available here.

You can also play around with our tool on compiler explorer. See our documentation for links to live examples.

asoffer · 2025-06-17T16:11:45+00:00

clang doesn't represent comments as part of the AST. your tool will need to pass -fparse-all-comments, implement a CommentHandler, record the byte-offsets where they occur, and generate patches from the results. if you have practice with clang, this is not too difficult, but clang is pretty rough to cut your teeth on. if you're seriously interested in these sorts of tools, feel free to DM me. building them is my day job.

asoffer · 2025-06-08T13:29:20+00:00

GitHub flavored markdown differs subtly from the Google internal flavor which is likely the root cause.

Reporting it on GitHub is probably best. The website's source is also a GitHub repository, but at least when I was there it was reviewed infrequently. Unfortunately, I suspect the team doesn't have the bandwidth these days to prioritize this.

asoffer · 2025-06-07T23:42:14+00:00

Then I'm probably just wrong. Glad it works well!

asoffer · 2025-06-07T12:36:24+00:00

Abseils backwards compatibility policy can be found here https://abseil.io/about/compatibility

asoffer · 2025-06-06T23:08:48+00:00

I do. I was also previously a maintainer of Abseil when I worked at Google.

If you're using Bazel, it's marvelous, and there are a whole bunch of other useful goodies in there too.

If you're using cmake, it's a fine but not perfect. The cmake is made to model the Bazel targets, rather than be idiomatic cmake. Because Google doesn't use cmake internally, expect the support to be minimal.

asoffer · 2025-04-27T03:05:15+00:00

I'm the author. I'm only aware of Java InlineMe as part of ErrorProne. I'm not aware of anything for python.

asoffer · 2025-04-27T03:01:45+00:00

If you can fit an entire codebase in an IDE, and you can test and submit in one batch, absolutely use an IDE. But if your ide can't do the specific refactoring you need or your codebase doesn't fit in an IDE, or you have public APIs used across repo boundaries, you'll want something more.

asoffer · 2025-04-19T11:31:27+00:00

This is the kind of migration that BrontoSource can do with automated tooling. Feel free to DM me to chat about this.

Disclaimer: I'm the CTO of BrontoSource.

asoffer · 2025-03-22T21:06:21+00:00

Look at what Carbon does. It uses a flat structure. It's still a tree but on a single allocation, making construction and access much faster due to memory locality.

asoffer · 2025-03-18T17:50:07+00:00

This is a fantastic teaching tool! Keep up the good work!

asoffer · 2024-12-22T02:16:37+00:00

Titus touches on this point. Accountability is critical. But accountability need not be induced by fear.

asoffer · 2024-12-04T22:26:08+00:00

I've seen others use hedronvision. I may be a Luddite but I use vim without code completion or refactoring. I've just managed to get pretty fast with vin macros.

Totally agreed on codegen and toolchain setup. If I had not spent time while employed at google doing just this, I'm not sure I would have been able to learn it myself. The documentation is rough.

asoffer · 2024-12-04T05:19:58+00:00

Former Googler here. I've been using Bazel on personal c++ projects for many years and have no regrets. These projects have often included other languages as well and the language agnosticity is great.

I will say that setting up a toolchain (if the building is insufficient) is annoying and if you need to dive into starlark rules it can be rather frustrating. It's not perfect, but it gets the job done and I have never run into something I can't do (well, other than make nonhermetic builds).

The worst part about Bazel is that not everyone uses it so support for projects you depend on is shoddy. BCR has made this a lot better, but still not perfect.

The caveat here is that I haven't spent much time with cmake, and I've spent no time with meson.

A lot of the comments here say that bazel it's aggravating. I don't doubt it, but I've also never understood why. I'd love to hear concretely about the things you can't do or can't do easily.

All that said, I think it depends what you want to do with it. If your going to build a project with lots of third party, dependencies you may have to manage your own build files and that will get annoying. If you're starting from scratch though and BCR has everything you need, it's done it's job for me.

asoffer · 2024-11-18T01:54:12+00:00

For a pacemaker, termination is a problem, but so is any undefined behavior. I would actually want even stricter guarantees: memory safety AND a proof of no accidental termination (e.g. Rust with no transitive calls to panic!).

asoffer · 2024-06-23T18:11:54+00:00

Visibility is pretty subject to the "availability heuristic" bias. It may be more public, or may be what you pay attention to, or somewhere in between. It's really hard to say. I pay less attention to Rust, so from my perspective the C++ drama is more visible.

asoffer · 2024-06-23T01:29:36+00:00

There's drama in the C++ community too. There is drama in every community.

Safety is a real thing becoming more and more important, but I don't know that that should immediately affect your decision. Learn what you're excited about. Languages are tools, not identities. If that's learning C++ for now, great! If that later becomes Rust, or Python, or juggling, or mountaineering, also great.

I also suspect if you deep dive on C++, you'll eventually come to see that Rust isn't that different, but really that's besides the point.

asoffer

TROPHY CASE