bcraig added a comment. libstdc++ and the Visual Studio C++ runtime have very different compatibility expectations.
libstdc++ is generally bundled with the operating system. It maintains binary compatibility over very long stretches of time. In most systems, there can only be one libstdc++ loaded in a process at a time. Throwing a std::exception in one shared library and catching it in another generally works, even if the two libraries were built with different compilers. So pretty similar to libc++ on Mac. This is almost certainly not news to you. The Visual Studio C++ runtime is not bundled with the operating system. It generally does not maintain binary compatibility over more than a major release. Having multiple versions of the Visual Studio C++ runtime loaded in the same process is pretty common. Throwing a std::exception in one DLL and catching it in another will generally won't work if the two libraries were built with different compilers. When you code against libstdc++ internals, your code will likely last 5+ years before it breaks, and when it breaks it would likely be considered a bug. When you code against Visual Studio C++ internals, your code has a shelf life of 1-3 years, and then the code has a high probability of breaking. I think the seh internals are more stable than the ExceptionPtr helper functions. One thing that works reasonably well is throwing an exception that doesn't derive from a CRT type in one DLL, and then catching it in another, even with different compiler versions. "catch(...)" also works reasonably well across DLL / compiler version boundaries. Is there a particular reason to go with a shorter term solution now, rather than straight to the long term solution? Is there a deadline or a particular milestone we are trying to hit for clang-cl support? Or is there a suspicion that future changes will make a really good implementation possible, incentivizing us to do something inexpensive for now? https://reviews.llvm.org/D32927 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
