4 ms·

No, I did mean the ABI. See this paper, for example, about the argument: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf http://www.open-st

No, I did mean the ABI. See this paper, for example, about the argument: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186... "there is a non-trivial amount of performance that we cannot recoup because of ABI concerns. We cannot remove runtime overhead involved in passing unique_ptr by value, nor can we change std::hash or class layout for unordered_map , without forcing a recompile everywhere etc. etc."

MaxBarraclough 6y ago
Thanks for the link, interesting skim-read. I thought passing template instantiations over an ABI boundary was generally discouraged and thought to be asking for trouble. I guess this isn't really at odds with what the paper is saying though - it could still be that a lot of people are doing so. edit Thinking about Hyrum's Law, [0] mentioned in the article, makes me think perhaps there was an upside to Java firmly refusing to support any kind of ahead-of-time compilation for so long. It fully closed the door on any funny business distributing Java packages as brittle precompiled native-code blobs, ensuring the bytecode format remained the way that Java packages were distributed, presumably avoiding some fraction of the issues C++ now faces. Of course, Java still has backward-compatibility obligations, but unlike in C++ they align pretty well with API compatibility, if I understand things correctly. [0] https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
- int_19h 6y ago
  There's nothing particular about template instantiations that makes them any different from any other object. The only problem with using them at ABI (or rather, linker) boundary is that instantiations have to be explicit - but that's what "extern template" is for.