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