Is making libc++ and its associated runtime support libraries a
drop-in replacement for libstdc++ one of the goals of the project? Or
will libc++ be more closely tied to clang in general?
I guess the general question is that if there was a C++ front-end that
was currently using libstdc++ for its library/runtime system, could it
easily switch over to libc++ in the future?
Thanks for the information!
The first is that we're definitely not trying to tie libc++ specifically to clang;
if libc++ can be made to work with some other frontend without invasive
changes, we're totally open to that. Howard's been very careful to hide
any uses of clang- or gcc-specific language extensions (e.g. visibility
attributes) behind macros, so porting libc++ to a different C++ compiler
shouldn't be too challenging.
The second is that libc++ is intended to be a fully source-compatible
replacement for a C++98 or C++11 standard library. It does not
necessarily include every extension that libstdc++ does. In general,
it is also not binary-compatible with libstdc++ above the ABI level:
things like type info and certain exception classes should interoperate,
but you can't pass a std::string from a file using libc++ to a file using
libstdc++, because the class layouts are totally different. That said,
trying to do so will result in link errors, not mysterious runtime errors.