EricWF marked an inline comment as done. EricWF added a comment. In https://reviews.llvm.org/D28442#638862, @smeenai wrote:
> Hooray for Microsoft for putting all these in msvcrt (their **C** runtime > library) instead of msvcprt (their C++ runtime library), I guess :p Although Boo to `eh.h` for being in the same directory as the MSVC STL headers. If possible I would like to be able to compile libc++ without adding that directory to the include paths. ================ Comment at: src/exception.cpp:53 +#if defined(_LIBCPP_ABI_MICROSOFT) + return ::set_unexpected(func); +#else ---------------- smeenai wrote: > MSDN says "unexpected is not used in the current C++ exception-handling > implementation", which is maybe not the most desirable thing in the world, > but I guess this is going away in C++17 anyway :D Actually `unexpected()` has gone away in C++17 since C++17 removes "dynamic exception specifications" (ie `void foo() throw(int, ...)`). Therefore I suspect the doc is referring to that. However I suspect are still used when `clang-cl` targets C++14 or newer. ================ Comment at: src/exception.cpp:139 +#elif defined(_LIBCPP_ABI_MICROSOFT) + return __uncaught_exceptions(); +#else ---------------- smeenai wrote: > Yay undocumented APIs (at least as far as I can see). Undocumented API for sure. Unfortunately libc++ is going to have to rely on a number of undocumented API's because Microsoft doesn't provide documentation for porting an STL to Windows. https://reviews.llvm.org/D28442 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
