On 6/20/2014 4:44 AM, Botond Ballo wrote:
Why object to this proposal, then? Even if it will, in practice, take a very long time for some projects to adopt extern "abi" and std::abi, this seems better than the status quo.
Is the status quo really that bad? MSVC can publish its ABI as is, and with the Itanium ABI published as well, that's effectively equivalent to saying that the platform ABIs are published. It doesn't necessarily solve gcc/msvc compatibility issues, but that's for Mingw to work out. If gcc is fixing its std::string without std::abi, then it's not clear that std::abi is useful to make ABI guarantees in practice to the degree that it's possible. Libc++ appears to do a decent job of making two distinct standard C++ libraries operate at an ABI level anyways.
Part of my contention is that backwards compatibility isn't as valuable as it appears to be, particular when you're stuck with it for decades. It's not clear to me that today is bad enough to warrant making something that we'll be stuck with for decades and doesn't really solve the problem.
-- Joshua Cranmer Thunderbird and DXR developer Source code archæologist _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
