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