title: Is clang's c++11 support reliable?
body: <p>I ran into an interesting issue when trying to mix clang (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn, Target: x86_64-apple-darwin14.0.0), c++11 and CGAL (via MacPorts).</p>
  
  <p>It seems that whether or not I call <code>std::vector&lt;&gt;::reserve</code> will determine whether my program will even compile.</p>
  
  <p>I've trimmed down the problem into a minimal example (as minimal as CGAL examples get):</p>
  
  <pre><code>#include &lt;vector&gt;
  #include &lt;CGAL/Exact_predicates_inexact_constructions_kernel.h&gt;
  #include &lt;CGAL/AABB_tree.h&gt;
  #include &lt;CGAL/AABB_traits.h&gt;
  #include &lt;CGAL/AABB_triangle_primitive.h&gt;
  
  // CGAL::Epeck works fine, suggesting the problem is in CGAL::Epick
  typedef CGAL::Epick Kernel;
  typedef CGAL::Triangle_3&lt;Kernel&gt; Triangle_3; 
  typedef typename std::vector&lt;Triangle_3&gt;::iterator Iterator;
  typedef CGAL::AABB_triangle_primitive&lt;Kernel, Iterator&gt; Primitive;
  typedef CGAL::AABB_traits&lt;Kernel, Primitive&gt; AABB_triangle_traits;
  typedef CGAL::AABB_tree&lt;AABB_triangle_traits&gt; Tree;
  typedef typename Tree::Point_and_primitive_id Point_and_primitive_id;
  typedef CGAL::Point_3&lt;Kernel&gt;    Point_3;
  
  template &lt;typename BKernel&gt;
  void A()
  {
    const CGAL::AABB_tree&lt;
      CGAL::AABB_traits&lt;BKernel, 
        CGAL::AABB_triangle_primitive&lt;BKernel, 
          typename std::vector&lt;CGAL::Triangle_3&lt;BKernel&gt; &gt;::iterator
        &gt;
      &gt;
    &gt; tree;
    Point_and_primitive_id pp = tree.closest_point_and_primitive(Point_3());
  }
  
  void B()
  {
    std::vector&lt;Triangle_3&gt; T;
  #ifdef MAGIC
    T.reserve(0);
  #endif
    return A&lt;Kernel&gt;();
  }
  </code></pre>
  
  <p>Issuing:</p>
  
  <pre><code>clang++ -std=c++11 -c example.cpp -I/opt/local/include
  </code></pre>
  
  <p>This fails to compile. Giving errors like:</p>
  
  <pre><code>    In file included from example.cpp:1:
      In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:265:
      In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__bit_reference:15:
      In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:626:
      In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:157:
      /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tuple:228:60: error: 
            no member named 'value' in 'std::__1::is_convertible&lt;const CGAL::Point_3&lt;CGAL::Epick&gt; &amp;,
            CGAL::Point_3&lt;CGAL::Epick&gt; &gt;'
                                     is_convertible&lt;_Tp0, _Up0&gt;::value &amp;&amp;
                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tuple:242:14: note: 
            in instantiation of template class 'std::__1::__tuple_convertible_imp&lt;true, std::__1::__tuple_types&lt;const
            CGAL::Point_3&lt;CGAL::Epick&gt; &amp;, const CGAL::Vector_3&lt;CGAL::Epick&gt; &amp;&gt;,
            std::__1::__tuple_types&lt;CGAL::Point_3&lt;CGAL::Epick&gt;, CGAL::Vector_3&lt;CGAL::Epick&gt; &gt; &gt;' requested here
          : public __tuple_convertible_imp&lt;tuple_size&lt;typename remove_reference&lt;_Tp&gt;::type&gt;::value ==
  </code></pre>
  
  <p>However, this <strong>does compile</strong> if I make this magic call to <code>std::vector::reserve</code>, issuing:</p>
  
  <pre><code>clang++ -std=c++11 -c example.cpp -I/opt/local/include -DMAGIC
  </code></pre>
  
  <p>or by disabling c++11</p>
  
  <pre><code>clang++ -c example.cpp -I/opt/local/include
  </code></pre>
  
  <ol>
  <li>Is this a bug in CGAL or clang?</li>
  <li>What explanation can there be for such erratic compiler behavior?</li>
  <li>Is there a <em>clean</em> way of avoiding this (hopefully without really changing the templating or function prototype set up as I need the solution to fit my larger project).</li>
  </ol>