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="#lvalue-cast">Lvalue casts</a></li>
  36       <li><a href="#blocks-in-protected-scope">Jumps to within <tt>__block</tt> variable scope</a></li>
  37     </ul>
  38   </li>
  39   <li><a href="#objective-c">Objective-C compatibility</a>
  40     <ul>
  41       <li><a href="#super-cast">Cast of super</a></li>
  42       <li><a href="#sizeof-interface">Size of interfaces</a></li>
  43     </ul>
  44   </li>
  45   <li><a href="#c++">C++ compatibility</a>
  46     <ul>
  47       <li><a href="#vla">Variable-length arrays</a></li>
  48       <li><a href="#init_static_const">Initialization of non-integral static const data members within a class definition</a></li>
  49       <li><a href="#dep_lookup">Unqualified lookup in templates</a></li>
  50       <li><a href="#dep_lookup_bases">Unqualified lookup into dependent bases of class templates</a></li>
  51       <li><a href="#undep_incomplete">Incomplete types in templates</a></li>
  52       <li><a href="#bad_templates">Templates with no valid instantiations</a></li>
  53       <li><a href="#default_init_const">Default initialization of const
  54       variable of a class type requires user-defined default
  55       constructor</a></li>
  56     </ul>
  57   </li>
  58   <li><a href="#objective-c++">Objective-C++ compatibility</a>
  59     <ul>
  60       <li><a href="#implicit-downcasts">Implicit downcasts</a></li>
  61     </ul>
  62     <ul>
  63       <li><a href="#Use of class as method name">Use of class as method name</a></li>
  64     </ul>
  65   </li>
  66 </ul>
  67
  68 <!-- ======================================================================= -->
  69 <h2 id="c">C compatibility</h3>
  70 <!-- ======================================================================= -->
  71
  72 <!-- ======================================================================= -->
  73 <h3 id="inline">C99 inline functions</h3>
  74 <!-- ======================================================================= -->
  75 <p>By default, Clang builds C code according to the C99 standard,
  76 which provides different inlining semantics than GCC's default
  77 behavior. For example, when compiling the following code with no optimization:</p>
  78 <pre>
  79 inline int add(int i, int j) { return i + j; }
  80
  81 int main() {
  82   int i = add(4, 5);
  83   return i;
  84 }
  85 </pre>
  86
  87 <p>In C99, this is an incomplete (incorrect) program because there is
  88 no external definition of the <code>add</code> function: the inline
  89 definition is only used for optimization, if the compiler decides to
  90 perform inlining. Therefore, we will get a (correct) link-time error
  91 with Clang, e.g.:</p>
  92
  93 <pre>
  94 Undefined symbols:
  95   "_add", referenced from:
  96       _main in cc-y1jXIr.o
  97 </pre>
  98
  99 <p>There are several ways to fix this problem:</p>
 100
 101 <ul>
 102   <li>Change <code>add</code> to a <code>static inline</code>
 103   function. Static inline functions are always resolved within the
 104   translation unit, so you won't have to add an external, non-inline
 105   definition of the function elsewhere in your program.</li>
 106
 107   <li>Provide an external (non-inline) definition of <code>add</code>
 108   somewhere in your program.</li>
 109
 110   <li>Compile with the GNU89 dialect by adding
 111   <code>-std=gnu89</code> to the set of Clang options. This option is
 112   only recommended if the program source cannot be changed or if the
 113   program also relies on additional C89-specific behavior that cannot
 114   be changed.</li>
 115 </ul>
 116
 117 <!-- ======================================================================= -->
 118 <h3 id="lvalue-cast">Lvalue casts</h3>
 119 <!-- ======================================================================= -->
 120
 121 <p>Old versions of GCC permit casting the left-hand side of an assignment to a
 122 different type. Clang produces an error on similar code, e.g.,</p>
 123
 124 <pre>
 125 lvalue.c:2:3: error: assignment to cast is illegal, lvalue casts are not
 126       supported
 127   (int*)addr = val;
 128   ^~~~~~~~~~ ~
 129 </pre>
 130
 131 <p>To fix this problem, move the cast to the right-hand side. In this
 132 example, one could use:</p>
 133
 134 <pre>
 135   addr = (float *)val;
 136 </pre>
 137
 138 <!-- ======================================================================= -->
 139 <h3 id="blocks-in-protected-scope">Jumps to within <tt>__block</tt> variable scope</h3>
 140 <!-- ======================================================================= -->
 141
 142 <p>Clang disallows jumps into the scope of a <tt>__block</tt> variable, similar
 143 to the manner in which both GCC and Clang disallow jumps into the scope of
 144 variables which have user defined constructors (in C++).</p>
 145
 146 <p>Variables marked with <tt>__block</tt> require special runtime initialization
 147 before they can be used. A jump into the scope of a <tt>__block</tt> variable
 148 would bypass this initialization and therefore the variable cannot safely be
 149 used.</p>
 150
 151 <p>For example, consider the following code fragment:</p>
 152
 153 <pre>
 154 int f0(int c) {
 155   if (c)
 156     goto error;
 157
 158   __block int x;
 159   x = 1;
 160   return x;
 161
 162  error:
 163   x = 0;
 164   return x;
 165 }
 166 </pre>
 167
 168 <p>GCC accepts this code, but it will crash at runtime along the error path,
 169 because the runtime setup for the storage backing the <tt>x</tt> variable will
 170 not have been initialized. Clang rejects this code with a hard error:</p>
 171
 172 <pre>
 173 t.c:3:5: error: goto into protected scope
 174     goto error;
 175     ^
 176 t.c:5:15: note: jump bypasses setup of __block variable
 177   __block int x;
 178               ^
 179 </pre>
 180
 181 <p>Some instances of this construct may be safe if the variable is never used
 182 after the jump target, however the protected scope checker does not check the
 183 uses of the variable, only the scopes in which it is visible. You should rewrite
 184 your code to put the <tt>__block</tt> variables in a scope which is only visible
 185 where they are used.</p>
 186
 187 <!-- ======================================================================= -->
 188 <h2 id="objective-c">Objective-C compatibility</h3>
 189 <!-- ======================================================================= -->
 190
 191 <!-- ======================================================================= -->
 192 <h3 id="super-cast">Cast of super</h3>
 193 <!-- ======================================================================= -->
 194
 195 <p>GCC treats the <code>super</code> identifier as an expression that
 196 can, among other things, be cast to a different type. Clang treats
 197 <code>super</code> as a context-sensitive keyword, and will reject a
 198 type-cast of <code>super</code>:</p>
 199
 200 <pre>
 201 super.m:11:12: error: cannot cast 'super' (it isn't an expression)
 202   [(Super*)super add:4];
 203    ~~~~~~~~^
 204 </pre>
 205
 206 <p>To fix this problem, remove the type cast, e.g.</p>
 207 <pre>
 208   [super add:4];
 209 </pre>
 210
 211 <!-- ======================================================================= -->
 212 <h3 id="sizeof-interface">Size of interfaces</h3>
 213 <!-- ======================================================================= -->
 214
 215 <p>When using the "non-fragile" Objective-C ABI in use, the size of an
 216 Objective-C class may change over time as instance variables are added
 217 (or removed). For this reason, Clang rejects the application of the
 218 <code>sizeof</code> operator to an Objective-C class when using this
 219 ABI:</p>
 220
 221 <pre>
 222 sizeof.m:4:14: error: invalid application of 'sizeof' to interface 'NSArray' in
 223       non-fragile ABI
 224   int size = sizeof(NSArray);
 225              ^     ~~~~~~~~~
 226 </pre>
 227
 228 <p>Code that relies on the size of an Objective-C class is likely to
 229 be broken anyway, since that size is not actually constant. To address
 230 this problem, use the Objective-C runtime API function
 231 <code>class_getInstanceSize()</code>:</p>
 232
 233 <pre>
 234   class_getInstanceSize([NSArray class])
 235 </pre>
 236
 237 <!-- ======================================================================= -->
 238 <h2 id="c++">C++ compatibility</h3>
 239 <!-- ======================================================================= -->
 240
 241 <!-- ======================================================================= -->
 242 <h3 id="vla">Variable-length arrays</h3>
 243 <!-- ======================================================================= -->
 244
 245 <p>GCC and C99 allow an array's size to be determined at run
 246 time. This extension is not permitted in standard C++. However, Clang
 247 supports such variable length arrays in very limited circumstances for
 248 compatibility with GNU C and C99 programs:</p>
 249
 250 <ul>
 251   <li>The element type of a variable length array must be a POD
 252   ("plain old data") type, which means that it cannot have any
 253   user-declared constructors or destructors, base classes, or any
 254   members if non-POD type. All C types are POD types.</li>
 255
 256   <li>Variable length arrays cannot be used as the type of a non-type
 257 template parameter.</li> </ul>
 258
 259 <p>If your code uses variable length arrays in a manner that Clang doesn't support, there are several ways to fix your code:
 260
 261 <ol>
 262 <li>replace the variable length array with a fixed-size array if you can
 263     determine a
 264     reasonable upper bound at compile time; sometimes this is as
 265     simple as changing <tt>int size = ...;</tt> to <tt>const int size
 266     = ...;</tt> (if the definition of <tt>size</tt> is a compile-time
 267     integral constant);</li>
 268 <li>use an <tt>std::string</tt> instead of a <tt>char []</tt>;</li>
 269 <li>use <tt>std::vector</tt> or some other suitable container type;
 270     or</li>
 271 <li>allocate the array on the heap instead using <tt>new Type[]</tt> -
 272     just remember to <tt>delete[]</tt> it.</li>
 273 </ol>
 274
 275 <!-- ======================================================================= -->
 276 <h3 id="init_static_const">Initialization of non-integral static const data members within a class definition</h3>
 277 <!-- ======================================================================= -->
 278
 279 The following code is ill-formed in C++'03:
 280
 281 <pre>
 282 class SomeClass {
 283  public:
 284   static const double SomeConstant = 0.5;
 285 };
 286
 287 const double SomeClass::SomeConstant;
 288 </pre>
 289
 290 Clang errors with something similar to:
 291
 292 <pre>
 293 .../your_file.h:42:42: error: 'SomeConstant' can only be initialized if it is a static const integral data member
 294   static const double SomeConstant = 0.5;
 295                       ^              ~~~
 296 </pre>
 297
 298 Only <i>integral</i> constant expressions are allowed as initializers
 299 within the class definition. See C++'03 [class.static.data] p4 for the
 300 details of this restriction.  The fix here is straightforward: move
 301 the initializer to the definition of the static data member, which
 302 must exist outside of the class definition:
 303
 304 <pre>
 305 class SomeClass {
 306  public:
 307   static const double SomeConstant;
 308 };
 309
 310 const double SomeClass::SomeConstant<b> = 0.5</b>;
 311 </pre>
 312
 313 Note that the forthcoming C++0x standard will allow this.
 314
 315 <!-- ======================================================================= -->
 316 <h3 id="dep_lookup">Unqualified lookup in templates</h3>
 317 <!-- ======================================================================= -->
 318
 319 <p>Some versions of GCC accept the following invalid code:
 320
 321 <pre>
 322 template &lt;typename T&gt; T Squared(T x) {
 323   return Multiply(x, x);
 324 }
 325
 326 int Multiply(int x, int y) {
 327   return x * y;
 328 }
 329
 330 int main() {
 331   Squared(5);
 332 }
 333 </pre>
 334
 335 <p>Clang complains:
 336
 337 <pre>  <b>my_file.cpp:2:10: <span class="error">error:</span> use of undeclared identifier 'Multiply'</b>
 338     return Multiply(x, x);
 339   <span class="caret">         ^</span>
 340
 341   <b>my_file.cpp:10:3: <span class="note">note:</span> in instantiation of function template specialization 'Squared&lt;int&gt;' requested here</b>
 342     Squared(5);
 343   <span class="caret">  ^</span>
 344 </pre>
 345
 346 <p>The C++ standard says that unqualified names like <q>Multiply</q>
 347 are looked up in two ways.
 348
 349 <p>First, the compiler does <i>unqualified lookup</i> in the scope
 350 where the name was written.  For a template, this means the lookup is
 351 done at the point where the template is defined, not where it's
 352 instantiated.  Since <tt>Multiply</tt> hasn't been declared yet at
 353 this point, unqualified lookup won't find it.
 354
 355 <p>Second, if the name is called like a function, then the compiler
 356 also does <i>argument-dependent lookup</i> (ADL).  (Sometimes
 357 unqualified lookup can suppress ADL; see [basic.lookup.argdep]p3 for
 358 more information.)  In ADL, the compiler looks at the types of all the
 359 arguments to the call.  When it finds a class type, it looks up the
 360 name in that class's namespace; the result is all the declarations it
 361 finds in those namespaces, plus the declarations from unqualified
 362 lookup.  However, the compiler doesn't do ADL until it knows all the
 363 argument types.
 364
 365 <p>In our example, <tt>Multiply</tt> is called with dependent
 366 arguments, so ADL isn't done until the template is instantiated.  At
 367 that point, the arguments both have type <tt>int</tt>, which doesn't
 368 contain any class types, and so ADL doesn't look in any namespaces.
 369 Since neither form of lookup found the declaration
 370 of <tt>Multiply</tt>, the code doesn't compile.
 371
 372 <p>Here's another example, this time using overloaded operators,
 373 which obey very similar rules.
 374
 375 <pre>#include &lt;iostream&gt;
 376
 377 template&lt;typename T&gt;
 378 void Dump(const T&amp; value) {
 379   std::cout &lt;&lt; value &lt;&lt; "\n";
 380 }
 381
 382 namespace ns {
 383   struct Data {};
 384 }
 385
 386 std::ostream&amp; operator&lt;&lt;(std::ostream&amp; out, ns::Data data) {
 387   return out &lt;&lt; "Some data";
 388 }
 389
 390 void Use() {
 391   Dump(ns::Data());
 392 }</pre>
 393
 394 <p>Again, Clang complains about not finding a matching function:</p>
 395
 396 <pre>
 397 <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>
 398   std::cout &lt;&lt; value &lt;&lt; "\n";
 399   <span class="caret">~~~~~~~~~ ^  ~~~~~</span>
 400 <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>
 401   Dump(ns::Data());
 402   <span class="caret">^</span>
 403 </pre>
 404
 405 <p>Just like before, unqualified lookup didn't find any declarations
 406 with the name <tt>operator&lt;&lt;</tt>.  Unlike before, the argument
 407 types both contain class types: one of them is an instance of the
 408 class template type <tt>std::basic_ostream</tt>, and the other is the
 409 type <tt>ns::Data</tt> that we declared above.  Therefore, ADL will
 410 look in the namespaces <tt>std</tt> and <tt>ns</tt> for
 411 an <tt>operator&lt;&lt;</tt>.  Since one of the argument types was
 412 still dependent during the template definition, ADL isn't done until
 413 the template is instantiated during <tt>Use</tt>, which means that
 414 the <tt>operator&lt;&lt;</tt> we want it to find has already been
 415 declared.  Unfortunately, it was declared in the global namespace, not
 416 in either of the namespaces that ADL will look in!
 417
 418 <p>There are two ways to fix this problem:</p>
 419 <ol><li>Make sure the function you want to call is declared before the
 420 template that might call it.  This is the only option if none of its
 421 argument types contain classes.  You can do this either by moving the
 422 template definition, or by moving the function definition, or by
 423 adding a forward declaration of the function before the template.</li>
 424 <li>Move the function into the same namespace as one of its arguments
 425 so that ADL applies.</li></ol>
 426
 427 <p>For more information about argument-dependent lookup, see
 428 [basic.lookup.argdep].  For more information about the ordering of
 429 lookup in templates, see [temp.dep.candidate].
 430
 431 <!-- ======================================================================= -->
 432 <h3 id="dep_lookup_bases">Unqualified lookup into dependent bases of class templates</h3>
 433 <!-- ======================================================================= -->
 434
 435 Some versions of GCC accept the following invalid code:
 436
 437 <pre>
 438 template &lt;typename T&gt; struct Base {
 439   void DoThis(T x) {}
 440   static void DoThat(T x) {}
 441 };
 442
 443 template &lt;typename T&gt; struct Derived : public Base&lt;T&gt; {
 444   void Work(T x) {
 445     DoThis(x);  // Invalid!
 446     DoThat(x);  // Invalid!
 447   }
 448 };
 449 </pre>
 450
 451 Clang correctly rejects it with the following errors
 452 (when <tt>Derived</tt> is eventually instantiated):
 453
 454 <pre>
 455 my_file.cpp:8:5: error: use of undeclared identifier 'DoThis'
 456     DoThis(x);
 457     ^
 458     this-&gt;
 459 my_file.cpp:2:8: note: must qualify identifier to find this declaration in dependent base class
 460   void DoThis(T x) {}
 461        ^
 462 my_file.cpp:9:5: error: use of undeclared identifier 'DoThat'
 463     DoThat(x);
 464     ^
 465     this-&gt;
 466 my_file.cpp:3:15: note: must qualify identifier to find this declaration in dependent base class
 467   static void DoThat(T x) {}
 468 </pre>
 469
 470 Like we said <a href="#dep_lookup">above</a>, unqualified names like
 471 <tt>DoThis</tt> and <tt>DoThat</tt> are looked up when the template
 472 <tt>Derived</tt> is defined, not when it's instantiated.  When we look
 473 up a name used in a class, we usually look into the base classes.
 474 However, we can't look into the base class <tt>Base&lt;T&gt;</tt>
 475 because its type depends on the template argument <tt>T</tt>, so the
 476 standard says we should just ignore it.  See [temp.dep]p3 for details.
 477
 478 <p>The fix, as Clang tells you, is to tell the compiler that we want a
 479 class member by prefixing the calls with <tt>this-&gt;</tt>:
 480
 481 <pre>
 482   void Work(T x) {
 483     <b>this-&gt;</b>DoThis(x);
 484     <b>this-&gt;</b>DoThat(x);
 485   }
 486 </pre>
 487
 488 Alternatively, you can tell the compiler exactly where to look:
 489
 490 <pre>
 491   void Work(T x) {
 492     <b>Base&lt;T&gt;</b>::DoThis(x);
 493     <b>Base&lt;T&gt;</b>::DoThat(x);
 494   }
 495 </pre>
 496
 497 This works whether the methods are static or not, but be careful:
 498 if <tt>DoThis</tt> is virtual, calling it this way will bypass virtual
 499 dispatch!
 500
 501 <!-- ======================================================================= -->
 502 <h3 id="undep_incomplete">Incomplete types in templates</h3>
 503 <!-- ======================================================================= -->
 504
 505 The following code is invalid, but compilers are allowed to accept it:
 506
 507 <pre>
 508   class IOOptions;
 509   template &lt;class T&gt; bool read(T &amp;value) {
 510     IOOptions opts;
 511     return read(opts, value);
 512   }
 513
 514   class IOOptions { bool ForceReads; };
 515   bool read(const IOOptions &amp;opts, int &amp;x);
 516   template bool read&lt;&gt;(int &amp;);
 517 </pre>
 518
 519 The standard says that types which don't depend on template parameters
 520 must be complete when a template is defined if they affect the
 521 program's behavior.  However, the standard also says that compilers
 522 are free to not enforce this rule.  Most compilers enforce it to some
 523 extent; for example, it would be an error in GCC to
 524 write <tt>opts.ForceReads</tt> in the code above.  In Clang, we feel
 525 that enforcing the rule consistently lets us provide a better
 526 experience, but unfortunately it also means we reject some code that
 527 other compilers accept.
 528
 529 <p>We've explained the rule here in very imprecise terms; see
 530 [temp.res]p8 for details.
 531
 532 <!-- ======================================================================= -->
 533 <h3 id="bad_templates">Templates with no valid instantiations</h3>
 534 <!-- ======================================================================= -->
 535
 536 The following code contains a typo: the programmer
 537 meant <tt>init()</tt> but wrote <tt>innit()</tt> instead.
 538
 539 <pre>
 540   template &lt;class T&gt; class Processor {
 541     ...
 542     void init();
 543     ...
 544   };
 545   ...
 546   template &lt;class T&gt; void process() {
 547     Processor&lt;T&gt; processor;
 548     processor.innit();       // <-- should be 'init()'
 549     ...
 550   }
 551 </pre>
 552
 553 Unfortunately, we can't flag this mistake as soon as we see it: inside
 554 a template, we're not allowed to make assumptions about "dependent
 555 types" like <tt>Processor&lt;T&gt;</tt>.  Suppose that later on in
 556 this file the programmer adds an explicit specialization
 557 of <tt>Processor</tt>, like so:
 558
 559 <pre>
 560   template &lt;&gt; class Processor&lt;char*&gt; {
 561     void innit();
 562   };
 563 </pre>
 564
 565 Now the program will work &mdash; as long as the programmer only ever
 566 instantiates <tt>process()</tt> with <tt>T = char*</tt>!  This is why
 567 it's hard, and sometimes impossible, to diagnose mistakes in a
 568 template definition before it's instantiated.
 569
 570 <p>The standard says that a template with no valid instantiations is
 571 ill-formed.  Clang tries to do as much checking as possible at
 572 definition-time instead of instantiation-time: not only does this
 573 produce clearer diagnostics, but it also substantially improves
 574 compile times when using pre-compiled headers.  The downside to this
 575 philosophy is that Clang sometimes fails to process files because they
 576 contain broken templates that are no longer used.  The solution is
 577 simple: since the code is unused, just remove it.
 578
 579 <!-- ======================================================================= -->
 580 <h3 id="default_init_const">Default initialization of const variable of a class type requires user-defined default constructor</h3>
 581 <!-- ======================================================================= -->
 582
 583 If a <tt>class</tt> or <tt>struct</tt> has no user-defined default
 584 constructor, C++ doesn't allow you to default construct a <tt>const</tt>
 585 instance of it like this ([dcl.init], p9):
 586
 587 <pre>
 588 class Foo {
 589  public:
 590   // The compiler-supplied default constructor works fine, so we
 591   // don't bother with defining one.
 592   ...
 593 };
 594
 595 void Bar() {
 596   const Foo foo;  // Error!
 597   ...
 598 }
 599 </pre>
 600
 601 To fix this, you can define a default constructor for the class:
 602
 603 <pre>
 604 class Foo {
 605  public:
 606   Foo() {}
 607   ...
 608 };
 609
 610 void Bar() {
 611   const Foo foo;  // Now the compiler is happy.
 612   ...
 613 }
 614 </pre>
 615
 616 <!-- ======================================================================= -->
 617 <h2 id="objective-c++">Objective-C++ compatibility</h3>
 618 <!-- ======================================================================= -->
 619
 620 <!-- ======================================================================= -->
 621 <h3 id="implicit-downcasts">Implicit downcasts</h3>
 622 <!-- ======================================================================= -->
 623
 624 <p>Due to a bug in its implementation, GCC allows implicit downcasts
 625 (from base class to a derived class) when calling functions. Such code is
 626 inherently unsafe, since the object might not actually be an instance
 627 of the derived class, and is rejected by Clang. For example, given
 628 this code:</p>
 629
 630 <pre>
 631 @interface Base @end
 632 @interface Derived : Base @end
 633
 634 void f(Derived *);
 635 void g(Base *base) {
 636   f(base);
 637 }
 638 </pre>
 639
 640 <p>Clang produces the following error:</p>
 641
 642 <pre>
 643 downcast.mm:6:3: error: no matching function for call to 'f'
 644   f(base);
 645   ^
 646 downcast.mm:4:6: note: candidate function not viable: cannot convert from
 647       superclass 'Base *' to subclass 'Derived *' for 1st argument
 648 void f(Derived *);
 649      ^
 650 </pre>
 651
 652 <p>If the downcast is actually correct (e.g., because the code has
 653 already checked that the object has the appropriate type), add an
 654 explicit cast:</p>
 655
 656 <pre>
 657   f((Derived *)base);
 658 </pre>
 659
 660 <!-- ======================================================================= -->
 661 <h3 id="Use of class as method name">Use of class as method name</h3>
 662 <!-- ======================================================================= -->
 663
 664 <p>Use of 'class' name to declare a method is allowed in objective-c++ mode to
 665 be compatible with GCC. However, use of property dot syntax notation to call
 666 this method is not allowed in clang++, as [I class] is a suitable syntax that
 667 will work. So, this test will fail in clang++.
 668
 669 <pre>
 670 @interface I {
 671 int cls;
 672 }
 673 + (int)class;
 674 @end
 675
 676 @implementation  I
 677 - (int) Meth { return I.class; }
 678 @end
 679 <pre>
 680
 681
 682 </div>
 683 </body>
 684 </html>