[cfe-dev] [libc++] libc++ and support libraries as drop in replacements

[John McCall]

On May 3, 2012, at 6:39 AM, Matthew Markland wrote:
> 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?

Two responses.

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.

John.