Document my current understanding of C++11 in Skia.

site/dev/contrib/c++11.md

Index: site/dev/contrib/c++11.md
diff --git a/site/dev/contrib/c++11.md b/site/dev/contrib/c++11.md
new file mode 100644
index 0000000000000000000000000000000000000000..fb04a0d652dc2e9e2874e349fbed5cc56bbc856f
--- /dev/null
+++ b/site/dev/contrib/c++11.md
@@ -0,0 +1,70 @@
+C++11 in Skia
+=============
+
+Skia is exploring the use of C++11.  As a library, we are technically limited
+by what our clients support and what our build bots support.
+
+Skia may also be limited by restrictions we choose put on ourselves.  This
+document is not concerned with C++11 policy in Skia, only its technical
+feasibility.  This is about what we can use, a superset of what we may use.
+
+The gist:
+    - C++11 the language as supported by GCC 4.4 or later is probably usable.
+    - If you break a bot, that feature is not usable.
+    - The C++11 standard library can't generally be used.
+    - Local statics are not thread safe.
+
+
+Clients
+-------
+
+The clients we pay most attention to are Chrome, Android, Mozilla, and a few
+internal Google projects.
+
+Chrome builds with a recent Clang on Mac and Linux and with a recent MSVC on
+Windows.  These toolchains are new enough to not be the weak link to use any
+C++11 language feature.  But Chrome still supports Mac OS X 10.6, which does
+not ship with a C++11 standard library.  So [Chrome has banned the use of the
+C++11 standard library](http://chromium-cpp.appspot.com/).  Some header-only
+features are probably technically fine, but the Mac toolchain will prevent us
+from even trying at compile time as long as we target 10.6 as our minimum API
+level.
+
+Chrome intentionally disables thread-safe initialization of static variables,
+and MSVC doesn't support it at all, so we cannot rely on that.
+
+Android builds with either a recent GCC or a recent Clang.  They're generally
+not a weak link for C++11 language features.  Android's C++ standard library
+has always been a pain, but since we can't use it anyway (see Chrome), don't
+worry about it.
+
+Mozilla's current weak link is a minimum requirement of GCC 4.6.  Most features
+marked in red on Mozilla's C++11 [feature
+matrix](https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code) are
+marked that way because they arrived in GCC 4.7 or GCC 4.8.  Their
+minimum-supported Clang and MSVC toolchains are great.  They also appear to ban
+the C++ standard library.
+
+Internal Google projects tend to support C++11 completely, including the
+full C++11 standard library.
+
+
+Bots
+----
+
+Most of our bots are pretty up-to-date: the Windows bots use MSVC 2013, the Mac
+bots a recent Clang, and the Linux bots GCC 4.8 or a recent Clang.  Our Android
+bots use a recent toolchain from Android (see above), and our Chrome bots use
+Chrome's toolchains (see above).  I'm not exactly sure what our Chrome OS bots
+are using, but they've never been a problem.
+
+A few miscellaneous compile-only bots are actually our current overall weak link:
+    - Our NaCl builds use an old non-PNaCl toolchain, which is based on GCC
+      4.4.  GCC 4.4 has some support for C++11, but it's not nearly complete.
+      There is no upgrade path except PNaCl; even the very latest NaCl toolchain
+      is GCC 4.4, while PNaCl is based on Clang 3.4 (with complete C++11 support).
+    - Our iOS builds are driven from a Mac 10.7 machine using some unknown old Clang.
+      Who knows how old that is or what it supports?  It's probably due for an update.
+
+If we were to eliminate the problems of the NaCl and iOS bots, our ability to
+use C++11 would match Mozilla's list nearly identically.