[oi-dev] [hhinnant at apple.com: Re: [cfe-dev] libc++ ABIstability]

[Garrett D'Amore]

Just a quick note.  I fully support moving to an open C++ library, but be advised that we will still need the closed Sun binaries in order to support legacy apps.  Of course I think nobody should use C++ but that is a different rant and probably highly controversial.  :)

  -- Garrett D'Amore

On May 24, 2011, at 12:07 PM, "Alasdair Lumsden" <alasdairrr at gmail.com> wrote:

> Hi Guido,
> 
> Thanks for forwarding this, libc++ sounds rather promising.
> 
> Without us testing it there's no way to know for sure what kind of issues we'll see in the field, so I'll mention in the policy document draft that libc++ is a candidate for our default open C++ library subject to testing.
> 
> We'll need to come up with an easy way of firing off builds with a different compiler and C++ library selected. In Userland this should be pretty easy to do, there's a makefile called shared-macros.mk which contains compiler definitions:
> 
> http://hg.genunix.org/userland.hg/file/520697a05dde/make-rules/shared-macros.mk
> 
> I'm not sure we would switch between the different c++ libraries but I imagine it won't be too hard to work out, although if its hardcoded in GCC like the linker collect2 runs then I'll be a little less happy.
> 
> Cheers,
> 
> Alasdair
> 
> On 23 May 2011, at 21:22, Guido Berhoerster wrote:
> 
>> 
>> ----- Forwarded message from Howard Hinnant <hhinnant at apple.com> -----
>> 
>> Date: Mon, 23 May 2011 16:08:23 -0400
>> From: Howard Hinnant <hhinnant at apple.com>
>> To: Guido Berhoerster <gber at openindiana.org>
>> Cc: cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] libc++ ABI stability
>> 
>> On May 23, 2011, at 2:27 PM, Guido Berhoerster wrote:
>> 
>>> Hello,
>>> 
>>> does the LLVM project make (or plan to make) any commitment with
>>> regard to the ABI stability of libc++?
>> 
>> The plan is to keep the ABI semi-stable.  The high level parts of the library are ABI-versioned using the C++11 feature inline namespaces.  The current version is 1.  This is considered an ABI version.  And the ABI for any given version is meant to be fixed.
>> 
>> Every once in a great while (e.g. maybe for the next C++ standard), we could issue a new ABI, which would then live in a different inlined namespace (e.g. std::_2).  There would be config macro to choose the ABI.
>> 
>> Some lower-level parts of the library are not ABI versioned.  They live in namespace std only.  These will remain stable until the sun swells up and swallows the earth (after that I can't vouch for it).  These low level parts include:
>> 
>> * operator new/delete
>> * get/set new_handler
>> * typeinfo
>> * the exception classes
>> 
>> The exception classes not only have a stable ABI, their ABI is identical to that of gcc-4.2.  This means you can throw exceptions across dyld boundaries and not worry which C++ std::lib the recipient of your exception is using (as long as that library is also ABI compatible with gcc-4.2).
>> 
>> Howard
>> 
>> 
>> ----- End forwarded message -----
>> 
>> -- 
>> Guido Berhoerster
>> 
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
> 
> 
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev