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