www/compatibility.html

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