1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
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">
14 <!--#include virtual="menu.html.incl"-->
18 <!-- ======================================================================= -->
19 <h1>Language Compatibility
</h1>
20 <!-- ======================================================================= -->
22 <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
24 in other compilers, so that most correct code will
"just work" when
25 compiled 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>
32 <li><a href=
"#c">C compatibility
</a>
34 <li><a href=
"#inline">C99 inline functions
</a></li>
35 <li><a href=
"#vector_builtins">"missing" vector __builtin functions
</a></li>
36 <li><a href=
"#lvalue-cast">Lvalue casts
</a></li>
37 <li><a href=
"#blocks-in-protected-scope">Jumps to within
<tt>__block
</tt> variable scope
</a></li>
38 <li><a href=
"#block-variable-initialization">Non-initialization of
<tt>__block
</tt> variables
</a></li>
39 <li><a href=
"#inline-asm">Inline assembly
</a></li>
42 <li><a href=
"#objective-c">Objective-C compatibility
</a>
44 <li><a href=
"#super-cast">Cast of super
</a></li>
45 <li><a href=
"#sizeof-interface">Size of interfaces
</a></li>
46 <li><a href=
"#objc_objs-cast">Internal Objective-C types
</a></li>
47 <li><a href=
"#c_variables-class">C variables in @class or @protocol
</a></li>
50 <li><a href=
"#cxx">C++ compatibility
</a>
52 <li><a href=
"#vla">Variable-length arrays
</a></li>
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
60 <li><a href=
"#param_name_lookup">Parameter name lookup
</a></li>
63 <li><a href=
"#cxx11">C++
11 compatibility
</a>
65 <li><a href=
"#deleted-special-func">Deleted special member
69 <li><a href=
"#objective-cxx">Objective-C++ compatibility
</a>
71 <li><a href=
"#implicit-downcasts">Implicit downcasts
</a></li>
74 <li><a href=
"#class-as-property-name">Using
<code>class
</code> as a property name
</a></li>
79 <!-- ======================================================================= -->
80 <h2 id=
"c">C compatibility
</h2>
81 <!-- ======================================================================= -->
83 <!-- ======================================================================= -->
84 <h3 id=
"inline">C99 inline functions
</h3>
85 <!-- ======================================================================= -->
86 <p>By default, Clang builds C code in GNU C11 mode, so it uses standard C99
87 semantics for the
<code>inline
</code> keyword. These semantics are different
88 from those in GNU C89 mode, which is the default mode in versions of GCC
89 prior to
5.0. For example, consider the following code:
</p>
91 inline int add(int i, int j) { return i + j; }
99 <p>In C99,
<code>inline
</code> means that a function's definition is
100 provided only for inlining, and that there is another definition
101 (without
<code>inline
</code>) somewhere else in the program. That
102 means that this program is incomplete, because if
<code>add
</code>
103 isn't inlined (for example, when compiling without optimization), then
104 <code>main
</code> will have an unresolved reference to that other
105 definition. Therefore we'll get a (correct) link-time error like this:
</p>
109 "_add", referenced from:
113 <p>By contrast, GNU C89 mode (used by default in older versions of GCC) is the
114 C89 standard plus a lot of extensions. C89 doesn't have an
<code>inline
</code>
115 keyword, but GCC recognizes it as an extension and just treats it as a hint to
118 <p>There are several ways to fix this problem:
</p>
121 <li>Change
<code>add
</code> to a
<code>static inline
</code>
122 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>
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>
134 <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>
138 <li>Compile in the GNU C89 dialect by adding
139 <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
145 <p>All of this only applies to C code; the meaning of
<code>inline
</code>
146 in C++ is very different from its meaning in either GNU89 or C99.
</p>
148 <!-- ======================================================================= -->
149 <h3 id=
"vector_builtins">"missing" vector __builtin functions
</h3>
150 <!-- ======================================================================= -->
152 <p>The Intel and AMD manuals document a number
"<tt><*mmintrin.h></tt>"
153 header files, which define a standardized API for accessing vector operations
154 on 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
156 however they want. Since Clang supports an excellent set of
<a
157 href=
"../docs/LanguageExtensions.html#vectors">native vector operations
</a>,
158 the Clang headers implement these interfaces in terms of the native vector
162 <p>In contrast, GCC implements these functions mostly as a
1-to-
1 mapping to
163 builtin function calls, like
<tt>__builtin_ia32_paddw128
</tt>. These builtin
164 functions are an internal implementation detail of GCC, and are not portable to
165 the Intel compiler, the Microsoft compiler, or Clang. If you get build errors
166 mentioning these, the fix is simple: switch to the *mmintrin.h functions.
</p>
168 <p>The same issue occurs for NEON and Altivec for the ARM and PowerPC
169 architectures respectively. For these, make sure to use the
<arm_neon.h
>
170 and
<altivec.h
> headers.
</p>
172 <p>For x86 architectures this
<a href=
"builtins.py">script
</a> should help with
173 the manual migration process. It will rewrite your source files in place to
174 use the APIs instead of builtin function calls. Just call it like this:
</p>
180 <p>and it will rewrite all of the .c and .h files in the current directory to
181 use the API calls instead of calls like
<tt>__builtin_ia32_paddw128
</tt>.
</p>
183 <!-- ======================================================================= -->
184 <h3 id=
"lvalue-cast">Lvalue casts
</h3>
185 <!-- ======================================================================= -->
187 <p>Old versions of GCC permit casting the left-hand side of an assignment to a
188 different type. Clang produces an error on similar code, e.g.,
</p>
191 <b>lvalue.c:
2:
3:
<span class=
"error">error:
</span> assignment to cast is illegal, lvalue casts are not supported
</b>
193 <span class=
"caret"> ^~~~~~~~~~ ~
</span>
196 <p>To fix this problem, move the cast to the right-hand side. In this
197 example, one could use:
</p>
203 <!-- ======================================================================= -->
204 <h3 id=
"blocks-in-protected-scope">Jumps to within
<tt>__block
</tt> variable scope
</h3>
205 <!-- ======================================================================= -->
207 <p>Clang disallows jumps into the scope of a
<tt>__block
</tt>
208 variable. Variables marked with
<tt>__block
</tt> require special
209 runtime initialization. A jump into the scope of a
<tt>__block
</tt>
210 variable bypasses this initialization, leaving the variable's metadata
211 in an invalid state. Consider the following code fragment:
</p>
214 int fetch_object_state(struct MyObject *c) {
215 if (!c-
>active) goto error;
218 run_specially_somehow(^{ result = c-
>state; });
222 fprintf(stderr,
"error while fetching object state");
227 <p>GCC accepts this code, but it produces code that will usually crash
228 when
<code>result
</code> goes out of scope if the jump is taken. (It's
229 possible for this bug to go undetected because it often won't crash if
230 the stack is fresh, i.e. still zeroed.) Therefore, Clang rejects this
231 code with a hard error:
</p>
234 <b>t.c:
3:
5:
<span class=
"error">error:
</span> goto into protected scope
</b>
236 <span class=
"caret"> ^
</span>
237 <b>t.c:
5:
15:
<span class=
"note">note:
</note></b> jump bypasses setup of __block variable
239 <span class=
"caret"> ^
</span>
242 <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>
248 run_specially_somehow(^{ result = c-
>state; });
253 <!-- ======================================================================= -->
254 <h3 id=
"block-variable-initialization">Non-initialization of
<tt>__block
</tt>
256 <!-- ======================================================================= -->
258 <p>In the following example code, the
<tt>x
</tt> variable is used before it is
263 return ^(){ return x; }();
267 <p>By an accident of implementation, GCC and llvm-gcc unintentionally always
268 zero initialized
<tt>__block
</tt> variables. However, any program which depends
269 on this behavior is relying on unspecified compiler behavior. Programs must
270 explicitly initialize all local block variables before they are used, as with
271 other local variables.
</p>
273 <p>Clang does not zero initialize local block variables, and programs which rely
274 on such behavior will most likely break when built with Clang.
</p>
277 <!-- ======================================================================= -->
278 <h3 id=
"inline-asm">Inline assembly
</h3>
279 <!-- ======================================================================= -->
281 <p>In general, Clang is highly compatible with the GCC inline assembly
282 extensions, allowing the same set of constraints, modifiers and operands as GCC
285 <p>On targets that use the integrated assembler (such as most X86 targets),
286 inline assembly is run through the integrated assembler instead of your system
287 assembler (which is most commonly
"gas", the GNU assembler). The LLVM
288 integrated assembler is extremely compatible with GAS, but there are a couple of
289 minor places where it is more picky, particularly due to outright GAS bugs.
</p>
291 <p>One specific example is that the assembler rejects ambiguous X86 instructions
292 that don't have suffixes. For example:
</p>
295 asm(
"add %al, (%rax)");
296 asm(
"addw $4, (%rax)");
297 asm(
"add $4, (%rax)");
300 <p>Both clang and GAS accept the first instruction: because the first
301 instruction uses the
8-bit
<tt>%al
</tt> register as an operand, it is clear that
302 it is an
8-bit add. The second instruction is accepted by both because the
"w"
303 suffix indicates that it is a
16-bit add. The last instruction is accepted by
304 GAS even though there is nothing that specifies the size of the instruction (and
305 the assembler randomly picks a
32-bit add). Because it is ambiguous, Clang
306 rejects the instruction with this error message:
310 <b><inline asm
>:
3:
1:
<span class=
"error">error:
</span> ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq')
</b>
312 <span class=
"caret">^
</span>
315 <p>To fix this compatibility issue, add an explicit suffix to the instruction:
316 this makes your code more clear and is compatible with both GCC and Clang.
</p>
318 <!-- ======================================================================= -->
319 <h2 id=
"objective-c">Objective-C compatibility
</h2>
320 <!-- ======================================================================= -->
322 <!-- ======================================================================= -->
323 <h3 id=
"super-cast">Cast of super
</h3>
324 <!-- ======================================================================= -->
326 <p>GCC treats the
<code>super
</code> identifier as an expression that
327 can, among other things, be cast to a different type. Clang treats
328 <code>super
</code> as a context-sensitive keyword, and will reject a
329 type-cast of
<code>super
</code>:
</p>
332 <b>super.m:
11:
12:
<span class=
"error">error:
</span> cannot cast 'super' (it isn't an expression)
</b>
333 [(Super*)super add:
4];
334 <span class=
"caret"> ~~~~~~~~^
</span>
337 <p>To fix this problem, remove the type cast, e.g.
</p>
342 <!-- ======================================================================= -->
343 <h3 id=
"sizeof-interface">Size of interfaces
</h3>
344 <!-- ======================================================================= -->
346 <p>When using the
"non-fragile" Objective-C ABI in use, the size of an
347 Objective-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
353 <b>sizeof.m:
4:
14:
<span class=
"error">error:
</span> invalid application of 'sizeof' to interface 'NSArray' in non-fragile ABI
</b>
354 int size = sizeof(NSArray);
355 <span class=
"caret"> ^ ~~~~~~~~~
</span>
358 <p>Code that relies on the size of an Objective-C class is likely to
359 be broken anyway, since that size is not actually constant. To address
360 this problem, use the Objective-C runtime API function
361 <code>class_getInstanceSize()
</code>:
</p>
364 class_getInstanceSize([NSArray class])
367 <!-- ======================================================================= -->
368 <h3 id=
"objc_objs-cast">Internal Objective-C types
</h3>
369 <!-- ======================================================================= -->
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
374 internal Objective-C structures as implementation detail and won't do implicit conversions:
377 <b>t.mm:
11:
2:
<span class=
"error">error:
</span> no matching function for call to 'f'
</b>
378 f((struct objc_object *)p);
379 <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
382 <span class=
"caret"> ^
</span>
385 <p>Code should use types
<tt>id
</tt>,
<tt>SEL
</tt>, and
<tt>Class
</tt>
386 instead of the internal types.
</p>
388 <!-- ======================================================================= -->
389 <h3 id=
"c_variables-class">C variables in @interface or @protocol
</h3>
390 <!-- ======================================================================= -->
392 <p>GCC allows the declaration of C variables in
393 an
<code>@interface
</code> or
<code>@protocol
</code>
394 declaration. Clang does not allow variable declarations to appear
395 within these declarations unless they are marked
<code>extern
</code>.
</p>
397 <p>Variables may still be declared in an @implementation.
</p>
401 int a; // not allowed in clang
402 int b =
1; // not allowed in clang
403 extern int c; // allowed
408 <!-- ======================================================================= -->
409 <h2 id=
"cxx">C++ compatibility
</h2>
410 <!-- ======================================================================= -->
412 <!-- ======================================================================= -->
413 <h3 id=
"vla">Variable-length arrays
</h3>
414 <!-- ======================================================================= -->
416 <p>GCC and C99 allow an array's size to be determined at run
417 time. This extension is not permitted in standard C++. However, Clang
418 supports such variable length arrays in very limited circumstances for
419 compatibility with GNU C and C99 programs:
</p>
422 <li>The element type of a variable length array must be a POD
423 (
"plain old data") type, which means that it cannot have any
424 user-declared constructors or destructors, any base classes, or any
425 members of non-POD type. All C types are POD types.
</li>
427 <li>Variable length arrays cannot be used as the type of a non-type
428 template parameter.
</li> </ul>
430 <p>If your code uses variable length arrays in a manner that Clang doesn't support, there are several ways to fix your code:
433 <li>replace the variable length array with a fixed-size array if you can
434 determine a reasonable upper bound at compile time; sometimes this is as
435 simple as changing
<tt>int size = ...;
</tt> to
<tt>const int size
436 = ...;
</tt> (if the initializer is a compile-time constant);
</li>
437 <li>use
<tt>std::vector
</tt> or some other suitable container type;
439 <li>allocate the array on the heap instead using
<tt>new Type[]
</tt> -
440 just remember to
<tt>delete[]
</tt> it.
</li>
443 <!-- ======================================================================= -->
444 <h3 id=
"dep_lookup">Unqualified lookup in templates
</h3>
445 <!-- ======================================================================= -->
447 <p>Some versions of GCC accept the following invalid code:
450 template
<typename T
> T Squared(T x) {
451 return Multiply(x, x);
454 int Multiply(int x, int y) {
466 <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>
467 return Multiply(x, x);
468 <span class=
"caret"> ^
</span>
469 <b>my_file.cpp:
10:
3:
<span class=
"note">note:
</span></b> in instantiation of function template specialization 'Squared
<int
>' requested here
471 <span class=
"caret"> ^
</span>
472 <b>my_file.cpp:
5:
5:
<span class=
"note">note:
</span></b> 'Multiply' should be declared prior to the call site
473 int Multiply(int x, int y) {
474 <span class=
"caret"> ^
</span>
477 <p>The C++ standard says that unqualified names like
<q>Multiply
</q>
478 are looked up in two ways.
480 <p>First, the compiler does
<i>unqualified lookup
</i> in the scope
481 where the name was written. For a template, this means the lookup is
482 done at the point where the template is defined, not where it's
483 instantiated. Since
<tt>Multiply
</tt> hasn't been declared yet at
484 this point, unqualified lookup won't find it.
486 <p>Second, if the name is called like a function, then the compiler
487 also does
<i>argument-dependent lookup
</i> (ADL). (Sometimes
488 unqualified lookup can suppress ADL; see [basic.lookup.argdep]p3 for
489 more information.) In ADL, the compiler looks at the types of all the
490 arguments to the call. When it finds a class type, it looks up the
491 name in that class's namespace; the result is all the declarations it
492 finds in those namespaces, plus the declarations from unqualified
493 lookup. However, the compiler doesn't do ADL until it knows all the
496 <p>In our example,
<tt>Multiply
</tt> is called with dependent
497 arguments, so ADL isn't done until the template is instantiated. At
498 that point, the arguments both have type
<tt>int
</tt>, which doesn't
499 contain any class types, and so ADL doesn't look in any namespaces.
500 Since neither form of lookup found the declaration
501 of
<tt>Multiply
</tt>, the code doesn't compile.
503 <p>Here's another example, this time using overloaded operators,
504 which obey very similar rules.
506 <pre>#include
<iostream
>
508 template
<typename T
>
509 void Dump(const T
& value) {
510 std::cout
<< value
<< "\n";
517 std::ostream
& operator
<<(std::ostream
& out, ns::Data data) {
518 return out
<< "Some data";
525 <p>Again, Clang complains:
</p>
528 <b>my_file2.cpp:
5:
13:
<span class=
"error">error:
</span> call to function 'operator
<<' that is neither visible in the template definition nor found by argument-dependent lookup
</b>
529 std::cout
<< value
<< "\n";
530 <span class=
"caret"> ^
</span>
531 <b>my_file2.cpp:
17:
3:
<span class=
"note">note:
</span></b> in instantiation of function template specialization 'Dump
<ns::Data
>' requested here
533 <span class=
"caret"> ^
</span>
534 <b>my_file2.cpp:
12:
15:
<span class=
"note">note:
</span></b> 'operator
<<' should be declared prior to the call site or in namespace 'ns'
535 std::ostream
& operator
<<(std::ostream
& out, ns::Data data) {
536 <span class=
"caret"> ^
</span>
539 <p>Just like before, unqualified lookup didn't find any declarations
540 with the name
<tt>operator
<<</tt>. Unlike before, the argument
541 types both contain class types: one of them is an instance of the
542 class template type
<tt>std::basic_ostream
</tt>, and the other is the
543 type
<tt>ns::Data
</tt> that we declared above. Therefore, ADL will
544 look in the namespaces
<tt>std
</tt> and
<tt>ns
</tt> for
545 an
<tt>operator
<<</tt>. Since one of the argument types was
546 still dependent during the template definition, ADL isn't done until
547 the template is instantiated during
<tt>Use
</tt>, which means that
548 the
<tt>operator
<<</tt> we want it to find has already been
549 declared. Unfortunately, it was declared in the global namespace, not
550 in either of the namespaces that ADL will look in!
552 <p>There are two ways to fix this problem:
</p>
553 <ol><li>Make sure the function you want to call is declared before the
554 template that might call it. This is the only option if none of its
555 argument types contain classes. You can do this either by moving the
556 template definition, or by moving the function definition, or by
557 adding a forward declaration of the function before the template.
</li>
558 <li>Move the function into the same namespace as one of its arguments
559 so that ADL applies.
</li></ol>
561 <p>For more information about argument-dependent lookup, see
562 [basic.lookup.argdep]. For more information about the ordering of
563 lookup in templates, see [temp.dep.candidate].
565 <!-- ======================================================================= -->
566 <h3 id=
"dep_lookup_bases">Unqualified lookup into dependent bases of class templates
</h3>
567 <!-- ======================================================================= -->
569 Some versions of GCC accept the following invalid code:
572 template
<typename T
> struct Base {
574 static void DoThat(T x) {}
577 template
<typename T
> struct Derived : public Base
<T
> {
579 DoThis(x); // Invalid!
580 DoThat(x); // Invalid!
585 Clang correctly rejects it with the following errors
586 (when
<tt>Derived
</tt> is eventually instantiated):
589 <b>my_file.cpp:
8:
5:
<span class=
"error">error:
</span> use of undeclared identifier 'DoThis'
</b>
591 <span class=
"caret"> ^
</span>
593 <b>my_file.cpp:
2:
8:
<span class=
"note">note:
</note></b> must qualify identifier to find this declaration in dependent base class
595 <span class=
"caret"> ^
</span>
596 <b>my_file.cpp:
9:
5:
<span class=
"error">error:
</span> use of undeclared identifier 'DoThat'
</b>
598 <span class=
"caret"> ^
</span>
600 <b>my_file.cpp:
3:
15:
<span class=
"note">note:
</note></b> must qualify identifier to find this declaration in dependent base class
601 static void DoThat(T x) {}
604 Like we said
<a href=
"#dep_lookup">above
</a>, unqualified names like
605 <tt>DoThis
</tt> and
<tt>DoThat
</tt> are looked up when the template
606 <tt>Derived
</tt> is defined, not when it's instantiated. When we look
607 up a name used in a class, we usually look into the base classes.
608 However, we can't look into the base class
<tt>Base
<T
></tt>
609 because its type depends on the template argument
<tt>T
</tt>, so the
610 standard says we should just ignore it. See [temp.dep]p3 for details.
612 <p>The fix, as Clang tells you, is to tell the compiler that we want a
613 class member by prefixing the calls with
<tt>this-
></tt>:
617 <b>this-
></b>DoThis(x);
618 <b>this-
></b>DoThat(x);
622 Alternatively, you can tell the compiler exactly where to look:
626 <b>Base
<T
></b>::DoThis(x);
627 <b>Base
<T
></b>::DoThat(x);
631 This works whether the methods are static or not, but be careful:
632 if
<tt>DoThis
</tt> is virtual, calling it this way will bypass virtual
635 <!-- ======================================================================= -->
636 <h3 id=
"undep_incomplete">Incomplete types in templates
</h3>
637 <!-- ======================================================================= -->
639 The following code is invalid, but compilers are allowed to accept it:
643 template
<class T
> bool read(T
&value) {
645 return read(opts, value);
648 class IOOptions { bool ForceReads; };
649 bool read(const IOOptions
&opts, int
&x);
650 template bool read
<>(int
&);
653 The standard says that types which don't depend on template parameters
654 must be complete when a template is defined if they affect the
655 program's behavior. However, the standard also says that compilers
656 are free to not enforce this rule. Most compilers enforce it to some
657 extent; for example, it would be an error in GCC to
658 write
<tt>opts.ForceReads
</tt> in the code above. In Clang, we feel
659 that enforcing the rule consistently lets us provide a better
660 experience, but unfortunately it also means we reject some code that
661 other compilers accept.
663 <p>We've explained the rule here in very imprecise terms; see
664 [temp.res]p8 for details.
666 <!-- ======================================================================= -->
667 <h3 id=
"bad_templates">Templates with no valid instantiations
</h3>
668 <!-- ======================================================================= -->
670 The following code contains a typo: the programmer
671 meant
<tt>init()
</tt> but wrote
<tt>innit()
</tt> instead.
674 template
<class T
> class Processor {
680 template
<class T
> void process() {
681 Processor
<T
> processor;
682 processor.innit(); // <-- should be 'init()'
687 Unfortunately, we can't flag this mistake as soon as we see it: inside
688 a template, we're not allowed to make assumptions about
"dependent
689 types" like
<tt>Processor
<T
></tt>. Suppose that later on in
690 this file the programmer adds an explicit specialization
691 of
<tt>Processor
</tt>, like so:
694 template
<> class Processor
<char*
> {
699 Now the program will work
— as long as the programmer only ever
700 instantiates
<tt>process()
</tt> with
<tt>T = char*
</tt>! This is why
701 it's hard, and sometimes impossible, to diagnose mistakes in a
702 template definition before it's instantiated.
704 <p>The standard says that a template with no valid instantiations is
705 ill-formed. Clang tries to do as much checking as possible at
706 definition-time instead of instantiation-time: not only does this
707 produce clearer diagnostics, but it also substantially improves
708 compile times when using pre-compiled headers. The downside to this
709 philosophy is that Clang sometimes fails to process files because they
710 contain broken templates that are no longer used. The solution is
711 simple: since the code is unused, just remove it.
713 <!-- ======================================================================= -->
714 <h3 id=
"default_init_const">Default initialization of const variable of a class type requires user-defined default constructor
</h3>
715 <!-- ======================================================================= -->
717 If a
<tt>class
</tt> or
<tt>struct
</tt> has no user-defined default
718 constructor, C++ doesn't allow you to default construct a
<tt>const
</tt>
719 instance of it like this ([dcl.init], p9):
724 // The compiler-supplied default constructor works fine, so we
725 // don't bother with defining one.
730 const Foo foo; // Error!
735 To fix this, you can define a default constructor for the class:
745 const Foo foo; // Now the compiler is happy.
750 <!-- ======================================================================= -->
751 <h3 id=
"param_name_lookup">Parameter name lookup
</h3>
752 <!-- ======================================================================= -->
754 <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>
757 void f(int a, int a);
760 <p>Clang diagnoses this error (where the parameter name has been redeclared). To fix this problem, rename one of the parameters.
</p>
762 <!-- ======================================================================= -->
763 <h2 id=
"cxx11">C++
11 compatibility
</h2>
764 <!-- ======================================================================= -->
766 <!-- ======================================================================= -->
767 <h3 id=
"deleted-special-func">Deleted special member functions
</h3>
768 <!-- ======================================================================= -->
770 <p>In C++
11, the explicit declaration of a move constructor or a move
771 assignment operator within a class deletes the implicit declaration
772 of the copy constructor and copy assignment operator. This change came
773 fairly late in the C++
11 standardization process, so early
774 implementations of C++
11 (including Clang before
3.0, GCC before
4.7,
775 and Visual Studio
2010) do not implement this rule, leading them to
776 accept this ill-formed code:
</p>
780 X(X
&&);
<i>// deletes implicit copy constructor:
</i>
781 <i>// X(const X
&) = delete;
</i>
786 f(x);
<i>// error: X has a deleted copy constructor
</i>
790 <p>This affects some early C++
11 code, including Boost's popular
<a
791 href=
"http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm"><tt>shared_ptr
</tt></a>
792 up to version
1.47.0. The fix for Boost's
<tt>shared_ptr
</tt> is
793 <a href=
"https://svn.boost.org/trac/boost/changeset/73202">available here
</a>.
</p>
795 <!-- ======================================================================= -->
796 <h2 id=
"objective-cxx">Objective-C++ compatibility
</h2>
797 <!-- ======================================================================= -->
799 <!-- ======================================================================= -->
800 <h3 id=
"implicit-downcasts">Implicit downcasts
</h3>
801 <!-- ======================================================================= -->
803 <p>Due to a bug in its implementation, GCC allows implicit downcasts
804 of Objective-C pointers (from a base class to a derived class) when
805 calling functions. Such code is inherently unsafe, since the object
806 might not actually be an instance of the derived class, and is
807 rejected by Clang. For example, given this code:
</p>
811 @interface Derived : Base @end
819 <p>Clang produces the following error:
</p>
822 <b>downcast.mm:
6:
3:
<span class=
"error">error:
</span> no matching function for call to 'f'
</b>
824 <span class=
"caret"> ^
</span>
825 <b>downcast.mm:
4:
6:
<span class=
"note">note:
</note></b> candidate function not viable: cannot convert from
826 superclass 'Base *' to subclass 'Derived *' for
1st argument
828 <span class=
"caret"> ^
</span>
831 <p>If the downcast is actually correct (e.g., because the code has
832 already checked that the object has the appropriate type), add an
839 <!-- ======================================================================= -->
840 <h3 id=
"class-as-property-name">Using
<code>class
</code> as a property name
</h3>
841 <!-- ======================================================================= -->
843 <p>In C and Objective-C,
<code>class
</code> is a normal identifier and
844 can be used to name fields, ivars, methods, and so on. In
845 C++,
<code>class
</code> is a keyword. For compatibility with existing
846 code, Clang permits
<code>class
</code> to be used as part of a method
847 selector in Objective-C++, but this does not extend to any other part
848 of the language. In particular, it is impossible to use property dot
849 syntax in Objective-C++ with the property name
<code>class
</code>, so
850 the following code will fail to parse:
</p>
860 - (int) Meth { return I.class; }
864 <p>Use explicit message-send syntax instead, i.e.
<code>[I class]
</code>.
</p>