From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-05-12 23:51:08
On 10/05/2024 23:01, Ville Voutilainen wrote:
> Are you going to make std::string a COM type with interface
> indirections? tuple? pair?
You are correct that ABI resiliency historically came with a runtime
overhead penalty.
If a linker can devirtualise final classes, it certainly can de-indirect
interface indirections.
The prototype I built at BlackBerry didn't implement the runtime
de-COMification stage, but it did emit all necessary metadata so a
linker stage could do so in linear time. The way I had it was if
compatible toolchains were used both sides of the ABI boundary, you got
linking like now. If they differed, you got varying amounts of runtime
overhead generated, with the worst being two toolchains with different
calling conventions.
As to whether to make all types which touch a nu-COM boundary be
required to be also nu-COMed themselves ... I guess it depends on the
impact on link times.
If Modules can be implemented in a way where link times are bounded,
then nu-COMifying everything is surely doable with bounded times. It is
hard to do better than speculation here, but for sure for Debug builds
we can have fast links and only for optimised builds do we invest more
time on linking. I think it would work.
>> tried to effectively propose a modernised COM for C++ Modules
>> originally, and to say that went down like a lead balloon would be
>> putting it mildly.
>
> I have absolutely no idea what you're talking about there. I cannot
> find a Modules proposal that does
> anything of the sort. Please point to the proposal you think you're
> talking about.
I don't think it ever made it as far as a formal WG21 paper. Gaby
described it to me over dinner one evening, otherwise I wouldn't know
about it either.
The essence of it was https://github.com/GabrielDosReis/ipr, and your
compiled C++ Module would be a shared library binary with an IPR
interface description embedded into it. Your C++ process runtime loader
would no longer use the ELF or PE symbol tables to link up the shared
library binaries into a process, it would parse the IPR for the
precompiled C++ Modules in the link database, assemble them into a
graph, generate any thunk code as needed between them, and thus birth
the process. This is why LLFIO works before main() gets called
incidentally, I originally intended it to be used to bootstrap C++
Modules based C++ programs into existence.
From what he told me, some within C++ tooling did not like there being
a standard binary interface for Modules. As in, over my dead body
showstopper red line no. So that got dropped very early on as it was
politically infeasible to standardise, plus historically speaking WG21
has not told implementations exactly how to implement tooling, so it
would have been a big land grab and a big ask to dictate to all
implementations "all C++ Modules shall be implemented in this EXACT
binary format".
The C++ Modules we eventually got I think you'll agree got very
considerably watered down even after the first WG21 papers appeared, so
it was probably right that it was too big an ask of WG21 to standardise
C++ Modules as a newly modernised COM of toolchain independent binary
objects. No point proposing something impossible.
Niall