[cfe-dev] [libc++] libc++ and support libraries as drop in replacements
rjmccall at apple.com
Thu May 3 12:06:45 PDT 2012
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?
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.
More information about the cfe-dev