blob: 512beaa042714b67b060162e38f22821b9448779 [file] [log] [blame]
Douglas Gregorc41b6ff2010-06-30 22:01:08 +00001<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
3<html>
4<head>
Benjamin Kramer665a8dc2012-01-15 15:26:07 +00005 <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
Douglas Gregorc41b6ff2010-06-30 22:01:08 +00006 <title>Language Compatibility</title>
Benjamin Kramer665a8dc2012-01-15 15:26:07 +00007 <link type="text/css" rel="stylesheet" href="menu.css">
8 <link type="text/css" rel="stylesheet" href="content.css">
Douglas Gregorc41b6ff2010-06-30 22:01:08 +00009 <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
Richard Smith11fd5b12013-03-10 00:11:00 +000022<p>Clang strives to both conform to current language standards (up to C11
23 and C++11) and also to implement many widely-used extensions available
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000024 in other compilers, so that most correct code will "just work" when
Richard Smith11fd5b12013-03-10 00:11:00 +000025 compiled with Clang. However, Clang is more strict than other
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000026 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 +000035 <li><a href="#vector_builtins">"missing" vector __builtin functions</a></li>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000036 <li><a href="#lvalue-cast">Lvalue casts</a></li>
Daniel Dunbar5a410212010-09-02 21:35:16 +000037 <li><a href="#blocks-in-protected-scope">Jumps to within <tt>__block</tt> variable scope</a></li>
Daniel Dunbar15952c92010-11-09 22:45:16 +000038 <li><a href="#block-variable-initialization">Non-initialization of <tt>__block</tt> variables</a></li>
Chris Lattner9b743f42010-11-10 23:51:50 +000039 <li><a href="#inline-asm">Inline assembly</a></li>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000040 </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 +000046 <li><a href="#objc_objs-cast">Internal Objective-C types</a></li>
Fariborz Jahanianddfa6c32010-10-22 22:35:51 +000047 <li><a href="#c_variables-class">C variables in @class or @protocol</a></li>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000048 </ul>
49 </li>
Benjamin Kramer665a8dc2012-01-15 15:26:07 +000050 <li><a href="#cxx">C++ compatibility</a>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000051 <ul>
52 <li><a href="#vla">Variable-length arrays</a></li>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000053 <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 +000060 <li><a href="#param_name_lookup">Parameter name lookup</a></li>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000061 </ul>
62 </li>
Benjamin Kramer665a8dc2012-01-15 15:26:07 +000063 <li><a href="#cxx11">C++11 compatibility</a>
Douglas Gregorfb2a0c52011-09-27 18:58:27 +000064 <ul>
65 <li><a href="#deleted-special-func">Deleted special member
66 functions</a></li>
67 </ul>
68 </li>
Benjamin Kramer665a8dc2012-01-15 15:26:07 +000069 <li><a href="#objective-cxx">Objective-C++ compatibility</a>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000070 <ul>
71 <li><a href="#implicit-downcasts">Implicit downcasts</a></li>
72 </ul>
Fariborz Jahanian36e738a2010-08-11 18:57:26 +000073 <ul>
John McCall6966c672011-02-03 11:29:18 +000074 <li><a href="#class-as-property-name">Using <code>class</code> as a property name</a></li>
Fariborz Jahanian36e738a2010-08-11 18:57:26 +000075 </ul>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000076 </li>
77</ul>
78
79<!-- ======================================================================= -->
Benjamin Kramer665a8dc2012-01-15 15:26:07 +000080<h2 id="c">C compatibility</h2>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000081<!-- ======================================================================= -->
82
83<!-- ======================================================================= -->
84<h3 id="inline">C99 inline functions</h3>
85<!-- ======================================================================= -->
Richard Smithb2414112014-10-20 23:26:58 +000086<p>By default, Clang builds C code in GNU C11 mode, so it uses standard C99
87semantics for the <code>inline</code> keyword. These semantics are different
88from those in GNU C89 mode, which is the default mode in versions of GCC
89prior to 5.0. For example, consider the following code:</p>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +000090<pre>
91inline int add(int i, int j) { return i + j; }
92
93int main() {
94 int i = add(4, 5);
95 return i;
96}
97</pre>
98
John McCall5ae84f22011-02-03 10:16:40 +000099<p>In C99, <code>inline</code> means that a function's definition is
100provided only for inlining, and that there is another definition
101(without <code>inline</code>) somewhere else in the program. That
102means that this program is incomplete, because if <code>add</code>
103isn't inlined (for example, when compiling without optimization), then
104<code>main</code> will have an unresolved reference to that other
105definition. Therefore we'll get a (correct) link-time error like this:</p>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000106
107<pre>
108Undefined symbols:
109 "_add", referenced from:
110 _main in cc-y1jXIr.o
111</pre>
112
Richard Smithb2414112014-10-20 23:26:58 +0000113<p>By contrast, GNU C89 mode (used by default in older versions of GCC) is the
114C89 standard plus a lot of extensions. C89 doesn't have an <code>inline</code>
115keyword, but GCC recognizes it as an extension and just treats it as a hint to
116the optimizer.</p>
John McCall5ae84f22011-02-03 10:16:40 +0000117
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000118<p>There are several ways to fix this problem:</p>
119
120<ul>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000121 <li>Change <code>add</code> to a <code>static inline</code>
John McCall5ae84f22011-02-03 10:16:40 +0000122 function. This is usually the right solution if only one
123 translation unit needs to use the function. <code>static
124 inline</code> functions are always resolved within the translation
125 unit, so you won't have to add a non-<code>inline</code> definition
126 of the function elsewhere in your program.</li>
127
128 <li>Remove the <code>inline</code> keyword from this definition of
129 <code>add</code>. The <code>inline</code> keyword is not required
130 for a function to be inlined, nor does it guarantee that it will be.
131 Some compilers ignore it completely. Clang treats it as a mild
132 suggestion from the programmer.</li>
Richard Smithb2414112014-10-20 23:26:58 +0000133
John McCall5ae84f22011-02-03 10:16:40 +0000134 <li>Provide an external (non-<code>inline</code>) definition
135 of <code>add</code> somewhere else in your program. The two
136 definitions must be equivalent!</li>
137
Richard Smithb2414112014-10-20 23:26:58 +0000138 <li>Compile in the GNU C89 dialect by adding
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000139 <code>-std=gnu89</code> to the set of Clang options. This option is
140 only recommended if the program source cannot be changed or if the
141 program also relies on additional C89-specific behavior that cannot
142 be changed.</li>
143</ul>
144
John McCall5ae84f22011-02-03 10:16:40 +0000145<p>All of this only applies to C code; the meaning of <code>inline</code>
146in C++ is very different from its meaning in either GNU89 or C99.</p>
Chris Lattnera02d1832010-09-16 18:17:55 +0000147
148<!-- ======================================================================= -->
149<h3 id="vector_builtins">"missing" vector __builtin functions</h3>
150<!-- ======================================================================= -->
151
152<p>The Intel and AMD manuals document a number "<tt>&lt;*mmintrin.h&gt;</tt>"
153header files, which define a standardized API for accessing vector operations
154on X86 CPUs. These functions have names like <tt>_mm_xor_ps</tt> and
155<tt>_mm256_addsub_pd</tt>. Compilers have leeway to implement these functions
156however they want. Since Clang supports an excellent set of <a
157href="../docs/LanguageExtensions.html#vectors">native vector operations</a>,
158the Clang headers implement these interfaces in terms of the native vector
159operations.
160</p>
161
162<p>In contrast, GCC implements these functions mostly as a 1-to-1 mapping to
163builtin function calls, like <tt>__builtin_ia32_paddw128</tt>. These builtin
164functions are an internal implementation detail of GCC, and are not portable to
165the Intel compiler, the Microsoft compiler, or Clang. If you get build errors
166mentioning these, the fix is simple: switch to the *mmintrin.h functions.</p>
167
168<p>The same issue occurs for NEON and Altivec for the ARM and PowerPC
169architectures respectively. For these, make sure to use the &lt;arm_neon.h&gt;
170and &lt;altivec.h&gt; headers.</p>
171
Eric Christophera473c952010-10-25 21:17:59 +0000172<p>For x86 architectures this <a href="builtins.py">script</a> should help with
173the manual migration process. It will rewrite your source files in place to
174use the APIs instead of builtin function calls. Just call it like this:</p>
175
176<pre>
177 builtins.py *.c *.h
178</pre>
179
180<p>and it will rewrite all of the .c and .h files in the current directory to
181use the API calls instead of calls like <tt>__builtin_ia32_paddw128</tt>.</p>
Chris Lattnera02d1832010-09-16 18:17:55 +0000182
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000183<!-- ======================================================================= -->
184<h3 id="lvalue-cast">Lvalue casts</h3>
185<!-- ======================================================================= -->
186
Douglas Gregor6f1adba2010-06-30 22:38:37 +0000187<p>Old versions of GCC permit casting the left-hand side of an assignment to a
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000188different type. Clang produces an error on similar code, e.g.,</p>
189
190<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000191<b>lvalue.c:2:3: <span class="error">error:</span> assignment to cast is illegal, lvalue casts are not supported</b>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000192 (int*)addr = val;
Richard Smitha55e3ff2013-02-01 00:45:12 +0000193<span class="caret"> ^~~~~~~~~~ ~</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000194</pre>
195
196<p>To fix this problem, move the cast to the right-hand side. In this
197example, one could use:</p>
198
199<pre>
200 addr = (float *)val;
201</pre>
202
203<!-- ======================================================================= -->
Daniel Dunbar5a410212010-09-02 21:35:16 +0000204<h3 id="blocks-in-protected-scope">Jumps to within <tt>__block</tt> variable scope</h3>
205<!-- ======================================================================= -->
206
John McCall504b3692011-02-03 10:56:31 +0000207<p>Clang disallows jumps into the scope of a <tt>__block</tt>
208variable. Variables marked with <tt>__block</tt> require special
209runtime initialization. A jump into the scope of a <tt>__block</tt>
210variable bypasses this initialization, leaving the variable's metadata
211in an invalid state. Consider the following code fragment:</p>
Daniel Dunbar5a410212010-09-02 21:35:16 +0000212
213<pre>
John McCall504b3692011-02-03 10:56:31 +0000214int fetch_object_state(struct MyObject *c) {
215 if (!c->active) goto error;
Daniel Dunbar5a410212010-09-02 21:35:16 +0000216
John McCall504b3692011-02-03 10:56:31 +0000217 __block int result;
218 run_specially_somehow(^{ result = c->state; });
219 return result;
Daniel Dunbar5a410212010-09-02 21:35:16 +0000220
221 error:
John McCall504b3692011-02-03 10:56:31 +0000222 fprintf(stderr, "error while fetching object state");
223 return -1;
Daniel Dunbar5a410212010-09-02 21:35:16 +0000224}
225</pre>
226
John McCall504b3692011-02-03 10:56:31 +0000227<p>GCC accepts this code, but it produces code that will usually crash
228when <code>result</code> goes out of scope if the jump is taken. (It's
229possible for this bug to go undetected because it often won't crash if
230the stack is fresh, i.e. still zeroed.) Therefore, Clang rejects this
231code with a hard error:</p>
Daniel Dunbar5a410212010-09-02 21:35:16 +0000232
233<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000234<b>t.c:3:5: <span class="error">error:</span> goto into protected scope</b>
Daniel Dunbar5a410212010-09-02 21:35:16 +0000235 goto error;
Richard Smitha55e3ff2013-02-01 00:45:12 +0000236<span class="caret"> ^</span>
237<b>t.c:5:15: <span class="note">note:</note></b> jump bypasses setup of __block variable
John McCall504b3692011-02-03 10:56:31 +0000238 __block int result;
Richard Smitha55e3ff2013-02-01 00:45:12 +0000239<span class="caret"> ^</span>
Daniel Dunbar5a410212010-09-02 21:35:16 +0000240</pre>
241
John McCall504b3692011-02-03 10:56:31 +0000242<p>The fix is to rewrite the code to not require jumping into a
243<tt>__block</tt> variable's scope, e.g. by limiting that scope:</p>
244
245<pre>
246 {
247 __block int result;
248 run_specially_somehow(^{ result = c->state; });
249 return result;
250 }
251</pre>
Daniel Dunbar5a410212010-09-02 21:35:16 +0000252
253<!-- ======================================================================= -->
Daniel Dunbar15952c92010-11-09 22:45:16 +0000254<h3 id="block-variable-initialization">Non-initialization of <tt>__block</tt>
255variables</h3>
256<!-- ======================================================================= -->
257
258<p>In the following example code, the <tt>x</tt> variable is used before it is
259defined:</p>
260<pre>
261int f0() {
262 __block int x;
263 return ^(){ return x; }();
264}
265</pre>
266
267<p>By an accident of implementation, GCC and llvm-gcc unintentionally always
268zero initialized <tt>__block</tt> variables. However, any program which depends
269on this behavior is relying on unspecified compiler behavior. Programs must
270explicitly initialize all local block variables before they are used, as with
271other local variables.</p>
272
273<p>Clang does not zero initialize local block variables, and programs which rely
274on such behavior will most likely break when built with Clang.</p>
275
Chris Lattner9b743f42010-11-10 23:51:50 +0000276
277<!-- ======================================================================= -->
278<h3 id="inline-asm">Inline assembly</h3>
279<!-- ======================================================================= -->
280
281<p>In general, Clang is highly compatible with the GCC inline assembly
282extensions, allowing the same set of constraints, modifiers and operands as GCC
283inline assembly.</p>
284
285<p>On targets that use the integrated assembler (such as most X86 targets),
286inline assembly is run through the integrated assembler instead of your system
287assembler (which is most commonly "gas", the GNU assembler). The LLVM
288integrated assembler is extremely compatible with GAS, but there are a couple of
289minor places where it is more picky, particularly due to outright GAS bugs.</p>
290
291<p>One specific example is that the assembler rejects ambiguous X86 instructions
292that don't have suffixes. For example:</p>
293
294<pre>
295 asm("add %al, (%rax)");
296 asm("addw $4, (%rax)");
297 asm("add $4, (%rax)");
298</pre>
299
300<p>Both clang and GAS accept the first instruction: because the first
301instruction uses the 8-bit <tt>%al</tt> register as an operand, it is clear that
302it is an 8-bit add. The second instruction is accepted by both because the "w"
303suffix indicates that it is a 16-bit add. The last instruction is accepted by
304GAS even though there is nothing that specifies the size of the instruction (and
305the assembler randomly picks a 32-bit add). Because it is ambiguous, Clang
306rejects the instruction with this error message:
307</p>
308
309<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000310<b>&lt;inline asm&gt;:3:1: <span class="error">error:</span> ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq')</b>
Chris Lattner9b743f42010-11-10 23:51:50 +0000311add $4, (%rax)
Richard Smitha55e3ff2013-02-01 00:45:12 +0000312<span class="caret">^</span>
Chris Lattner9b743f42010-11-10 23:51:50 +0000313</pre>
314
315<p>To fix this compatibility issue, add an explicit suffix to the instruction:
316this makes your code more clear and is compatible with both GCC and Clang.</p>
317
Daniel Dunbar15952c92010-11-09 22:45:16 +0000318<!-- ======================================================================= -->
Benjamin Kramer665a8dc2012-01-15 15:26:07 +0000319<h2 id="objective-c">Objective-C compatibility</h2>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000320<!-- ======================================================================= -->
321
322<!-- ======================================================================= -->
323<h3 id="super-cast">Cast of super</h3>
324<!-- ======================================================================= -->
325
326<p>GCC treats the <code>super</code> identifier as an expression that
327can, among other things, be cast to a different type. Clang treats
328<code>super</code> as a context-sensitive keyword, and will reject a
329type-cast of <code>super</code>:</p>
330
331<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000332<b>super.m:11:12: <span class="error">error:</span> cannot cast 'super' (it isn't an expression)</b>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000333 [(Super*)super add:4];
Richard Smitha55e3ff2013-02-01 00:45:12 +0000334<span class="caret"> ~~~~~~~~^</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000335</pre>
336
337<p>To fix this problem, remove the type cast, e.g.</p>
338<pre>
339 [super add:4];
340</pre>
341
342<!-- ======================================================================= -->
343<h3 id="sizeof-interface">Size of interfaces</h3>
344<!-- ======================================================================= -->
345
346<p>When using the "non-fragile" Objective-C ABI in use, the size of an
347Objective-C class may change over time as instance variables are added
348(or removed). For this reason, Clang rejects the application of the
349<code>sizeof</code> operator to an Objective-C class when using this
350ABI:</p>
351
352<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000353<b>sizeof.m:4:14: <span class="error">error:</span> invalid application of 'sizeof' to interface 'NSArray' in non-fragile ABI</b>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000354 int size = sizeof(NSArray);
Richard Smitha55e3ff2013-02-01 00:45:12 +0000355<span class="caret"> ^ ~~~~~~~~~</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000356</pre>
357
358<p>Code that relies on the size of an Objective-C class is likely to
359be broken anyway, since that size is not actually constant. To address
360this problem, use the Objective-C runtime API function
Benjamin Kramere6617502010-06-30 22:29:56 +0000361<code>class_getInstanceSize()</code>:</p>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000362
363<pre>
364 class_getInstanceSize([NSArray class])
365</pre>
366
367<!-- ======================================================================= -->
Argyrios Kyrtzidis3b5b92a2010-09-13 17:48:07 +0000368<h3 id="objc_objs-cast">Internal Objective-C types</h3>
369<!-- ======================================================================= -->
370
371<p>GCC allows using pointers to internal Objective-C objects, <tt>struct objc_object*</tt>,
372<tt>struct objc_selector*</tt>, and <tt>struct objc_class*</tt> in place of the types
373<tt>id</tt>, <tt>SEL</tt>, and <tt>Class</tt> respectively. Clang treats the
374internal Objective-C structures as implementation detail and won't do implicit conversions:
375
376<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000377<b>t.mm:11:2: <span class="error">error:</span> no matching function for call to 'f'</b>
Argyrios Kyrtzidis3b5b92a2010-09-13 17:48:07 +0000378 f((struct objc_object *)p);
Richard Smitha55e3ff2013-02-01 00:45:12 +0000379<span class="caret"> ^</span>
380<b>t.mm:5:6: <span class="note">note:</note></b> candidate function not viable: no known conversion from 'struct objc_object *' to 'id' for 1st argument
Argyrios Kyrtzidis3b5b92a2010-09-13 17:48:07 +0000381void f(id x);
Richard Smitha55e3ff2013-02-01 00:45:12 +0000382<span class="caret"> ^</span>
Argyrios Kyrtzidis3b5b92a2010-09-13 17:48:07 +0000383</pre>
384
385<p>Code should use types <tt>id</tt>, <tt>SEL</tt>, and <tt>Class</tt>
386instead of the internal types.</p>
387
388<!-- ======================================================================= -->
John McCall3cdbe442011-02-03 11:05:04 +0000389<h3 id="c_variables-class">C variables in @interface or @protocol</h3>
Fariborz Jahanianddfa6c32010-10-22 22:35:51 +0000390<!-- ======================================================================= -->
391
John McCall3cdbe442011-02-03 11:05:04 +0000392<p>GCC allows the declaration of C variables in
393an <code>@interface</code> or <code>@protocol</code>
394declaration. Clang does not allow variable declarations to appear
395within these declarations unless they are marked <code>extern</code>.</p>
396
397<p>Variables may still be declared in an @implementation.</p>
Fariborz Jahanianddfa6c32010-10-22 22:35:51 +0000398
399<pre>
400@interface XX
John McCall3cdbe442011-02-03 11:05:04 +0000401int a; // not allowed in clang
402int b = 1; // not allowed in clang
403extern int c; // allowed
Fariborz Jahanianddfa6c32010-10-22 22:35:51 +0000404@end
405
406</pre>
407
408<!-- ======================================================================= -->
Benjamin Kramer665a8dc2012-01-15 15:26:07 +0000409<h2 id="cxx">C++ compatibility</h2>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000410<!-- ======================================================================= -->
411
412<!-- ======================================================================= -->
413<h3 id="vla">Variable-length arrays</h3>
414<!-- ======================================================================= -->
415
416<p>GCC and C99 allow an array's size to be determined at run
417time. This extension is not permitted in standard C++. However, Clang
Richard Smith245f8082016-05-05 02:53:55 +0000418supports such variable length arrays for compatibility with GNU C and
419C99 programs.</p>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000420
Richard Smith245f8082016-05-05 02:53:55 +0000421<p>If you would prefer not to use this extension, you can disable it with
422<tt>-Werror=vla</tt>. There are several ways to fix your code:
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000423
424<ol>
425<li>replace the variable length array with a fixed-size array if you can
John McCall6966c672011-02-03 11:29:18 +0000426 determine a reasonable upper bound at compile time; sometimes this is as
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000427 simple as changing <tt>int size = ...;</tt> to <tt>const int size
John McCall6966c672011-02-03 11:29:18 +0000428 = ...;</tt> (if the initializer is a compile-time constant);</li>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000429<li>use <tt>std::vector</tt> or some other suitable container type;
430 or</li>
431<li>allocate the array on the heap instead using <tt>new Type[]</tt> -
432 just remember to <tt>delete[]</tt> it.</li>
433</ol>
434
435<!-- ======================================================================= -->
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000436<h3 id="dep_lookup">Unqualified lookup in templates</h3>
437<!-- ======================================================================= -->
438
439<p>Some versions of GCC accept the following invalid code:
440
441<pre>
442template &lt;typename T&gt; T Squared(T x) {
443 return Multiply(x, x);
444}
445
446int Multiply(int x, int y) {
447 return x * y;
448}
449
450int main() {
451 Squared(5);
452}
453</pre>
454
455<p>Clang complains:
456
Richard Smitha55e3ff2013-02-01 00:45:12 +0000457<pre>
458<b>my_file.cpp:2:10: <span class="error">error:</span> call to function 'Multiply' that is neither visible in the template definition nor found by argument-dependent lookup</b>
459 return Multiply(x, x);
460<span class="caret"> ^</span>
461<b>my_file.cpp:10:3: <span class="note">note:</span></b> in instantiation of function template specialization 'Squared&lt;int&gt;' requested here
462 Squared(5);
463<span class="caret"> ^</span>
464<b>my_file.cpp:5:5: <span class="note">note:</span></b> 'Multiply' should be declared prior to the call site
465int Multiply(int x, int y) {
466<span class="caret"> ^</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000467</pre>
468
469<p>The C++ standard says that unqualified names like <q>Multiply</q>
470are looked up in two ways.
471
472<p>First, the compiler does <i>unqualified lookup</i> in the scope
473where the name was written. For a template, this means the lookup is
474done at the point where the template is defined, not where it's
475instantiated. Since <tt>Multiply</tt> hasn't been declared yet at
476this point, unqualified lookup won't find it.
477
478<p>Second, if the name is called like a function, then the compiler
479also does <i>argument-dependent lookup</i> (ADL). (Sometimes
480unqualified lookup can suppress ADL; see [basic.lookup.argdep]p3 for
481more information.) In ADL, the compiler looks at the types of all the
482arguments to the call. When it finds a class type, it looks up the
483name in that class's namespace; the result is all the declarations it
484finds in those namespaces, plus the declarations from unqualified
485lookup. However, the compiler doesn't do ADL until it knows all the
486argument types.
487
488<p>In our example, <tt>Multiply</tt> is called with dependent
489arguments, so ADL isn't done until the template is instantiated. At
490that point, the arguments both have type <tt>int</tt>, which doesn't
491contain any class types, and so ADL doesn't look in any namespaces.
492Since neither form of lookup found the declaration
493of <tt>Multiply</tt>, the code doesn't compile.
494
495<p>Here's another example, this time using overloaded operators,
496which obey very similar rules.
497
498<pre>#include &lt;iostream&gt;
499
500template&lt;typename T&gt;
501void Dump(const T&amp; value) {
502 std::cout &lt;&lt; value &lt;&lt; "\n";
503}
504
505namespace ns {
506 struct Data {};
507}
508
509std::ostream&amp; operator&lt;&lt;(std::ostream&amp; out, ns::Data data) {
510 return out &lt;&lt; "Some data";
511}
512
513void Use() {
514 Dump(ns::Data());
515}</pre>
516
Richard Smithf50e88a2011-06-05 22:42:48 +0000517<p>Again, Clang complains:</p>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000518
Richard Smitha55e3ff2013-02-01 00:45:12 +0000519<pre>
520<b>my_file2.cpp:5:13: <span class="error">error:</span> call to function 'operator&lt;&lt;' that is neither visible in the template definition nor found by argument-dependent lookup</b>
521 std::cout &lt;&lt; value &lt;&lt; "\n";
522<span class="caret"> ^</span>
523<b>my_file2.cpp:17:3: <span class="note">note:</span></b> in instantiation of function template specialization 'Dump&lt;ns::Data&gt;' requested here
524 Dump(ns::Data());
525<span class="caret"> ^</span>
526<b>my_file2.cpp:12:15: <span class="note">note:</span></b> 'operator&lt;&lt;' should be declared prior to the call site or in namespace 'ns'
527std::ostream&amp; operator&lt;&lt;(std::ostream&amp; out, ns::Data data) {
528<span class="caret"> ^</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000529</pre>
530
531<p>Just like before, unqualified lookup didn't find any declarations
532with the name <tt>operator&lt;&lt;</tt>. Unlike before, the argument
533types both contain class types: one of them is an instance of the
534class template type <tt>std::basic_ostream</tt>, and the other is the
535type <tt>ns::Data</tt> that we declared above. Therefore, ADL will
536look in the namespaces <tt>std</tt> and <tt>ns</tt> for
537an <tt>operator&lt;&lt;</tt>. Since one of the argument types was
538still dependent during the template definition, ADL isn't done until
539the template is instantiated during <tt>Use</tt>, which means that
540the <tt>operator&lt;&lt;</tt> we want it to find has already been
541declared. Unfortunately, it was declared in the global namespace, not
542in either of the namespaces that ADL will look in!
543
544<p>There are two ways to fix this problem:</p>
545<ol><li>Make sure the function you want to call is declared before the
546template that might call it. This is the only option if none of its
547argument types contain classes. You can do this either by moving the
548template definition, or by moving the function definition, or by
549adding a forward declaration of the function before the template.</li>
550<li>Move the function into the same namespace as one of its arguments
551so that ADL applies.</li></ol>
552
553<p>For more information about argument-dependent lookup, see
554[basic.lookup.argdep]. For more information about the ordering of
555lookup in templates, see [temp.dep.candidate].
556
557<!-- ======================================================================= -->
558<h3 id="dep_lookup_bases">Unqualified lookup into dependent bases of class templates</h3>
559<!-- ======================================================================= -->
560
Richard Smith245f8082016-05-05 02:53:55 +0000561<p>Some versions of GCC accept the following invalid code:
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000562
563<pre>
564template &lt;typename T&gt; struct Base {
565 void DoThis(T x) {}
566 static void DoThat(T x) {}
567};
568
569template &lt;typename T&gt; struct Derived : public Base&lt;T&gt; {
570 void Work(T x) {
571 DoThis(x); // Invalid!
572 DoThat(x); // Invalid!
573 }
574};
575</pre>
576
577Clang correctly rejects it with the following errors
578(when <tt>Derived</tt> is eventually instantiated):
579
580<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000581<b>my_file.cpp:8:5: <span class="error">error:</span> use of undeclared identifier 'DoThis'</b>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000582 DoThis(x);
Richard Smitha55e3ff2013-02-01 00:45:12 +0000583<span class="caret"> ^</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000584 this-&gt;
Richard Smitha55e3ff2013-02-01 00:45:12 +0000585<b>my_file.cpp:2:8: <span class="note">note:</note></b> must qualify identifier to find this declaration in dependent base class
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000586 void DoThis(T x) {}
Richard Smitha55e3ff2013-02-01 00:45:12 +0000587<span class="caret"> ^</span>
588<b>my_file.cpp:9:5: <span class="error">error:</span> use of undeclared identifier 'DoThat'</b>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000589 DoThat(x);
Richard Smitha55e3ff2013-02-01 00:45:12 +0000590<span class="caret"> ^</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000591 this-&gt;
Richard Smitha55e3ff2013-02-01 00:45:12 +0000592<b>my_file.cpp:3:15: <span class="note">note:</note></b> must qualify identifier to find this declaration in dependent base class
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000593 static void DoThat(T x) {}
594</pre>
595
596Like we said <a href="#dep_lookup">above</a>, unqualified names like
597<tt>DoThis</tt> and <tt>DoThat</tt> are looked up when the template
598<tt>Derived</tt> is defined, not when it's instantiated. When we look
599up a name used in a class, we usually look into the base classes.
600However, we can't look into the base class <tt>Base&lt;T&gt;</tt>
601because its type depends on the template argument <tt>T</tt>, so the
602standard says we should just ignore it. See [temp.dep]p3 for details.
603
604<p>The fix, as Clang tells you, is to tell the compiler that we want a
605class member by prefixing the calls with <tt>this-&gt;</tt>:
606
607<pre>
608 void Work(T x) {
609 <b>this-&gt;</b>DoThis(x);
610 <b>this-&gt;</b>DoThat(x);
611 }
612</pre>
613
614Alternatively, you can tell the compiler exactly where to look:
615
616<pre>
617 void Work(T x) {
618 <b>Base&lt;T&gt;</b>::DoThis(x);
619 <b>Base&lt;T&gt;</b>::DoThat(x);
620 }
621</pre>
622
623This works whether the methods are static or not, but be careful:
624if <tt>DoThis</tt> is virtual, calling it this way will bypass virtual
625dispatch!
626
627<!-- ======================================================================= -->
628<h3 id="undep_incomplete">Incomplete types in templates</h3>
629<!-- ======================================================================= -->
630
Richard Smith245f8082016-05-05 02:53:55 +0000631<p>The following code is invalid, but compilers are allowed to accept it:
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000632
633<pre>
634 class IOOptions;
635 template &lt;class T&gt; bool read(T &amp;value) {
636 IOOptions opts;
637 return read(opts, value);
638 }
639
640 class IOOptions { bool ForceReads; };
641 bool read(const IOOptions &amp;opts, int &amp;x);
642 template bool read&lt;&gt;(int &amp;);
643</pre>
644
645The standard says that types which don't depend on template parameters
646must be complete when a template is defined if they affect the
647program's behavior. However, the standard also says that compilers
648are free to not enforce this rule. Most compilers enforce it to some
649extent; for example, it would be an error in GCC to
650write <tt>opts.ForceReads</tt> in the code above. In Clang, we feel
651that enforcing the rule consistently lets us provide a better
652experience, but unfortunately it also means we reject some code that
653other compilers accept.
654
655<p>We've explained the rule here in very imprecise terms; see
656[temp.res]p8 for details.
657
658<!-- ======================================================================= -->
659<h3 id="bad_templates">Templates with no valid instantiations</h3>
660<!-- ======================================================================= -->
661
Richard Smith245f8082016-05-05 02:53:55 +0000662<p>The following code contains a typo: the programmer
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000663meant <tt>init()</tt> but wrote <tt>innit()</tt> instead.
664
665<pre>
666 template &lt;class T&gt; class Processor {
667 ...
668 void init();
669 ...
670 };
671 ...
672 template &lt;class T&gt; void process() {
673 Processor&lt;T&gt; processor;
674 processor.innit(); // <-- should be 'init()'
675 ...
676 }
677</pre>
678
679Unfortunately, we can't flag this mistake as soon as we see it: inside
680a template, we're not allowed to make assumptions about "dependent
681types" like <tt>Processor&lt;T&gt;</tt>. Suppose that later on in
682this file the programmer adds an explicit specialization
683of <tt>Processor</tt>, like so:
684
685<pre>
686 template &lt;&gt; class Processor&lt;char*&gt; {
687 void innit();
688 };
689</pre>
690
691Now the program will work &mdash; as long as the programmer only ever
692instantiates <tt>process()</tt> with <tt>T = char*</tt>! This is why
693it's hard, and sometimes impossible, to diagnose mistakes in a
694template definition before it's instantiated.
695
696<p>The standard says that a template with no valid instantiations is
697ill-formed. Clang tries to do as much checking as possible at
698definition-time instead of instantiation-time: not only does this
699produce clearer diagnostics, but it also substantially improves
700compile times when using pre-compiled headers. The downside to this
701philosophy is that Clang sometimes fails to process files because they
702contain broken templates that are no longer used. The solution is
703simple: since the code is unused, just remove it.
704
705<!-- ======================================================================= -->
706<h3 id="default_init_const">Default initialization of const variable of a class type requires user-defined default constructor</h3>
707<!-- ======================================================================= -->
708
Richard Smith245f8082016-05-05 02:53:55 +0000709<p>If a <tt>class</tt> or <tt>struct</tt> has no user-defined default
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000710constructor, C++ doesn't allow you to default construct a <tt>const</tt>
711instance of it like this ([dcl.init], p9):
712
713<pre>
714class Foo {
715 public:
716 // The compiler-supplied default constructor works fine, so we
717 // don't bother with defining one.
718 ...
719};
720
721void Bar() {
722 const Foo foo; // Error!
723 ...
724}
725</pre>
726
727To fix this, you can define a default constructor for the class:
728
729<pre>
730class Foo {
731 public:
732 Foo() {}
733 ...
734};
735
736void Bar() {
737 const Foo foo; // Now the compiler is happy.
738 ...
739}
740</pre>
741
Richard Smith245f8082016-05-05 02:53:55 +0000742An upcoming change to the C++ standard is expected to weaken this rule to only
743apply when the compiler-supplied default constructor would leave a member
744uninitialized. Clang implements the more relaxed rule in version 3.8 onwards.
745
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000746<!-- ======================================================================= -->
Douglas Gregora66d3bb2010-11-10 20:24:21 +0000747<h3 id="param_name_lookup">Parameter name lookup</h3>
748<!-- ======================================================================= -->
749
Richard Smith245f8082016-05-05 02:53:55 +0000750<p>Some versions of GCC allow the redeclaration of function parameter names within a function prototype in C++ code, e.g.</p>
Douglas Gregora66d3bb2010-11-10 20:24:21 +0000751<blockquote>
752<pre>
753void f(int a, int a);
754</pre>
755</blockquote>
756<p>Clang diagnoses this error (where the parameter name has been redeclared). To fix this problem, rename one of the parameters.</p>
757
758<!-- ======================================================================= -->
Benjamin Kramer665a8dc2012-01-15 15:26:07 +0000759<h2 id="cxx11">C++11 compatibility</h2>
Douglas Gregorfb2a0c52011-09-27 18:58:27 +0000760<!-- ======================================================================= -->
761
762<!-- ======================================================================= -->
763<h3 id="deleted-special-func">Deleted special member functions</h3>
764<!-- ======================================================================= -->
765
766<p>In C++11, the explicit declaration of a move constructor or a move
Sean Hunt04bea932011-12-29 18:40:13 +0000767assignment operator within a class deletes the implicit declaration
Douglas Gregorfb2a0c52011-09-27 18:58:27 +0000768of the copy constructor and copy assignment operator. This change came
769fairly late in the C++11 standardization process, so early
770implementations of C++11 (including Clang before 3.0, GCC before 4.7,
771and Visual Studio 2010) do not implement this rule, leading them to
772accept this ill-formed code:</p>
773
774<pre>
775struct X {
Sean Hunt04bea932011-12-29 18:40:13 +0000776 X(X&amp;&amp;); <i>// deletes implicit copy constructor:</i>
777 <i>// X(const X&amp;) = delete;</i>
Douglas Gregorfb2a0c52011-09-27 18:58:27 +0000778};
779
780void f(X x);
781void g(X x) {
Sean Hunt04bea932011-12-29 18:40:13 +0000782 f(x); <i>// error: X has a deleted copy constructor</i>
Douglas Gregorfb2a0c52011-09-27 18:58:27 +0000783}
784</pre>
785
Sean Hunt04bea932011-12-29 18:40:13 +0000786<p>This affects some early C++11 code, including Boost's popular <a
Douglas Gregorfb2a0c52011-09-27 18:58:27 +0000787href="http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm"><tt>shared_ptr</tt></a>
788up to version 1.47.0. The fix for Boost's <tt>shared_ptr</tt> is
789<a href="https://svn.boost.org/trac/boost/changeset/73202">available here</a>.</p>
790
791<!-- ======================================================================= -->
Benjamin Kramer665a8dc2012-01-15 15:26:07 +0000792<h2 id="objective-cxx">Objective-C++ compatibility</h2>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000793<!-- ======================================================================= -->
794
795<!-- ======================================================================= -->
796<h3 id="implicit-downcasts">Implicit downcasts</h3>
797<!-- ======================================================================= -->
798
799<p>Due to a bug in its implementation, GCC allows implicit downcasts
John McCall6966c672011-02-03 11:29:18 +0000800of Objective-C pointers (from a base class to a derived class) when
801calling functions. Such code is inherently unsafe, since the object
802might not actually be an instance of the derived class, and is
803rejected by Clang. For example, given this code:</p>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000804
805<pre>
806@interface Base @end
807@interface Derived : Base @end
808
John McCall6966c672011-02-03 11:29:18 +0000809void f(Derived *p);
810void g(Base *p) {
811 f(p);
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000812}
813</pre>
814
815<p>Clang produces the following error:</p>
816
817<pre>
Richard Smitha55e3ff2013-02-01 00:45:12 +0000818<b>downcast.mm:6:3: <span class="error">error:</span> no matching function for call to 'f'</b>
John McCall6966c672011-02-03 11:29:18 +0000819 f(p);
Richard Smitha55e3ff2013-02-01 00:45:12 +0000820<span class="caret"> ^</span>
821<b>downcast.mm:4:6: <span class="note">note:</note></b> candidate function not viable: cannot convert from
Douglas Gregor92bc0272010-07-01 03:50:01 +0000822 superclass 'Base *' to subclass 'Derived *' for 1st argument
John McCall6966c672011-02-03 11:29:18 +0000823void f(Derived *p);
Richard Smitha55e3ff2013-02-01 00:45:12 +0000824<span class="caret"> ^</span>
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000825</pre>
826
827<p>If the downcast is actually correct (e.g., because the code has
828already checked that the object has the appropriate type), add an
829explicit cast:</p>
830
831<pre>
832 f((Derived *)base);
833</pre>
834
Fariborz Jahanian36e738a2010-08-11 18:57:26 +0000835<!-- ======================================================================= -->
John McCall6966c672011-02-03 11:29:18 +0000836<h3 id="class-as-property-name">Using <code>class</code> as a property name</h3>
Fariborz Jahanian36e738a2010-08-11 18:57:26 +0000837<!-- ======================================================================= -->
838
John McCall6966c672011-02-03 11:29:18 +0000839<p>In C and Objective-C, <code>class</code> is a normal identifier and
840can be used to name fields, ivars, methods, and so on. In
841C++, <code>class</code> is a keyword. For compatibility with existing
842code, Clang permits <code>class</code> to be used as part of a method
843selector in Objective-C++, but this does not extend to any other part
844of the language. In particular, it is impossible to use property dot
845syntax in Objective-C++ with the property name <code>class</code>, so
846the following code will fail to parse:</p>
Fariborz Jahanian36e738a2010-08-11 18:57:26 +0000847
848<pre>
849@interface I {
850int cls;
851}
852+ (int)class;
853@end
854
855@implementation I
856- (int) Meth { return I.class; }
857@end
Benjamin Kramer665a8dc2012-01-15 15:26:07 +0000858</pre>
Fariborz Jahanian36e738a2010-08-11 18:57:26 +0000859
John McCall6966c672011-02-03 11:29:18 +0000860<p>Use explicit message-send syntax instead, i.e. <code>[I class]</code>.</p>
Fariborz Jahanian36e738a2010-08-11 18:57:26 +0000861
Douglas Gregorc41b6ff2010-06-30 22:01:08 +0000862</div>
863</body>
864</html>