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