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