[cfe-dev] Adopting libc++, hitting problems on Mac OS X
David Chisnall
David.Chisnall at cl.cam.ac.uk
Fri Sep 28 04:06:27 PDT 2012
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
More information about the cfe-dev
mailing list