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