improve the 'current status' section to say what *is* there in
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
diff --git a/www/index.html b/www/index.html
index 09f8870..bcef628 100644
--- a/www/index.html
+++ b/www/index.html
@@ -57,6 +57,48 @@
</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><future></code></li>
- <li>Missing <code><regex></code></li>
- <li>Under construction <code><random></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><future></code> and <code><regex></code>, and parts of
+ <code><random></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