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