mesos git commit: Add constexpr to C++ whitelist

[be...@apache.org]

Repository: mesos
Updated Branches:
  refs/heads/master 17d61af6f -> b8007aaa9


Add constexpr to C++ whitelist

Review: https://reviews.apache.org/r/34835


Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/b8007aaa
Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/b8007aaa
Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/b8007aaa

Branch: refs/heads/master
Commit: b8007aaa9329479e993ded4b7b1ceab7c6c27966
Parents: 17d61af
Author: Paul Brett <pa...@twopensource.com>
Authored: Mon Jun 29 11:49:04 2015 +0200
Committer: Bernd Mathiske <be...@mesosphere.io>
Committed: Mon Jun 29 11:50:47 2015 +0200

----------------------------------------------------------------------
 docs/mesos-c++-style-guide.md | 42 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/mesos/blob/b8007aaa/docs/mesos-c++-style-guide.md
----------------------------------------------------------------------
diff --git a/docs/mesos-c++-style-guide.md b/docs/mesos-c++-style-guide.md
index a8bec8e..a806d86 100644
--- a/docs/mesos-c++-style-guide.md
+++ b/docs/mesos-c++-style-guide.md
@@ -525,3 +525,45 @@ auto lambda = [
 * Unrestricted Union.
 
   Like the pre-existing `union`, we can overlap storage allocation for objects that never exist simultaneously. However, with C++11 we are no longer *restricted to having only non-POD types in unions*. Adding non-POD types to unions complicates things, however, because we need to make sure to properly call constructors and destructors. Therefore, only use unrestricted unions (i.e., unions with non-POD types) when the union has only a single field. What does this buy us? Now we can avoid dynamic memory allocations for "container" like types, e.g., `Option`, `Try`, `Result`, etc. In effect, we treat the union like a dynamic allocation, calling *placement new*, `new (&t) T(...)` anyplace we would have just called `new T(...)` and the destructor `t.~T()` anyplace we would have called `delete t`.
+
+* Constant expressions.
+
+  Constant expressions allow the declaration of static non-POD objects while eliminating the unpredictable runtime initialization and destruction issues normally encountered, helping eliminate macros and hard-coded literals without sacrificing performance and type safety.  Changes which require converting from `constexpr` to `const` can propagate through the dependency tree requiring that dependent `constexpr` uses also be converted to `const`, hence we avoid using `constexpr` in complex functions.
+
+  `constexpr` behaves as a combination of `inline` and `const` and hence must be defined before use in another `constexpr`.
+
+  Prefer `constexpr to `const` for all constant POD declarations, `constexpr` `char` arrays are preferred to `const` `string` literals.
+  ```
+  // OK
+  constexpr char LITERAL[] = "value";
+
+  // Not OK - not available at compile time for optimization and
+  // definition required in a separate compilation module.
+  const char LITERAL[];
+
+  // Not OK - uncertain initialization order, cannot be used in other
+  // constexpr statements.
+  const string LITERAL("value");
+
+  ```
+  `constexpr` functions are evaluated at compile time if all their arguments are constant expressions. Otherwise they default to initialization at runtime. However `constexpr` functions are limited in that they cannot perform dynamic casts, memory allocation or calls to non-constexpr functions.  Prefer `constexpr` over const inline functions.
+
+  ```
+  constexpr size_t MIN = 200;
+  constexpr size_t MAX = 1000;
+  constexpr size_t SPAN() { return MAX-MIN; }
+  int array[SPAN()];
+  ```
+  Const expression constructors allow object initialization at compile time provided that all the constructor arguments are constexpr and the constuctor body is empty, i.e. all initialization is performed in the initialization list.  Classes which provide constexpr constructors should normally also provide constexpr copy constructors to allow the class to be used in the return value from a constexpr function.
+  ```
+  class C
+  {
+  public:
+    constexpr C(int _i) : i(_i) {};
+    constexpr C(const C& c) : i(c.i) {}
+  private:
+    const int i;
+  };
+
+  ```
+  C++11 does not provide constexpr string or containers in the STL and hence constexpr cannot be used for any class using stout's Error() class.