generic-library/cxx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

improve the 'current status' section to say what *is* there in

Browse Source 
addition to what is not.

Add a big "why libc++" section to address a pretty major FAQ.


git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@103655 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2010-05-12 22:21:15 +00:00
parent a64111c95a
commit 24173b81dd
1 changed files with 46 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
www/index.html
View File

@ -56,6 +56,48 @@
<li>Extensive unit tests.</li>
</ul>
<!--=====================================================================-->
<h2 id="why">Why a new C++ Standard Library for C++'0x?</h2>
<!--=====================================================================-->
<p>After its initial introduction, many people have asked "why start a new
library instead of contributing to an existing library?" (like Apache's
libstdcxx, GNU's libstdc++, STLport, etc). There are many contributing
reasons, but some of the major ones are:</p>
<ul>
<li><p>From years of experience (including having implemented the standard
library before), we've learned many things about implementing
the standard containers which require ABI breakage and fundamental changes
to how they are implemented. For example, it is generally accepted that
building std::string using the "short string optimization" instead of
using Copy On Write (COW) is a superior approach for multicore
machines. Breaking ABI compatibility with old versions of the library was
determined to be critical to achieving the performance goals of
libc++.</p></li>
<li><p>Mainline libstdc++ has switched to GPL3, a license which the developers
of libc++ cannot use. libstdc++ 4.2 (the last GPL2 version) could be
independently extended to support C++'0x, but this would be a fork of the
codebase, which is usually seen as worse for a project than starting a new
one. Another problem with libstdc++ is that it is tightly integrated with
G++ development, tending to be tied fairly closely to the matching
version of G++.</p>
</li>
<li><p>STLport and the Apache libstdcxx library are two other popular
candidates, but both lack C++'0x support. Our experience (and the
experience of libstdc++ developers) is that adding support for C++0x (in
particular rvalue references and move-only types) requires changes to
almost every class and function, essentially amounting to a rewrite.
Faced with a rewrite, we decided to start from scratch and evaluate every
decision based from first principles based on experience.</p>
<p>Further, both projects are apparently abandoned: STLport 5.2.1 was
released in Oct'08, and STDCXX 4.2.1 in May'08.</p>
</ul>
<!--=====================================================================-->
<h2 id="requirements">Platform Support</h2>
<!--=====================================================================-->
@ -74,13 +116,10 @@
<p>libc++ is still under development. It has about 85% of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>
implemented/tested.</p>
<ul>
<li>Missing <code>&lt;future&gt;</code></li>
<li>Missing <code>&lt;regex&gt;</code></li>
<li>Under construction <code>&lt;random&gt;</code></li>
</ul>
implemented/tested. C++'98 support is fully featured, and most of C++'0x
support is as well. The only major missing pieces of C++'0x support are
<code>&lt;future&gt;</code> and <code>&lt;regex&gt;</code>, and parts of
<code>&lt;random&gt;</code>.</p>
<p>libc++ is currently dependent upon a separate library for the low-level
ABI compatibility with gcc. As a workaround it can be linked against