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