Clever system !
Clever system !
Posted Dec 4, 2024 11:03 UTC (Wed) by ebee_matteo (subscriber, #165284)In reply to: Clever system ! by Karellen
Parent article: Rust's incremental compiler architecture
* Rust doesn't have a stable ABI.
* in Rust, everything is typically statically linked together; a manifest can specify different features which can cause dependent libraries to be recompiled when feature selection changes. In this sense, a library crate (a crate can also be binary-only, of course) in this sense is not too far away from a static library, but since there is no ABI stability guarantee for Rust, everything needs to be recompiled each time the compiler / toolchain changes.
* A lot of types use generic parameters. These are monomorphized at compile time. A library crate cannot possibly know all the ways a parameterized type is instantiated by its users. Type information needs hence to be encoded in the library e.g. by emitting an intermediate representation for it from the AST, or the source code for crates need to be available at compilation time for all its users.
* it gets worse with stuff such as proc macros :-)
So, a library crate is conceptually a library, but not a static or dynamic library in the C/C++ sense, which I think was the comment from OP asking for.
Incidentally, C++20 modules introduce a lot of the same issues also to that language :-).
Posted Dec 4, 2024 12:28 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Hmm. I'm not seeing the connections to your bullet points. C++20 modules certainly support distributing ABI-stable libraries (and roughly on the same order of magnitude of difficulty as pre-modules) better than Rust does. Care to elaborate?
Posted Dec 4, 2024 12:48 UTC (Wed)
by ebee_matteo (subscriber, #165284)
[Link] (1 responses)
There is an experimental draft of a cross-compiler ABI for this, but to my knowledge this is not part of any C++ standard but just some kind of gentlemen agreement among compiler writers. People are still working on this and nowhere near complete. ABI stability is not even guaranteed across different versions of the same compiler (same as Rust, actually).
C++ does NOT define a stable ABI, it just kinda happened to settle down after decades of use. And for modules, which are a new feature, there is nothing uniform.
Posted Dec 4, 2024 16:30 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
No one has written anything about what this looks like in the Itanium ABI (or any other for that matter). AFAIK, modules still need to ship the module sources (just like headers before). Basically, PIMPL is still relevant and no, modules don't change the decl/impl file split. I don't see any appetite for no-module-interface library deployment from implementations, but maybe I'm just not listening in the right places.
> There is an experimental draft of a cross-compiler ABI for this
Are you talking about Microsoft's IFC format? That still doesn't resolve the "need to ship module source files" problem.
> C++ does NOT define a stable ABI
Nor will the language (in any likelihood). What is stable is the implementations' guarantees about how they generate ABIs when compiling. That has been sufficient so far.
(FD, should have mentioned in the prior comment, but I was rushing out the door: I implemented C++20 module support in CMake, co-chair WG21's SG15 Tooling, and am very involved in "how to build modules" processes as I hear about them.)
Posted Dec 6, 2024 6:23 UTC (Fri)
by donald.buczek (subscriber, #112892)
[Link]
It could be added, though, that Rust can both offer and use the C API and ABI. So it's not that Rust is less capable than C or C++, just that you wouldn't normally restrict Rust libraries for Rust users in that way.
Clever system !
Clever system !
Clever system !
Clever system !