<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
          "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
  <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
  <title>Clang - C++ Compatibility</title>
  <link type="text/css" rel="stylesheet" href="menu.css" />
  <link type="text/css" rel="stylesheet" href="content.css" />
  <style type="text/css">
</style>
</head>
<body>

<!--#include virtual="menu.html.incl"-->

<div id="content">

<!-- ======================================================================= -->
<h1>Clang's C++ Compatibility</h1>
<!-- ======================================================================= -->

<ul>
<li><a href="#intro">Introduction</a></li>
<li><a href="#vla">Variable-length arrays</a></li>
<li><a href="#init_static_const">Initialization of non-integral static const data members within a class definition</a></li>
<li><a href="#dep_lookup">Unqualified lookup in templates</a></li>
<li><a href="#dep_lookup_bases">Unqualified lookup into dependent bases of class templates</a></li>
<li><a href="#undep_incomplete">Incomplete types in templates</a></li>
<li><a href="#bad_templates">Templates with no valid instantiations</a></li>
<li><a href="#default_init_const">Default initialization of const variable of a class type requires user-defined default constructor</a></li>
</ul>

<!-- ======================================================================= -->
<h2 id="intro">Introduction</h2>
<!-- ======================================================================= -->

<p>Clang strives to strictly conform to the C++ standard.  That means
it will reject invalid C++ code that another compiler may accept.
This page helps you decide whether a Clang error message means a
C++-conformance bug in your code and how you can fix it.</p>

<!-- ======================================================================= -->
<h2 id="vla">Variable-length arrays</h2>
<!-- ======================================================================= -->

<p>GCC and C99 allow an array's size to be determined at run
time. This extension is not permitted in standard C++. However, Clang
supports such variable length arrays in very limited circumstances for
compatibility with GNU C and C99 programs:</p>

<ul>  
  <li>The element type of a variable length array must be a POD
  ("plain old data") type, which means that it cannot have any
  user-declared constructors or destructors, base classes, or any
  members if non-POD type. All C types are POD types.</li>

  <li>Variable length arrays cannot be used as the type of a non-type
template parameter.</li> </ul>

<p>If your code uses variable length arrays in a manner that Clang doesn't support, there are several ways to fix your code:

<ol>
<li>replace the variable length array with a fixed-size array if you can
    determine a
    reasonable upper bound at compile time; sometimes this is as
    simple as changing <tt>int size = ...;</tt> to <tt>const int size
    = ...;</tt> (if the definition of <tt>size</tt> is a compile-time
    integral constant);</li>
<li>use an <tt>std::string</tt> instead of a <tt>char []</tt>;</li>
<li>use <tt>std::vector</tt> or some other suitable container type;
    or</li>
<li>allocate the array on the heap instead using <tt>new Type[]</tt> -
    just remember to <tt>delete[]</tt> it.</li>
</ol>

<!-- ======================================================================= -->
<h2 id="init_static_const">Initialization of non-integral static const data members within a class definition</h2>
<!-- ======================================================================= -->

The following code is ill-formed in C++'03:

<pre>
class SomeClass {
 public:
  static const double SomeConstant = 0.5;
};

const double SomeClass::SomeConstant;
</pre>

Clang errors with something similar to:

<pre>
.../your_file.h:42:42: error: 'SomeConstant' can only be initialized if it is a static const integral data member
  static const double SomeConstant = 0.5;
                      ^              ~~~
</pre>

Only <i>integral</i> constant expressions are allowed as initializers
within the class definition. See C++'03 [class.static.data] p4 for the
details of this restriction.  The fix here is straightforward: move
the initializer to the definition of the static data member, which
must exist outside of the class definition:

<pre>
class SomeClass {
 public:
  static const double SomeConstant;
};

const double SomeClass::SomeConstant<b> = 0.5</b>;
</pre>

Note that the forthcoming C++0x standard will allow this.

<!-- ======================================================================= -->
<h2 id="dep_lookup">Unqualified lookup in templates</h2>
<!-- ======================================================================= -->

Some versions of GCC accept the following invalid code:

<pre>
template &lt;typename T&gt; struct Foo {
  void Work(T x) {
    func(x);
  }
};
...
void func(int x);
...
template struct Foo&lt;int&gt;; // or anything else that instantiates Foo&lt;int&gt;::Work
</pre>

The standard says that unqualified names like <tt>func</tt> are looked up
when the template is defined, not when it's instantiated.  Since
<tt>void func(int)</tt> was not declared yet when <tt>Foo</tt> was
defined, it's not considered.  The fix is usually to
declare <tt>func</tt> before <tt>Foo</tt>.

<p>This is complicated by <i>argument-dependent lookup</i> (ADL),
which is done when unqualified names are called as functions,
like <tt>func(x)</tt> above.  The standard says that ADL is performed
in both places if any of the arguments are type-dependent, like
<tt>x</tt> is in this example.  However, ADL does nothing for builtin
types like <tt>int</tt>, so the example is still invalid.  See
[basic.lookup.argdep] for more information.

<!-- ======================================================================= -->
<h2 id="dep_lookup_bases">Unqualified lookup into dependent bases of class templates</h2>
<!-- ======================================================================= -->

Some versions of GCC accept the following invalid code:

<pre>
template &lt;typename T&gt; struct Base {
  void DoThis(T x) {}
  static void DoThat(T x) {}
};

