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