1f4a2713aSLionel Sambuc<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 2f4a2713aSLionel Sambuc "http://www.w3.org/TR/html4/strict.dtd"> 3f4a2713aSLionel Sambuc<html> 4f4a2713aSLionel Sambuc<head> 5f4a2713aSLionel Sambuc <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> 6f4a2713aSLionel Sambuc <title>Language Compatibility</title> 7f4a2713aSLionel Sambuc <link type="text/css" rel="stylesheet" href="menu.css"> 8f4a2713aSLionel Sambuc <link type="text/css" rel="stylesheet" href="content.css"> 9f4a2713aSLionel Sambuc <style type="text/css"> 10f4a2713aSLionel Sambuc</style> 11f4a2713aSLionel Sambuc</head> 12f4a2713aSLionel Sambuc<body> 13f4a2713aSLionel Sambuc 14f4a2713aSLionel Sambuc<!--#include virtual="menu.html.incl"--> 15f4a2713aSLionel Sambuc 16f4a2713aSLionel Sambuc<div id="content"> 17f4a2713aSLionel Sambuc 18f4a2713aSLionel Sambuc<!-- ======================================================================= --> 19f4a2713aSLionel Sambuc<h1>Language Compatibility</h1> 20f4a2713aSLionel Sambuc<!-- ======================================================================= --> 21f4a2713aSLionel Sambuc 22f4a2713aSLionel Sambuc<p>Clang strives to both conform to current language standards (up to C11 23f4a2713aSLionel Sambuc and C++11) and also to implement many widely-used extensions available 24f4a2713aSLionel Sambuc in other compilers, so that most correct code will "just work" when 25f4a2713aSLionel Sambuc compiled with Clang. However, Clang is more strict than other 26f4a2713aSLionel Sambuc popular compilers, and may reject incorrect code that other 27f4a2713aSLionel Sambuc compilers allow. This page documents common compatibility and 28f4a2713aSLionel Sambuc portability issues with Clang to help you understand and fix the 29f4a2713aSLionel Sambuc problem in your code when Clang emits an error message.</p> 30f4a2713aSLionel Sambuc 31f4a2713aSLionel Sambuc<ul> 32f4a2713aSLionel Sambuc <li><a href="#c">C compatibility</a> 33f4a2713aSLionel Sambuc <ul> 34f4a2713aSLionel Sambuc <li><a href="#inline">C99 inline functions</a></li> 35f4a2713aSLionel Sambuc <li><a href="#vector_builtins">"missing" vector __builtin functions</a></li> 36f4a2713aSLionel Sambuc <li><a href="#lvalue-cast">Lvalue casts</a></li> 37f4a2713aSLionel Sambuc <li><a href="#blocks-in-protected-scope">Jumps to within <tt>__block</tt> variable scope</a></li> 38f4a2713aSLionel Sambuc <li><a href="#block-variable-initialization">Non-initialization of <tt>__block</tt> variables</a></li> 39f4a2713aSLionel Sambuc <li><a href="#inline-asm">Inline assembly</a></li> 40f4a2713aSLionel Sambuc </ul> 41f4a2713aSLionel Sambuc </li> 42f4a2713aSLionel Sambuc <li><a href="#objective-c">Objective-C compatibility</a> 43f4a2713aSLionel Sambuc <ul> 44f4a2713aSLionel Sambuc <li><a href="#super-cast">Cast of super</a></li> 45f4a2713aSLionel Sambuc <li><a href="#sizeof-interface">Size of interfaces</a></li> 46f4a2713aSLionel Sambuc <li><a href="#objc_objs-cast">Internal Objective-C types</a></li> 47f4a2713aSLionel Sambuc <li><a href="#c_variables-class">C variables in @class or @protocol</a></li> 48f4a2713aSLionel Sambuc </ul> 49f4a2713aSLionel Sambuc </li> 50f4a2713aSLionel Sambuc <li><a href="#cxx">C++ compatibility</a> 51f4a2713aSLionel Sambuc <ul> 52f4a2713aSLionel Sambuc <li><a href="#vla">Variable-length arrays</a></li> 53f4a2713aSLionel Sambuc <li><a href="#dep_lookup">Unqualified lookup in templates</a></li> 54f4a2713aSLionel Sambuc <li><a href="#dep_lookup_bases">Unqualified lookup into dependent bases of class templates</a></li> 55f4a2713aSLionel Sambuc <li><a href="#undep_incomplete">Incomplete types in templates</a></li> 56f4a2713aSLionel Sambuc <li><a href="#bad_templates">Templates with no valid instantiations</a></li> 57f4a2713aSLionel Sambuc <li><a href="#default_init_const">Default initialization of const 58f4a2713aSLionel Sambuc variable of a class type requires user-defined default 59f4a2713aSLionel Sambuc constructor</a></li> 60f4a2713aSLionel Sambuc <li><a href="#param_name_lookup">Parameter name lookup</a></li> 61f4a2713aSLionel Sambuc </ul> 62f4a2713aSLionel Sambuc </li> 63f4a2713aSLionel Sambuc <li><a href="#cxx11">C++11 compatibility</a> 64f4a2713aSLionel Sambuc <ul> 65f4a2713aSLionel Sambuc <li><a href="#deleted-special-func">Deleted special member 66f4a2713aSLionel Sambuc functions</a></li> 67f4a2713aSLionel Sambuc </ul> 68f4a2713aSLionel Sambuc </li> 69f4a2713aSLionel Sambuc <li><a href="#objective-cxx">Objective-C++ compatibility</a> 70f4a2713aSLionel Sambuc <ul> 71f4a2713aSLionel Sambuc <li><a href="#implicit-downcasts">Implicit downcasts</a></li> 72f4a2713aSLionel Sambuc </ul> 73f4a2713aSLionel Sambuc <ul> 74f4a2713aSLionel Sambuc <li><a href="#class-as-property-name">Using <code>class</code> as a property name</a></li> 75f4a2713aSLionel Sambuc </ul> 76f4a2713aSLionel Sambuc </li> 77f4a2713aSLionel Sambuc</ul> 78f4a2713aSLionel Sambuc 79f4a2713aSLionel Sambuc<!-- ======================================================================= --> 80f4a2713aSLionel Sambuc<h2 id="c">C compatibility</h2> 81f4a2713aSLionel Sambuc<!-- ======================================================================= --> 82f4a2713aSLionel Sambuc 83f4a2713aSLionel Sambuc<!-- ======================================================================= --> 84f4a2713aSLionel Sambuc<h3 id="inline">C99 inline functions</h3> 85f4a2713aSLionel Sambuc<!-- ======================================================================= --> 86*0a6a1f1dSLionel Sambuc<p>By default, Clang builds C code in GNU C11 mode, so it uses standard C99 87*0a6a1f1dSLionel Sambucsemantics for the <code>inline</code> keyword. These semantics are different 88*0a6a1f1dSLionel Sambucfrom those in GNU C89 mode, which is the default mode in versions of GCC 89*0a6a1f1dSLionel Sambucprior to 5.0. For example, consider the following code:</p> 90f4a2713aSLionel Sambuc<pre> 91f4a2713aSLionel Sambucinline int add(int i, int j) { return i + j; } 92f4a2713aSLionel Sambuc 93f4a2713aSLionel Sambucint main() { 94f4a2713aSLionel Sambuc int i = add(4, 5); 95f4a2713aSLionel Sambuc return i; 96f4a2713aSLionel Sambuc} 97f4a2713aSLionel Sambuc</pre> 98f4a2713aSLionel Sambuc 99f4a2713aSLionel Sambuc<p>In C99, <code>inline</code> means that a function's definition is 100f4a2713aSLionel Sambucprovided only for inlining, and that there is another definition 101f4a2713aSLionel Sambuc(without <code>inline</code>) somewhere else in the program. That 102f4a2713aSLionel Sambucmeans that this program is incomplete, because if <code>add</code> 103f4a2713aSLionel Sambucisn't inlined (for example, when compiling without optimization), then 104f4a2713aSLionel Sambuc<code>main</code> will have an unresolved reference to that other 105f4a2713aSLionel Sambucdefinition. Therefore we'll get a (correct) link-time error like this:</p> 106f4a2713aSLionel Sambuc 107f4a2713aSLionel Sambuc<pre> 108f4a2713aSLionel SambucUndefined symbols: 109f4a2713aSLionel Sambuc "_add", referenced from: 110f4a2713aSLionel Sambuc _main in cc-y1jXIr.o 111f4a2713aSLionel Sambuc</pre> 112f4a2713aSLionel Sambuc 113*0a6a1f1dSLionel Sambuc<p>By contrast, GNU C89 mode (used by default in older versions of GCC) is the 114*0a6a1f1dSLionel SambucC89 standard plus a lot of extensions. C89 doesn't have an <code>inline</code> 115*0a6a1f1dSLionel Sambuckeyword, but GCC recognizes it as an extension and just treats it as a hint to 116*0a6a1f1dSLionel Sambucthe optimizer.</p> 117f4a2713aSLionel Sambuc 118f4a2713aSLionel Sambuc<p>There are several ways to fix this problem:</p> 119f4a2713aSLionel Sambuc 120f4a2713aSLionel Sambuc<ul> 121f4a2713aSLionel Sambuc <li>Change <code>add</code> to a <code>static inline</code> 122f4a2713aSLionel Sambuc function. This is usually the right solution if only one 123f4a2713aSLionel Sambuc translation unit needs to use the function. <code>static 124f4a2713aSLionel Sambuc inline</code> functions are always resolved within the translation 125f4a2713aSLionel Sambuc unit, so you won't have to add a non-<code>inline</code> definition 126f4a2713aSLionel Sambuc of the function elsewhere in your program.</li> 127f4a2713aSLionel Sambuc 128f4a2713aSLionel Sambuc <li>Remove the <code>inline</code> keyword from this definition of 129f4a2713aSLionel Sambuc <code>add</code>. The <code>inline</code> keyword is not required 130f4a2713aSLionel Sambuc for a function to be inlined, nor does it guarantee that it will be. 131f4a2713aSLionel Sambuc Some compilers ignore it completely. Clang treats it as a mild 132f4a2713aSLionel Sambuc suggestion from the programmer.</li> 133f4a2713aSLionel Sambuc 134f4a2713aSLionel Sambuc <li>Provide an external (non-<code>inline</code>) definition 135f4a2713aSLionel Sambuc of <code>add</code> somewhere else in your program. The two 136f4a2713aSLionel Sambuc definitions must be equivalent!</li> 137f4a2713aSLionel Sambuc 138*0a6a1f1dSLionel Sambuc <li>Compile in the GNU C89 dialect by adding 139f4a2713aSLionel Sambuc <code>-std=gnu89</code> to the set of Clang options. This option is 140f4a2713aSLionel Sambuc only recommended if the program source cannot be changed or if the 141f4a2713aSLionel Sambuc program also relies on additional C89-specific behavior that cannot 142f4a2713aSLionel Sambuc be changed.</li> 143f4a2713aSLionel Sambuc</ul> 144f4a2713aSLionel Sambuc 145f4a2713aSLionel Sambuc<p>All of this only applies to C code; the meaning of <code>inline</code> 146f4a2713aSLionel Sambucin C++ is very different from its meaning in either GNU89 or C99.</p> 147f4a2713aSLionel Sambuc 148f4a2713aSLionel Sambuc<!-- ======================================================================= --> 149f4a2713aSLionel Sambuc<h3 id="vector_builtins">"missing" vector __builtin functions</h3> 150f4a2713aSLionel Sambuc<!-- ======================================================================= --> 151f4a2713aSLionel Sambuc 152f4a2713aSLionel Sambuc<p>The Intel and AMD manuals document a number "<tt><*mmintrin.h></tt>" 153f4a2713aSLionel Sambucheader files, which define a standardized API for accessing vector operations 154f4a2713aSLionel Sambucon X86 CPUs. These functions have names like <tt>_mm_xor_ps</tt> and 155f4a2713aSLionel Sambuc<tt>_mm256_addsub_pd</tt>. Compilers have leeway to implement these functions 156f4a2713aSLionel Sambuchowever they want. Since Clang supports an excellent set of <a 157f4a2713aSLionel Sambuchref="../docs/LanguageExtensions.html#vectors">native vector operations</a>, 158f4a2713aSLionel Sambucthe Clang headers implement these interfaces in terms of the native vector 159f4a2713aSLionel Sambucoperations. 160f4a2713aSLionel Sambuc</p> 161f4a2713aSLionel Sambuc 162f4a2713aSLionel Sambuc<p>In contrast, GCC implements these functions mostly as a 1-to-1 mapping to 163f4a2713aSLionel Sambucbuiltin function calls, like <tt>__builtin_ia32_paddw128</tt>. These builtin 164f4a2713aSLionel Sambucfunctions are an internal implementation detail of GCC, and are not portable to 165f4a2713aSLionel Sambucthe Intel compiler, the Microsoft compiler, or Clang. If you get build errors 166f4a2713aSLionel Sambucmentioning these, the fix is simple: switch to the *mmintrin.h functions.</p> 167f4a2713aSLionel Sambuc 168f4a2713aSLionel Sambuc<p>The same issue occurs for NEON and Altivec for the ARM and PowerPC 169f4a2713aSLionel Sambucarchitectures respectively. For these, make sure to use the <arm_neon.h> 170f4a2713aSLionel Sambucand <altivec.h> headers.</p> 171f4a2713aSLionel Sambuc 172f4a2713aSLionel Sambuc<p>For x86 architectures this <a href="builtins.py">script</a> should help with 173f4a2713aSLionel Sambucthe manual migration process. It will rewrite your source files in place to 174f4a2713aSLionel Sambucuse the APIs instead of builtin function calls. Just call it like this:</p> 175f4a2713aSLionel Sambuc 176f4a2713aSLionel Sambuc<pre> 177f4a2713aSLionel Sambuc builtins.py *.c *.h 178f4a2713aSLionel Sambuc</pre> 179f4a2713aSLionel Sambuc 180f4a2713aSLionel Sambuc<p>and it will rewrite all of the .c and .h files in the current directory to 181f4a2713aSLionel Sambucuse the API calls instead of calls like <tt>__builtin_ia32_paddw128</tt>.</p> 182f4a2713aSLionel Sambuc 183f4a2713aSLionel Sambuc<!-- ======================================================================= --> 184f4a2713aSLionel Sambuc<h3 id="lvalue-cast">Lvalue casts</h3> 185f4a2713aSLionel Sambuc<!-- ======================================================================= --> 186f4a2713aSLionel Sambuc 187f4a2713aSLionel Sambuc<p>Old versions of GCC permit casting the left-hand side of an assignment to a 188f4a2713aSLionel Sambucdifferent type. Clang produces an error on similar code, e.g.,</p> 189f4a2713aSLionel Sambuc 190f4a2713aSLionel Sambuc<pre> 191f4a2713aSLionel Sambuc<b>lvalue.c:2:3: <span class="error">error:</span> assignment to cast is illegal, lvalue casts are not supported</b> 192f4a2713aSLionel Sambuc (int*)addr = val; 193f4a2713aSLionel Sambuc<span class="caret"> ^~~~~~~~~~ ~</span> 194f4a2713aSLionel Sambuc</pre> 195f4a2713aSLionel Sambuc 196f4a2713aSLionel Sambuc<p>To fix this problem, move the cast to the right-hand side. In this 197f4a2713aSLionel Sambucexample, one could use:</p> 198f4a2713aSLionel Sambuc 199f4a2713aSLionel Sambuc<pre> 200f4a2713aSLionel Sambuc addr = (float *)val; 201f4a2713aSLionel Sambuc</pre> 202f4a2713aSLionel Sambuc 203f4a2713aSLionel Sambuc<!-- ======================================================================= --> 204f4a2713aSLionel Sambuc<h3 id="blocks-in-protected-scope">Jumps to within <tt>__block</tt> variable scope</h3> 205f4a2713aSLionel Sambuc<!-- ======================================================================= --> 206f4a2713aSLionel Sambuc 207f4a2713aSLionel Sambuc<p>Clang disallows jumps into the scope of a <tt>__block</tt> 208f4a2713aSLionel Sambucvariable. Variables marked with <tt>__block</tt> require special 209f4a2713aSLionel Sambucruntime initialization. A jump into the scope of a <tt>__block</tt> 210f4a2713aSLionel Sambucvariable bypasses this initialization, leaving the variable's metadata 211f4a2713aSLionel Sambucin an invalid state. Consider the following code fragment:</p> 212f4a2713aSLionel Sambuc 213f4a2713aSLionel Sambuc<pre> 214f4a2713aSLionel Sambucint fetch_object_state(struct MyObject *c) { 215f4a2713aSLionel Sambuc if (!c->active) goto error; 216f4a2713aSLionel Sambuc 217f4a2713aSLionel Sambuc __block int result; 218f4a2713aSLionel Sambuc run_specially_somehow(^{ result = c->state; }); 219f4a2713aSLionel Sambuc return result; 220f4a2713aSLionel Sambuc 221f4a2713aSLionel Sambuc error: 222f4a2713aSLionel Sambuc fprintf(stderr, "error while fetching object state"); 223f4a2713aSLionel Sambuc return -1; 224f4a2713aSLionel Sambuc} 225f4a2713aSLionel Sambuc</pre> 226f4a2713aSLionel Sambuc 227f4a2713aSLionel Sambuc<p>GCC accepts this code, but it produces code that will usually crash 228f4a2713aSLionel Sambucwhen <code>result</code> goes out of scope if the jump is taken. (It's 229f4a2713aSLionel Sambucpossible for this bug to go undetected because it often won't crash if 230f4a2713aSLionel Sambucthe stack is fresh, i.e. still zeroed.) Therefore, Clang rejects this 231f4a2713aSLionel Sambuccode with a hard error:</p> 232f4a2713aSLionel Sambuc 233f4a2713aSLionel Sambuc<pre> 234f4a2713aSLionel Sambuc<b>t.c:3:5: <span class="error">error:</span> goto into protected scope</b> 235f4a2713aSLionel Sambuc goto error; 236f4a2713aSLionel Sambuc<span class="caret"> ^</span> 237f4a2713aSLionel Sambuc<b>t.c:5:15: <span class="note">note:</note></b> jump bypasses setup of __block variable 238f4a2713aSLionel Sambuc __block int result; 239f4a2713aSLionel Sambuc<span class="caret"> ^</span> 240f4a2713aSLionel Sambuc</pre> 241f4a2713aSLionel Sambuc 242f4a2713aSLionel Sambuc<p>The fix is to rewrite the code to not require jumping into a 243f4a2713aSLionel Sambuc<tt>__block</tt> variable's scope, e.g. by limiting that scope:</p> 244f4a2713aSLionel Sambuc 245f4a2713aSLionel Sambuc<pre> 246f4a2713aSLionel Sambuc { 247f4a2713aSLionel Sambuc __block int result; 248f4a2713aSLionel Sambuc run_specially_somehow(^{ result = c->state; }); 249f4a2713aSLionel Sambuc return result; 250f4a2713aSLionel Sambuc } 251f4a2713aSLionel Sambuc</pre> 252f4a2713aSLionel Sambuc 253f4a2713aSLionel Sambuc<!-- ======================================================================= --> 254f4a2713aSLionel Sambuc<h3 id="block-variable-initialization">Non-initialization of <tt>__block</tt> 255f4a2713aSLionel Sambucvariables</h3> 256f4a2713aSLionel Sambuc<!-- ======================================================================= --> 257f4a2713aSLionel Sambuc 258f4a2713aSLionel Sambuc<p>In the following example code, the <tt>x</tt> variable is used before it is 259f4a2713aSLionel Sambucdefined:</p> 260f4a2713aSLionel Sambuc<pre> 261f4a2713aSLionel Sambucint f0() { 262f4a2713aSLionel Sambuc __block int x; 263f4a2713aSLionel Sambuc return ^(){ return x; }(); 264f4a2713aSLionel Sambuc} 265f4a2713aSLionel Sambuc</pre> 266f4a2713aSLionel Sambuc 267f4a2713aSLionel Sambuc<p>By an accident of implementation, GCC and llvm-gcc unintentionally always 268f4a2713aSLionel Sambuczero initialized <tt>__block</tt> variables. However, any program which depends 269f4a2713aSLionel Sambucon this behavior is relying on unspecified compiler behavior. Programs must 270f4a2713aSLionel Sambucexplicitly initialize all local block variables before they are used, as with 271f4a2713aSLionel Sambucother local variables.</p> 272f4a2713aSLionel Sambuc 273f4a2713aSLionel Sambuc<p>Clang does not zero initialize local block variables, and programs which rely 274f4a2713aSLionel Sambucon such behavior will most likely break when built with Clang.</p> 275f4a2713aSLionel Sambuc 276f4a2713aSLionel Sambuc 277f4a2713aSLionel Sambuc<!-- ======================================================================= --> 278f4a2713aSLionel Sambuc<h3 id="inline-asm">Inline assembly</h3> 279f4a2713aSLionel Sambuc<!-- ======================================================================= --> 280f4a2713aSLionel Sambuc 281f4a2713aSLionel Sambuc<p>In general, Clang is highly compatible with the GCC inline assembly 282f4a2713aSLionel Sambucextensions, allowing the same set of constraints, modifiers and operands as GCC 283f4a2713aSLionel Sambucinline assembly.</p> 284f4a2713aSLionel Sambuc 285f4a2713aSLionel Sambuc<p>On targets that use the integrated assembler (such as most X86 targets), 286f4a2713aSLionel Sambucinline assembly is run through the integrated assembler instead of your system 287f4a2713aSLionel Sambucassembler (which is most commonly "gas", the GNU assembler). The LLVM 288f4a2713aSLionel Sambucintegrated assembler is extremely compatible with GAS, but there are a couple of 289f4a2713aSLionel Sambucminor places where it is more picky, particularly due to outright GAS bugs.</p> 290f4a2713aSLionel Sambuc 291f4a2713aSLionel Sambuc<p>One specific example is that the assembler rejects ambiguous X86 instructions 292f4a2713aSLionel Sambucthat don't have suffixes. For example:</p> 293f4a2713aSLionel Sambuc 294f4a2713aSLionel Sambuc<pre> 295f4a2713aSLionel Sambuc asm("add %al, (%rax)"); 296f4a2713aSLionel Sambuc asm("addw $4, (%rax)"); 297f4a2713aSLionel Sambuc asm("add $4, (%rax)"); 298f4a2713aSLionel Sambuc</pre> 299f4a2713aSLionel Sambuc 300f4a2713aSLionel Sambuc<p>Both clang and GAS accept the first instruction: because the first 301f4a2713aSLionel Sambucinstruction uses the 8-bit <tt>%al</tt> register as an operand, it is clear that 302f4a2713aSLionel Sambucit is an 8-bit add. The second instruction is accepted by both because the "w" 303f4a2713aSLionel Sambucsuffix indicates that it is a 16-bit add. The last instruction is accepted by 304f4a2713aSLionel SambucGAS even though there is nothing that specifies the size of the instruction (and 305f4a2713aSLionel Sambucthe assembler randomly picks a 32-bit add). Because it is ambiguous, Clang 306f4a2713aSLionel Sambucrejects the instruction with this error message: 307f4a2713aSLionel Sambuc</p> 308f4a2713aSLionel Sambuc 309f4a2713aSLionel Sambuc<pre> 310f4a2713aSLionel Sambuc<b><inline asm>:3:1: <span class="error">error:</span> ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq')</b> 311f4a2713aSLionel Sambucadd $4, (%rax) 312f4a2713aSLionel Sambuc<span class="caret">^</span> 313f4a2713aSLionel Sambuc</pre> 314f4a2713aSLionel Sambuc 315f4a2713aSLionel Sambuc<p>To fix this compatibility issue, add an explicit suffix to the instruction: 316f4a2713aSLionel Sambucthis makes your code more clear and is compatible with both GCC and Clang.</p> 317f4a2713aSLionel Sambuc 318f4a2713aSLionel Sambuc<!-- ======================================================================= --> 319f4a2713aSLionel Sambuc<h2 id="objective-c">Objective-C compatibility</h2> 320f4a2713aSLionel Sambuc<!-- ======================================================================= --> 321f4a2713aSLionel Sambuc 322f4a2713aSLionel Sambuc<!-- ======================================================================= --> 323f4a2713aSLionel Sambuc<h3 id="super-cast">Cast of super</h3> 324f4a2713aSLionel Sambuc<!-- ======================================================================= --> 325f4a2713aSLionel Sambuc 326f4a2713aSLionel Sambuc<p>GCC treats the <code>super</code> identifier as an expression that 327f4a2713aSLionel Sambuccan, among other things, be cast to a different type. Clang treats 328f4a2713aSLionel Sambuc<code>super</code> as a context-sensitive keyword, and will reject a 329f4a2713aSLionel Sambuctype-cast of <code>super</code>:</p> 330f4a2713aSLionel Sambuc 331f4a2713aSLionel Sambuc<pre> 332f4a2713aSLionel Sambuc<b>super.m:11:12: <span class="error">error:</span> cannot cast 'super' (it isn't an expression)</b> 333f4a2713aSLionel Sambuc [(Super*)super add:4]; 334f4a2713aSLionel Sambuc<span class="caret"> ~~~~~~~~^</span> 335f4a2713aSLionel Sambuc</pre> 336f4a2713aSLionel Sambuc 337f4a2713aSLionel Sambuc<p>To fix this problem, remove the type cast, e.g.</p> 338f4a2713aSLionel Sambuc<pre> 339f4a2713aSLionel Sambuc [super add:4]; 340f4a2713aSLionel Sambuc</pre> 341f4a2713aSLionel Sambuc 342f4a2713aSLionel Sambuc<!-- ======================================================================= --> 343f4a2713aSLionel Sambuc<h3 id="sizeof-interface">Size of interfaces</h3> 344f4a2713aSLionel Sambuc<!-- ======================================================================= --> 345f4a2713aSLionel Sambuc 346f4a2713aSLionel Sambuc<p>When using the "non-fragile" Objective-C ABI in use, the size of an 347f4a2713aSLionel SambucObjective-C class may change over time as instance variables are added 348f4a2713aSLionel Sambuc(or removed). For this reason, Clang rejects the application of the 349f4a2713aSLionel Sambuc<code>sizeof</code> operator to an Objective-C class when using this 350f4a2713aSLionel SambucABI:</p> 351f4a2713aSLionel Sambuc 352f4a2713aSLionel Sambuc<pre> 353f4a2713aSLionel Sambuc<b>sizeof.m:4:14: <span class="error">error:</span> invalid application of 'sizeof' to interface 'NSArray' in non-fragile ABI</b> 354f4a2713aSLionel Sambuc int size = sizeof(NSArray); 355f4a2713aSLionel Sambuc<span class="caret"> ^ ~~~~~~~~~</span> 356f4a2713aSLionel Sambuc</pre> 357f4a2713aSLionel Sambuc 358f4a2713aSLionel Sambuc<p>Code that relies on the size of an Objective-C class is likely to 359f4a2713aSLionel Sambucbe broken anyway, since that size is not actually constant. To address 360f4a2713aSLionel Sambucthis problem, use the Objective-C runtime API function 361f4a2713aSLionel Sambuc<code>class_getInstanceSize()</code>:</p> 362f4a2713aSLionel Sambuc 363f4a2713aSLionel Sambuc<pre> 364f4a2713aSLionel Sambuc class_getInstanceSize([NSArray class]) 365f4a2713aSLionel Sambuc</pre> 366f4a2713aSLionel Sambuc 367f4a2713aSLionel Sambuc<!-- ======================================================================= --> 368f4a2713aSLionel Sambuc<h3 id="objc_objs-cast">Internal Objective-C types</h3> 369f4a2713aSLionel Sambuc<!-- ======================================================================= --> 370f4a2713aSLionel Sambuc 371f4a2713aSLionel Sambuc<p>GCC allows using pointers to internal Objective-C objects, <tt>struct objc_object*</tt>, 372f4a2713aSLionel Sambuc<tt>struct objc_selector*</tt>, and <tt>struct objc_class*</tt> in place of the types 373f4a2713aSLionel Sambuc<tt>id</tt>, <tt>SEL</tt>, and <tt>Class</tt> respectively. Clang treats the 374f4a2713aSLionel Sambucinternal Objective-C structures as implementation detail and won't do implicit conversions: 375f4a2713aSLionel Sambuc 376f4a2713aSLionel Sambuc<pre> 377f4a2713aSLionel Sambuc<b>t.mm:11:2: <span class="error">error:</span> no matching function for call to 'f'</b> 378f4a2713aSLionel Sambuc f((struct objc_object *)p); 379f4a2713aSLionel Sambuc<span class="caret"> ^</span> 380f4a2713aSLionel Sambuc<b>t.mm:5:6: <span class="note">note:</note></b> candidate function not viable: no known conversion from 'struct objc_object *' to 'id' for 1st argument 381f4a2713aSLionel Sambucvoid f(id x); 382f4a2713aSLionel Sambuc<span class="caret"> ^</span> 383f4a2713aSLionel Sambuc</pre> 384f4a2713aSLionel Sambuc 385f4a2713aSLionel Sambuc<p>Code should use types <tt>id</tt>, <tt>SEL</tt>, and <tt>Class</tt> 386f4a2713aSLionel Sambucinstead of the internal types.</p> 387f4a2713aSLionel Sambuc 388f4a2713aSLionel Sambuc<!-- ======================================================================= --> 389f4a2713aSLionel Sambuc<h3 id="c_variables-class">C variables in @interface or @protocol</h3> 390f4a2713aSLionel Sambuc<!-- ======================================================================= --> 391f4a2713aSLionel Sambuc 392f4a2713aSLionel Sambuc<p>GCC allows the declaration of C variables in 393f4a2713aSLionel Sambucan <code>@interface</code> or <code>@protocol</code> 394f4a2713aSLionel Sambucdeclaration. Clang does not allow variable declarations to appear 395f4a2713aSLionel Sambucwithin these declarations unless they are marked <code>extern</code>.</p> 396f4a2713aSLionel Sambuc 397f4a2713aSLionel Sambuc<p>Variables may still be declared in an @implementation.</p> 398f4a2713aSLionel Sambuc 399f4a2713aSLionel Sambuc<pre> 400f4a2713aSLionel Sambuc@interface XX 401f4a2713aSLionel Sambucint a; // not allowed in clang 402f4a2713aSLionel Sambucint b = 1; // not allowed in clang 403f4a2713aSLionel Sambucextern int c; // allowed 404f4a2713aSLionel Sambuc@end 405f4a2713aSLionel Sambuc 406f4a2713aSLionel Sambuc</pre> 407f4a2713aSLionel Sambuc 408f4a2713aSLionel Sambuc<!-- ======================================================================= --> 409f4a2713aSLionel Sambuc<h2 id="cxx">C++ compatibility</h2> 410f4a2713aSLionel Sambuc<!-- ======================================================================= --> 411f4a2713aSLionel Sambuc 412f4a2713aSLionel Sambuc<!-- ======================================================================= --> 413f4a2713aSLionel Sambuc<h3 id="vla">Variable-length arrays</h3> 414f4a2713aSLionel Sambuc<!-- ======================================================================= --> 415f4a2713aSLionel Sambuc 416f4a2713aSLionel Sambuc<p>GCC and C99 allow an array's size to be determined at run 417f4a2713aSLionel Sambuctime. This extension is not permitted in standard C++. However, Clang 418f4a2713aSLionel Sambucsupports such variable length arrays in very limited circumstances for 419f4a2713aSLionel Sambuccompatibility with GNU C and C99 programs:</p> 420f4a2713aSLionel Sambuc 421f4a2713aSLionel Sambuc<ul> 422f4a2713aSLionel Sambuc <li>The element type of a variable length array must be a POD 423f4a2713aSLionel Sambuc ("plain old data") type, which means that it cannot have any 424f4a2713aSLionel Sambuc user-declared constructors or destructors, any base classes, or any 425f4a2713aSLionel Sambuc members of non-POD type. All C types are POD types.</li> 426f4a2713aSLionel Sambuc 427f4a2713aSLionel Sambuc <li>Variable length arrays cannot be used as the type of a non-type 428f4a2713aSLionel Sambuctemplate parameter.</li> </ul> 429f4a2713aSLionel Sambuc 430f4a2713aSLionel Sambuc<p>If your code uses variable length arrays in a manner that Clang doesn't support, there are several ways to fix your code: 431f4a2713aSLionel Sambuc 432f4a2713aSLionel Sambuc<ol> 433f4a2713aSLionel Sambuc<li>replace the variable length array with a fixed-size array if you can 434f4a2713aSLionel Sambuc determine a reasonable upper bound at compile time; sometimes this is as 435f4a2713aSLionel Sambuc simple as changing <tt>int size = ...;</tt> to <tt>const int size 436f4a2713aSLionel Sambuc = ...;</tt> (if the initializer is a compile-time constant);</li> 437f4a2713aSLionel Sambuc<li>use <tt>std::vector</tt> or some other suitable container type; 438f4a2713aSLionel Sambuc or</li> 439f4a2713aSLionel Sambuc<li>allocate the array on the heap instead using <tt>new Type[]</tt> - 440f4a2713aSLionel Sambuc just remember to <tt>delete[]</tt> it.</li> 441f4a2713aSLionel Sambuc</ol> 442f4a2713aSLionel Sambuc 443f4a2713aSLionel Sambuc<!-- ======================================================================= --> 444f4a2713aSLionel Sambuc<h3 id="dep_lookup">Unqualified lookup in templates</h3> 445f4a2713aSLionel Sambuc<!-- ======================================================================= --> 446f4a2713aSLionel Sambuc 447f4a2713aSLionel Sambuc<p>Some versions of GCC accept the following invalid code: 448f4a2713aSLionel Sambuc 449f4a2713aSLionel Sambuc<pre> 450f4a2713aSLionel Sambuctemplate <typename T> T Squared(T x) { 451f4a2713aSLionel Sambuc return Multiply(x, x); 452f4a2713aSLionel Sambuc} 453f4a2713aSLionel Sambuc 454f4a2713aSLionel Sambucint Multiply(int x, int y) { 455f4a2713aSLionel Sambuc return x * y; 456f4a2713aSLionel Sambuc} 457f4a2713aSLionel Sambuc 458f4a2713aSLionel Sambucint main() { 459f4a2713aSLionel Sambuc Squared(5); 460f4a2713aSLionel Sambuc} 461f4a2713aSLionel Sambuc</pre> 462f4a2713aSLionel Sambuc 463f4a2713aSLionel Sambuc<p>Clang complains: 464f4a2713aSLionel Sambuc 465f4a2713aSLionel Sambuc<pre> 466f4a2713aSLionel Sambuc<b>my_file.cpp:2:10: <span class="error">error:</span> call to function 'Multiply' that is neither visible in the template definition nor found by argument-dependent lookup</b> 467f4a2713aSLionel Sambuc return Multiply(x, x); 468f4a2713aSLionel Sambuc<span class="caret"> ^</span> 469f4a2713aSLionel Sambuc<b>my_file.cpp:10:3: <span class="note">note:</span></b> in instantiation of function template specialization 'Squared<int>' requested here 470f4a2713aSLionel Sambuc Squared(5); 471f4a2713aSLionel Sambuc<span class="caret"> ^</span> 472f4a2713aSLionel Sambuc<b>my_file.cpp:5:5: <span class="note">note:</span></b> 'Multiply' should be declared prior to the call site 473f4a2713aSLionel Sambucint Multiply(int x, int y) { 474f4a2713aSLionel Sambuc<span class="caret"> ^</span> 475f4a2713aSLionel Sambuc</pre> 476f4a2713aSLionel Sambuc 477f4a2713aSLionel Sambuc<p>The C++ standard says that unqualified names like <q>Multiply</q> 478f4a2713aSLionel Sambucare looked up in two ways. 479f4a2713aSLionel Sambuc 480f4a2713aSLionel Sambuc<p>First, the compiler does <i>unqualified lookup</i> in the scope 481f4a2713aSLionel Sambucwhere the name was written. For a template, this means the lookup is 482f4a2713aSLionel Sambucdone at the point where the template is defined, not where it's 483f4a2713aSLionel Sambucinstantiated. Since <tt>Multiply</tt> hasn't been declared yet at 484f4a2713aSLionel Sambucthis point, unqualified lookup won't find it. 485f4a2713aSLionel Sambuc 486f4a2713aSLionel Sambuc<p>Second, if the name is called like a function, then the compiler 487f4a2713aSLionel Sambucalso does <i>argument-dependent lookup</i> (ADL). (Sometimes 488f4a2713aSLionel Sambucunqualified lookup can suppress ADL; see [basic.lookup.argdep]p3 for 489f4a2713aSLionel Sambucmore information.) In ADL, the compiler looks at the types of all the 490f4a2713aSLionel Sambucarguments to the call. When it finds a class type, it looks up the 491f4a2713aSLionel Sambucname in that class's namespace; the result is all the declarations it 492f4a2713aSLionel Sambucfinds in those namespaces, plus the declarations from unqualified 493f4a2713aSLionel Sambuclookup. However, the compiler doesn't do ADL until it knows all the 494f4a2713aSLionel Sambucargument types. 495f4a2713aSLionel Sambuc 496f4a2713aSLionel Sambuc<p>In our example, <tt>Multiply</tt> is called with dependent 497f4a2713aSLionel Sambucarguments, so ADL isn't done until the template is instantiated. At 498f4a2713aSLionel Sambucthat point, the arguments both have type <tt>int</tt>, which doesn't 499f4a2713aSLionel Sambuccontain any class types, and so ADL doesn't look in any namespaces. 500f4a2713aSLionel SambucSince neither form of lookup found the declaration 501f4a2713aSLionel Sambucof <tt>Multiply</tt>, the code doesn't compile. 502f4a2713aSLionel Sambuc 503f4a2713aSLionel Sambuc<p>Here's another example, this time using overloaded operators, 504f4a2713aSLionel Sambucwhich obey very similar rules. 505f4a2713aSLionel Sambuc 506f4a2713aSLionel Sambuc<pre>#include <iostream> 507f4a2713aSLionel Sambuc 508f4a2713aSLionel Sambuctemplate<typename T> 509f4a2713aSLionel Sambucvoid Dump(const T& value) { 510f4a2713aSLionel Sambuc std::cout << value << "\n"; 511f4a2713aSLionel Sambuc} 512f4a2713aSLionel Sambuc 513f4a2713aSLionel Sambucnamespace ns { 514f4a2713aSLionel Sambuc struct Data {}; 515f4a2713aSLionel Sambuc} 516f4a2713aSLionel Sambuc 517f4a2713aSLionel Sambucstd::ostream& operator<<(std::ostream& out, ns::Data data) { 518f4a2713aSLionel Sambuc return out << "Some data"; 519f4a2713aSLionel Sambuc} 520f4a2713aSLionel Sambuc 521f4a2713aSLionel Sambucvoid Use() { 522f4a2713aSLionel Sambuc Dump(ns::Data()); 523f4a2713aSLionel Sambuc}</pre> 524f4a2713aSLionel Sambuc 525f4a2713aSLionel Sambuc<p>Again, Clang complains:</p> 526f4a2713aSLionel Sambuc 527f4a2713aSLionel Sambuc<pre> 528f4a2713aSLionel Sambuc<b>my_file2.cpp:5:13: <span class="error">error:</span> call to function 'operator<<' that is neither visible in the template definition nor found by argument-dependent lookup</b> 529f4a2713aSLionel Sambuc std::cout << value << "\n"; 530f4a2713aSLionel Sambuc<span class="caret"> ^</span> 531f4a2713aSLionel Sambuc<b>my_file2.cpp:17:3: <span class="note">note:</span></b> in instantiation of function template specialization 'Dump<ns::Data>' requested here 532f4a2713aSLionel Sambuc Dump(ns::Data()); 533f4a2713aSLionel Sambuc<span class="caret"> ^</span> 534f4a2713aSLionel Sambuc<b>my_file2.cpp:12:15: <span class="note">note:</span></b> 'operator<<' should be declared prior to the call site or in namespace 'ns' 535f4a2713aSLionel Sambucstd::ostream& operator<<(std::ostream& out, ns::Data data) { 536f4a2713aSLionel Sambuc<span class="caret"> ^</span> 537f4a2713aSLionel Sambuc</pre> 538f4a2713aSLionel Sambuc 539f4a2713aSLionel Sambuc<p>Just like before, unqualified lookup didn't find any declarations 540f4a2713aSLionel Sambucwith the name <tt>operator<<</tt>. Unlike before, the argument 541f4a2713aSLionel Sambuctypes both contain class types: one of them is an instance of the 542f4a2713aSLionel Sambucclass template type <tt>std::basic_ostream</tt>, and the other is the 543f4a2713aSLionel Sambuctype <tt>ns::Data</tt> that we declared above. Therefore, ADL will 544f4a2713aSLionel Sambuclook in the namespaces <tt>std</tt> and <tt>ns</tt> for 545f4a2713aSLionel Sambucan <tt>operator<<</tt>. Since one of the argument types was 546f4a2713aSLionel Sambucstill dependent during the template definition, ADL isn't done until 547f4a2713aSLionel Sambucthe template is instantiated during <tt>Use</tt>, which means that 548f4a2713aSLionel Sambucthe <tt>operator<<</tt> we want it to find has already been 549f4a2713aSLionel Sambucdeclared. Unfortunately, it was declared in the global namespace, not 550f4a2713aSLionel Sambucin either of the namespaces that ADL will look in! 551f4a2713aSLionel Sambuc 552f4a2713aSLionel Sambuc<p>There are two ways to fix this problem:</p> 553f4a2713aSLionel Sambuc<ol><li>Make sure the function you want to call is declared before the 554f4a2713aSLionel Sambuctemplate that might call it. This is the only option if none of its 555f4a2713aSLionel Sambucargument types contain classes. You can do this either by moving the 556f4a2713aSLionel Sambuctemplate definition, or by moving the function definition, or by 557f4a2713aSLionel Sambucadding a forward declaration of the function before the template.</li> 558f4a2713aSLionel Sambuc<li>Move the function into the same namespace as one of its arguments 559f4a2713aSLionel Sambucso that ADL applies.</li></ol> 560f4a2713aSLionel Sambuc 561f4a2713aSLionel Sambuc<p>For more information about argument-dependent lookup, see 562f4a2713aSLionel Sambuc[basic.lookup.argdep]. For more information about the ordering of 563f4a2713aSLionel Sambuclookup in templates, see [temp.dep.candidate]. 564f4a2713aSLionel Sambuc 565f4a2713aSLionel Sambuc<!-- ======================================================================= --> 566f4a2713aSLionel Sambuc<h3 id="dep_lookup_bases">Unqualified lookup into dependent bases of class templates</h3> 567f4a2713aSLionel Sambuc<!-- ======================================================================= --> 568f4a2713aSLionel Sambuc 569f4a2713aSLionel SambucSome versions of GCC accept the following invalid code: 570f4a2713aSLionel Sambuc 571f4a2713aSLionel Sambuc<pre> 572f4a2713aSLionel Sambuctemplate <typename T> struct Base { 573f4a2713aSLionel Sambuc void DoThis(T x) {} 574f4a2713aSLionel Sambuc static void DoThat(T x) {} 575f4a2713aSLionel Sambuc}; 576f4a2713aSLionel Sambuc 577f4a2713aSLionel Sambuctemplate <typename T> struct Derived : public Base<T> { 578f4a2713aSLionel Sambuc void Work(T x) { 579f4a2713aSLionel Sambuc DoThis(x); // Invalid! 580f4a2713aSLionel Sambuc DoThat(x); // Invalid! 581f4a2713aSLionel Sambuc } 582f4a2713aSLionel Sambuc}; 583f4a2713aSLionel Sambuc</pre> 584f4a2713aSLionel Sambuc 585f4a2713aSLionel SambucClang correctly rejects it with the following errors 586f4a2713aSLionel Sambuc(when <tt>Derived</tt> is eventually instantiated): 587f4a2713aSLionel Sambuc 588f4a2713aSLionel Sambuc<pre> 589f4a2713aSLionel Sambuc<b>my_file.cpp:8:5: <span class="error">error:</span> use of undeclared identifier 'DoThis'</b> 590f4a2713aSLionel Sambuc DoThis(x); 591f4a2713aSLionel Sambuc<span class="caret"> ^</span> 592f4a2713aSLionel Sambuc this-> 593f4a2713aSLionel Sambuc<b>my_file.cpp:2:8: <span class="note">note:</note></b> must qualify identifier to find this declaration in dependent base class 594f4a2713aSLionel Sambuc void DoThis(T x) {} 595f4a2713aSLionel Sambuc<span class="caret"> ^</span> 596f4a2713aSLionel Sambuc<b>my_file.cpp:9:5: <span class="error">error:</span> use of undeclared identifier 'DoThat'</b> 597f4a2713aSLionel Sambuc DoThat(x); 598f4a2713aSLionel Sambuc<span class="caret"> ^</span> 599f4a2713aSLionel Sambuc this-> 600f4a2713aSLionel Sambuc<b>my_file.cpp:3:15: <span class="note">note:</note></b> must qualify identifier to find this declaration in dependent base class 601f4a2713aSLionel Sambuc static void DoThat(T x) {} 602f4a2713aSLionel Sambuc</pre> 603f4a2713aSLionel Sambuc 604f4a2713aSLionel SambucLike we said <a href="#dep_lookup">above</a>, unqualified names like 605f4a2713aSLionel Sambuc<tt>DoThis</tt> and <tt>DoThat</tt> are looked up when the template 606f4a2713aSLionel Sambuc<tt>Derived</tt> is defined, not when it's instantiated. When we look 607f4a2713aSLionel Sambucup a name used in a class, we usually look into the base classes. 608f4a2713aSLionel SambucHowever, we can't look into the base class <tt>Base<T></tt> 609f4a2713aSLionel Sambucbecause its type depends on the template argument <tt>T</tt>, so the 610f4a2713aSLionel Sambucstandard says we should just ignore it. See [temp.dep]p3 for details. 611f4a2713aSLionel Sambuc 612f4a2713aSLionel Sambuc<p>The fix, as Clang tells you, is to tell the compiler that we want a 613f4a2713aSLionel Sambucclass member by prefixing the calls with <tt>this-></tt>: 614f4a2713aSLionel Sambuc 615f4a2713aSLionel Sambuc<pre> 616f4a2713aSLionel Sambuc void Work(T x) { 617f4a2713aSLionel Sambuc <b>this-></b>DoThis(x); 618f4a2713aSLionel Sambuc <b>this-></b>DoThat(x); 619f4a2713aSLionel Sambuc } 620f4a2713aSLionel Sambuc</pre> 621f4a2713aSLionel Sambuc 622f4a2713aSLionel SambucAlternatively, you can tell the compiler exactly where to look: 623f4a2713aSLionel Sambuc 624f4a2713aSLionel Sambuc<pre> 625f4a2713aSLionel Sambuc void Work(T x) { 626f4a2713aSLionel Sambuc <b>Base<T></b>::DoThis(x); 627f4a2713aSLionel Sambuc <b>Base<T></b>::DoThat(x); 628f4a2713aSLionel Sambuc } 629f4a2713aSLionel Sambuc</pre> 630f4a2713aSLionel Sambuc 631f4a2713aSLionel SambucThis works whether the methods are static or not, but be careful: 632f4a2713aSLionel Sambucif <tt>DoThis</tt> is virtual, calling it this way will bypass virtual 633f4a2713aSLionel Sambucdispatch! 634f4a2713aSLionel Sambuc 635f4a2713aSLionel Sambuc<!-- ======================================================================= --> 636f4a2713aSLionel Sambuc<h3 id="undep_incomplete">Incomplete types in templates</h3> 637f4a2713aSLionel Sambuc<!-- ======================================================================= --> 638f4a2713aSLionel Sambuc 639f4a2713aSLionel SambucThe following code is invalid, but compilers are allowed to accept it: 640f4a2713aSLionel Sambuc 641f4a2713aSLionel Sambuc<pre> 642f4a2713aSLionel Sambuc class IOOptions; 643f4a2713aSLionel Sambuc template <class T> bool read(T &value) { 644f4a2713aSLionel Sambuc IOOptions opts; 645f4a2713aSLionel Sambuc return read(opts, value); 646f4a2713aSLionel Sambuc } 647f4a2713aSLionel Sambuc 648f4a2713aSLionel Sambuc class IOOptions { bool ForceReads; }; 649f4a2713aSLionel Sambuc bool read(const IOOptions &opts, int &x); 650f4a2713aSLionel Sambuc template bool read<>(int &); 651f4a2713aSLionel Sambuc</pre> 652f4a2713aSLionel Sambuc 653f4a2713aSLionel SambucThe standard says that types which don't depend on template parameters 654f4a2713aSLionel Sambucmust be complete when a template is defined if they affect the 655f4a2713aSLionel Sambucprogram's behavior. However, the standard also says that compilers 656f4a2713aSLionel Sambucare free to not enforce this rule. Most compilers enforce it to some 657f4a2713aSLionel Sambucextent; for example, it would be an error in GCC to 658f4a2713aSLionel Sambucwrite <tt>opts.ForceReads</tt> in the code above. In Clang, we feel 659f4a2713aSLionel Sambucthat enforcing the rule consistently lets us provide a better 660f4a2713aSLionel Sambucexperience, but unfortunately it also means we reject some code that 661f4a2713aSLionel Sambucother compilers accept. 662f4a2713aSLionel Sambuc 663f4a2713aSLionel Sambuc<p>We've explained the rule here in very imprecise terms; see 664f4a2713aSLionel Sambuc[temp.res]p8 for details. 665f4a2713aSLionel Sambuc 666f4a2713aSLionel Sambuc<!-- ======================================================================= --> 667f4a2713aSLionel Sambuc<h3 id="bad_templates">Templates with no valid instantiations</h3> 668f4a2713aSLionel Sambuc<!-- ======================================================================= --> 669f4a2713aSLionel Sambuc 670f4a2713aSLionel SambucThe following code contains a typo: the programmer 671f4a2713aSLionel Sambucmeant <tt>init()</tt> but wrote <tt>innit()</tt> instead. 672f4a2713aSLionel Sambuc 673f4a2713aSLionel Sambuc<pre> 674f4a2713aSLionel Sambuc template <class T> class Processor { 675f4a2713aSLionel Sambuc ... 676f4a2713aSLionel Sambuc void init(); 677f4a2713aSLionel Sambuc ... 678f4a2713aSLionel Sambuc }; 679f4a2713aSLionel Sambuc ... 680f4a2713aSLionel Sambuc template <class T> void process() { 681f4a2713aSLionel Sambuc Processor<T> processor; 682f4a2713aSLionel Sambuc processor.innit(); // <-- should be 'init()' 683f4a2713aSLionel Sambuc ... 684f4a2713aSLionel Sambuc } 685f4a2713aSLionel Sambuc</pre> 686f4a2713aSLionel Sambuc 687f4a2713aSLionel SambucUnfortunately, we can't flag this mistake as soon as we see it: inside 688f4a2713aSLionel Sambuca template, we're not allowed to make assumptions about "dependent 689f4a2713aSLionel Sambuctypes" like <tt>Processor<T></tt>. Suppose that later on in 690f4a2713aSLionel Sambucthis file the programmer adds an explicit specialization 691f4a2713aSLionel Sambucof <tt>Processor</tt>, like so: 692f4a2713aSLionel Sambuc 693f4a2713aSLionel Sambuc<pre> 694f4a2713aSLionel Sambuc template <> class Processor<char*> { 695f4a2713aSLionel Sambuc void innit(); 696f4a2713aSLionel Sambuc }; 697f4a2713aSLionel Sambuc</pre> 698f4a2713aSLionel Sambuc 699f4a2713aSLionel SambucNow the program will work — as long as the programmer only ever 700f4a2713aSLionel Sambucinstantiates <tt>process()</tt> with <tt>T = char*</tt>! This is why 701f4a2713aSLionel Sambucit's hard, and sometimes impossible, to diagnose mistakes in a 702f4a2713aSLionel Sambuctemplate definition before it's instantiated. 703f4a2713aSLionel Sambuc 704f4a2713aSLionel Sambuc<p>The standard says that a template with no valid instantiations is 705f4a2713aSLionel Sambucill-formed. Clang tries to do as much checking as possible at 706f4a2713aSLionel Sambucdefinition-time instead of instantiation-time: not only does this 707f4a2713aSLionel Sambucproduce clearer diagnostics, but it also substantially improves 708f4a2713aSLionel Sambuccompile times when using pre-compiled headers. The downside to this 709f4a2713aSLionel Sambucphilosophy is that Clang sometimes fails to process files because they 710f4a2713aSLionel Sambuccontain broken templates that are no longer used. The solution is 711f4a2713aSLionel Sambucsimple: since the code is unused, just remove it. 712f4a2713aSLionel Sambuc 713f4a2713aSLionel Sambuc<!-- ======================================================================= --> 714f4a2713aSLionel Sambuc<h3 id="default_init_const">Default initialization of const variable of a class type requires user-defined default constructor</h3> 715f4a2713aSLionel Sambuc<!-- ======================================================================= --> 716f4a2713aSLionel Sambuc 717f4a2713aSLionel SambucIf a <tt>class</tt> or <tt>struct</tt> has no user-defined default 718f4a2713aSLionel Sambucconstructor, C++ doesn't allow you to default construct a <tt>const</tt> 719f4a2713aSLionel Sambucinstance of it like this ([dcl.init], p9): 720f4a2713aSLionel Sambuc 721f4a2713aSLionel Sambuc<pre> 722f4a2713aSLionel Sambucclass Foo { 723f4a2713aSLionel Sambuc public: 724f4a2713aSLionel Sambuc // The compiler-supplied default constructor works fine, so we 725f4a2713aSLionel Sambuc // don't bother with defining one. 726f4a2713aSLionel Sambuc ... 727f4a2713aSLionel Sambuc}; 728f4a2713aSLionel Sambuc 729f4a2713aSLionel Sambucvoid Bar() { 730f4a2713aSLionel Sambuc const Foo foo; // Error! 731f4a2713aSLionel Sambuc ... 732f4a2713aSLionel Sambuc} 733f4a2713aSLionel Sambuc</pre> 734f4a2713aSLionel Sambuc 735f4a2713aSLionel SambucTo fix this, you can define a default constructor for the class: 736f4a2713aSLionel Sambuc 737f4a2713aSLionel Sambuc<pre> 738f4a2713aSLionel Sambucclass Foo { 739f4a2713aSLionel Sambuc public: 740f4a2713aSLionel Sambuc Foo() {} 741f4a2713aSLionel Sambuc ... 742f4a2713aSLionel Sambuc}; 743f4a2713aSLionel Sambuc 744f4a2713aSLionel Sambucvoid Bar() { 745f4a2713aSLionel Sambuc const Foo foo; // Now the compiler is happy. 746f4a2713aSLionel Sambuc ... 747f4a2713aSLionel Sambuc} 748f4a2713aSLionel Sambuc</pre> 749f4a2713aSLionel Sambuc 750f4a2713aSLionel Sambuc<!-- ======================================================================= --> 751f4a2713aSLionel Sambuc<h3 id="param_name_lookup">Parameter name lookup</h3> 752f4a2713aSLionel Sambuc<!-- ======================================================================= --> 753f4a2713aSLionel Sambuc 754f4a2713aSLionel Sambuc<p>Due to a bug in its implementation, GCC allows the redeclaration of function parameter names within a function prototype in C++ code, e.g.</p> 755f4a2713aSLionel Sambuc<blockquote> 756f4a2713aSLionel Sambuc<pre> 757f4a2713aSLionel Sambucvoid f(int a, int a); 758f4a2713aSLionel Sambuc</pre> 759f4a2713aSLionel Sambuc</blockquote> 760f4a2713aSLionel Sambuc<p>Clang diagnoses this error (where the parameter name has been redeclared). To fix this problem, rename one of the parameters.</p> 761f4a2713aSLionel Sambuc 762f4a2713aSLionel Sambuc<!-- ======================================================================= --> 763f4a2713aSLionel Sambuc<h2 id="cxx11">C++11 compatibility</h2> 764f4a2713aSLionel Sambuc<!-- ======================================================================= --> 765f4a2713aSLionel Sambuc 766f4a2713aSLionel Sambuc<!-- ======================================================================= --> 767f4a2713aSLionel Sambuc<h3 id="deleted-special-func">Deleted special member functions</h3> 768f4a2713aSLionel Sambuc<!-- ======================================================================= --> 769f4a2713aSLionel Sambuc 770f4a2713aSLionel Sambuc<p>In C++11, the explicit declaration of a move constructor or a move 771f4a2713aSLionel Sambucassignment operator within a class deletes the implicit declaration 772f4a2713aSLionel Sambucof the copy constructor and copy assignment operator. This change came 773f4a2713aSLionel Sambucfairly late in the C++11 standardization process, so early 774f4a2713aSLionel Sambucimplementations of C++11 (including Clang before 3.0, GCC before 4.7, 775f4a2713aSLionel Sambucand Visual Studio 2010) do not implement this rule, leading them to 776f4a2713aSLionel Sambucaccept this ill-formed code:</p> 777f4a2713aSLionel Sambuc 778f4a2713aSLionel Sambuc<pre> 779f4a2713aSLionel Sambucstruct X { 780f4a2713aSLionel Sambuc X(X&&); <i>// deletes implicit copy constructor:</i> 781f4a2713aSLionel Sambuc <i>// X(const X&) = delete;</i> 782f4a2713aSLionel Sambuc}; 783f4a2713aSLionel Sambuc 784f4a2713aSLionel Sambucvoid f(X x); 785f4a2713aSLionel Sambucvoid g(X x) { 786f4a2713aSLionel Sambuc f(x); <i>// error: X has a deleted copy constructor</i> 787f4a2713aSLionel Sambuc} 788f4a2713aSLionel Sambuc</pre> 789f4a2713aSLionel Sambuc 790f4a2713aSLionel Sambuc<p>This affects some early C++11 code, including Boost's popular <a 791f4a2713aSLionel Sambuchref="http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm"><tt>shared_ptr</tt></a> 792f4a2713aSLionel Sambucup to version 1.47.0. The fix for Boost's <tt>shared_ptr</tt> is 793f4a2713aSLionel Sambuc<a href="https://svn.boost.org/trac/boost/changeset/73202">available here</a>.</p> 794f4a2713aSLionel Sambuc 795f4a2713aSLionel Sambuc<!-- ======================================================================= --> 796f4a2713aSLionel Sambuc<h2 id="objective-cxx">Objective-C++ compatibility</h2> 797f4a2713aSLionel Sambuc<!-- ======================================================================= --> 798f4a2713aSLionel Sambuc 799f4a2713aSLionel Sambuc<!-- ======================================================================= --> 800f4a2713aSLionel Sambuc<h3 id="implicit-downcasts">Implicit downcasts</h3> 801f4a2713aSLionel Sambuc<!-- ======================================================================= --> 802f4a2713aSLionel Sambuc 803f4a2713aSLionel Sambuc<p>Due to a bug in its implementation, GCC allows implicit downcasts 804f4a2713aSLionel Sambucof Objective-C pointers (from a base class to a derived class) when 805f4a2713aSLionel Sambuccalling functions. Such code is inherently unsafe, since the object 806f4a2713aSLionel Sambucmight not actually be an instance of the derived class, and is 807f4a2713aSLionel Sambucrejected by Clang. For example, given this code:</p> 808f4a2713aSLionel Sambuc 809f4a2713aSLionel Sambuc<pre> 810f4a2713aSLionel Sambuc@interface Base @end 811f4a2713aSLionel Sambuc@interface Derived : Base @end 812f4a2713aSLionel Sambuc 813f4a2713aSLionel Sambucvoid f(Derived *p); 814f4a2713aSLionel Sambucvoid g(Base *p) { 815f4a2713aSLionel Sambuc f(p); 816f4a2713aSLionel Sambuc} 817f4a2713aSLionel Sambuc</pre> 818f4a2713aSLionel Sambuc 819f4a2713aSLionel Sambuc<p>Clang produces the following error:</p> 820f4a2713aSLionel Sambuc 821f4a2713aSLionel Sambuc<pre> 822f4a2713aSLionel Sambuc<b>downcast.mm:6:3: <span class="error">error:</span> no matching function for call to 'f'</b> 823f4a2713aSLionel Sambuc f(p); 824f4a2713aSLionel Sambuc<span class="caret"> ^</span> 825f4a2713aSLionel Sambuc<b>downcast.mm:4:6: <span class="note">note:</note></b> candidate function not viable: cannot convert from 826f4a2713aSLionel Sambuc superclass 'Base *' to subclass 'Derived *' for 1st argument 827f4a2713aSLionel Sambucvoid f(Derived *p); 828f4a2713aSLionel Sambuc<span class="caret"> ^</span> 829f4a2713aSLionel Sambuc</pre> 830f4a2713aSLionel Sambuc 831f4a2713aSLionel Sambuc<p>If the downcast is actually correct (e.g., because the code has 832f4a2713aSLionel Sambucalready checked that the object has the appropriate type), add an 833f4a2713aSLionel Sambucexplicit cast:</p> 834f4a2713aSLionel Sambuc 835f4a2713aSLionel Sambuc<pre> 836f4a2713aSLionel Sambuc f((Derived *)base); 837f4a2713aSLionel Sambuc</pre> 838f4a2713aSLionel Sambuc 839f4a2713aSLionel Sambuc<!-- ======================================================================= --> 840f4a2713aSLionel Sambuc<h3 id="class-as-property-name">Using <code>class</code> as a property name</h3> 841f4a2713aSLionel Sambuc<!-- ======================================================================= --> 842f4a2713aSLionel Sambuc 843f4a2713aSLionel Sambuc<p>In C and Objective-C, <code>class</code> is a normal identifier and 844f4a2713aSLionel Sambuccan be used to name fields, ivars, methods, and so on. In 845f4a2713aSLionel SambucC++, <code>class</code> is a keyword. For compatibility with existing 846f4a2713aSLionel Sambuccode, Clang permits <code>class</code> to be used as part of a method 847f4a2713aSLionel Sambucselector in Objective-C++, but this does not extend to any other part 848f4a2713aSLionel Sambucof the language. In particular, it is impossible to use property dot 849f4a2713aSLionel Sambucsyntax in Objective-C++ with the property name <code>class</code>, so 850f4a2713aSLionel Sambucthe following code will fail to parse:</p> 851f4a2713aSLionel Sambuc 852f4a2713aSLionel Sambuc<pre> 853f4a2713aSLionel Sambuc@interface I { 854f4a2713aSLionel Sambucint cls; 855f4a2713aSLionel Sambuc} 856f4a2713aSLionel Sambuc+ (int)class; 857f4a2713aSLionel Sambuc@end 858f4a2713aSLionel Sambuc 859f4a2713aSLionel Sambuc@implementation I 860f4a2713aSLionel Sambuc- (int) Meth { return I.class; } 861f4a2713aSLionel Sambuc@end 862f4a2713aSLionel Sambuc</pre> 863f4a2713aSLionel Sambuc 864f4a2713aSLionel Sambuc<p>Use explicit message-send syntax instead, i.e. <code>[I class]</code>.</p> 865f4a2713aSLionel Sambuc 866f4a2713aSLionel Sambuc</div> 867f4a2713aSLionel Sambuc</body> 868f4a2713aSLionel Sambuc</html> 869