[cfe-dev] Adopting libc++, hitting problems on Mac OS X

[David Chisnall]

On 28 Sep 2012, at 12:01, Dallman, John wrote:

> Now I have to try to write some rules for this for developers who believe C++
> is magic and always works right. For applications where large numbers of dylibs
> are supplied by third parties. This could be fiddly, since my own understanding
> of C++ is not of the very finest.

I wrote some for FreeBSD developers here:

http://wiki.freebsd.org/NewC%2B%2BStack

>> For example, if you define a function that takes a std::string, then you
>> must pass it a std::string from the same STL that it was compiled with
>> (libstdc++ or libc++). Libc++ puts all of its code in a non-standard
>> namespace and then imports it into the std namespace, so you will get a
>> linker error if you try this.
> 
> So "if it links, it will work (in this respect)?"

Yes, unless they do unsafe things with function pointer casts.

> As regards writing a rule, it sounds like this should work:
> 
>  If two separately linked modules (executables or dylibs) have a C++ call
>  interface between them, then they must be compiled for the same C++ run-
>  time; if they aren't, it (usually) won't link. If C++ is used behind the
>  scenes to implement an API that has a C call interface, and C++ objects
>  are *never* passed across the interface, then the process can have a
>  mixture of libc++ and libstdc++.

Please say STL implementation rather than runtime: all C++ code must be using the same C++ runtime (typically libsupc++ or libcxxrt, possibly libc++abi).  It is also safe to pass non-STL objects across C++ library boundaries.

David