template &lt;typename T&gt; struct Derived : public Base&lt;T&gt; {
  void Work(T x) {
    DoThis(x);  // Invalid!
    DoThat(x);  // Invalid!
  }
};
</pre>

Clang correctly rejects it with the following errors
(when <tt>Derived</tt> is eventually instantiated):

<pre>
my_file.cpp:8:5: error: use of undeclared identifier 'DoThis'
    DoThis(x);
    ^
    this-&gt;
my_file.cpp:2:8: note: must qualify identifier to find this declaration in dependent base class
  void DoThis(T x) {}
       ^
my_file.cpp:9:5: error: use of undeclared identifier 'DoThat'
    DoThat(x);
    ^
    this-&gt;
my_file.cpp:3:15: note: must qualify identifier to find this declaration in dependent base class
  static void DoThat(T x) {}
</pre>

Like we said <a href="#dep_lookup">above</a>, unqualified names like
<tt>DoThis</tt> and <tt>DoThat</tt> are looked up when the template
<tt>Derived</tt> is defined, not when it's instantiated.  When we look
up a name used in a class, we usually look into the base classes.
However, we can't look into the base class <tt>Base&lt;T&gt;</tt>
because its type depends on the template argument <tt>T</tt>, so the
standard says we should just ignore it.  See [temp.dep]p3 for details.

<p>The fix, as Clang tells you, is to tell the compiler that we want a
class member by prefixing the calls with <tt>this-&gt;</tt>:

<pre>
  void Work(T x) {
    <b>this-&gt;</b>DoThis(x);
    <b>this-&gt;</b>DoThat(x);
  }
</pre>

Alternatively, you can tell the compiler exactly where to look:

<pre>
  void Work(T x) {
    <b>Base&lt;T&gt;</b>::DoThis(x);
    <b>Base&lt;T&gt;</b>::DoThat(x);
  }
</pre>

This works whether the methods are static or not, but be careful:
if <tt>DoThis</tt> is virtual, calling it this way will bypass virtual
dispatch!

<!-- ======================================================================= -->
<h2 id="undep_incomplete">Incomplete types in templates</h2>
<!-- ======================================================================= -->

The following code is invalid, but compilers are allowed to accept it:

<pre>
  class IOOptions;
  template &lt;class T&gt; bool read(T &amp;value) {
    IOOptions opts;
    return read(opts, value);
  }

  class IOOptions { bool ForceReads; };
  bool read(const IOOptions &amp;opts, int &amp;x);
  template bool read&lt;&gt;(int &amp;);
</pre>

The standard says that types which don't depend on template parameters
must be complete when a template is defined if they affect the
program's behavior.  However, the standard also says that compilers
are free to not enforce this rule.  Most compilers enforce it to some
extent; for example, it would be an error in GCC to
write <tt>opts.ForceReads</tt> in the code above.  In Clang, we feel
that enforcing the rule consistently lets us provide a better
experience, but unfortunately it also means we reject some code that
other compilers accept.

<p>We've explained the rule here in very imprecise terms; see
[temp.res]p8 for details.

<!-- ======================================================================= -->
<h2 id="bad_templates">Templates with no valid instantiations</h2>
<!-- ======================================================================= -->

The following code contains a typo: the programmer
meant <tt>init()</tt> but wrote <tt>innit()</tt> instead.

<pre>
  template &lt;class T&gt; class Processor {
    ...
    void init();
    ...
  };
  ...
  template &lt;class T&gt; void process() {
    Processor&lt;T&gt; processor;
    processor.innit();       // <-- should be 'init()'
    ...
  }
</pre>

Unfortunately, we can't flag this mistake as soon as we see it: inside
a template, we're not allowed to make assumptions about "dependent
types" like <tt>Processor&lt;T&gt;</tt>.  Suppose that later on in
this file the programmer adds an explicit specialization
of <tt>Processor</tt>, like so:

<pre>
  template &lt;&gt; class Processor&lt;char*&gt; {
    void innit();
  };
</pre>

Now the program will work &mdash; as long as the programmer only ever
instantiates <tt>process()</tt> with <tt>T = char*</tt>!  This is why
it's hard, and sometimes impossible, to diagnose mistakes in a
template definition before it's instantiated.

<p>The standard says that a template with no valid instantiations is
ill-formed.  Clang tries to do as much checking as possible at
definition-time instead of instantiation-time: not only does this
produce clearer diagnostics, but it also substantially improves
compile times when using pre-compiled headers.  The downside to this
philosophy is that Clang sometimes fails to process files because they
contain broken templates that are no longer used.  The solution is
simple: since the code is unused, just remove it.

<!-- ======================================================================= -->
<h2 id="default_init_const">Default initialization of const variable of a class type requires user-defined default constructor</h2>
<!-- ======================================================================= -->

If a <tt>class</tt> or <tt>struct</tt> has no user-defined default
constructor, C++ doesn't allow you to default construct a <tt>const</tt>
instance of it like this ([dcl.init], p9):

<pre>
class Foo {
 public:
  // The compiler-supplied default constructor works fine, so we
  // don't bother with defining one.
  ...
};

void Bar() {
  const Foo foo;  // Error!
  ...
}
</pre>

To fix this, you can define a default constructor for the class:

<pre>
class Foo {
 public:
  Foo() {}
  ...
};

void Bar() {
  const Foo foo;  // Now the compiler is happy.
  ...
}
</pre>

</div>
</body>
</html>