[cfe-commits] [libcxx] r103655 - /libcxx/trunk/www/index.html

[Chris Lattner]

Author: lattner
Date: Wed May 12 17:21:15 2010
New Revision: 103655

URL: http://llvm.org/viewvc/llvm-project?rev=103655&view=rev
Log:
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.

Modified:
    libcxx/trunk/www/index.html

Modified: libcxx/trunk/www/index.html
URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/index.html?rev=103655&r1=103654&r2=103655&view=diff
==============================================================================
--- libcxx/trunk/www/index.html (original)
+++ libcxx/trunk/www/index.html Wed May 12 17:21:15 2010
@@ -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