Blame - www/compatibility.html - fp2-dev/platform/external/clang

blob: b068ec58271b069841e95c47995ca7bef4b692e8 [file] [log] [blame]

Douglas Gregor	c41b6ff	2010-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 Lattner	a02d183	2010-09-16 18:17:55 +0000	[diff] [blame]	35	<li><a href="#vector_builtins">"missing" vector __builtin functions</a></li>
Douglas Gregor	c41b6ff	2010-06-30 22:01:08 +0000	[diff] [blame]	36	<li><a href="#lvalue-cast">Lvalue casts</a></li>
Daniel Dunbar	5a41021	2010-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 Dunbar	15952c9	2010-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 Lattner	9b743f4	2010-11-10 23:51:50 +0000	[diff] [blame^]	39	<li><a href="#inline-asm">Inline assembly</a></li>
Douglas Gregor	c41b6ff	2010-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 Kyrtzidis	3b5b92a	2010-09-13 17:48:07 +0000	[diff] [blame]	46	<li><a href="#objc_objs-cast">Internal Objective-C types</a></li>
Fariborz Jahanian	ddfa6c3	2010-10-22 22:35:51 +0000	[diff] [blame]	47	<li><a href="#c_variables-class">C variables in @class or @protocol</a></li>
Douglas Gregor	c41b6ff	2010-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 Gregor	c41b6ff	2010-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 Gregor	a66d3bb	2010-11-10 20:24:21 +0000	[diff] [blame]	60	<li><a href="#param_name_lookup">Parameter name lookup</a></li>
Douglas Gregor	c41b6ff	2010-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 Jahanian	36e738a	2010-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 Gregor	c41b6ff	2010-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,
				81	which provides different inlining semantics than GCC's default
				82	behavior. For example, when compiling the following code with no optimization:</p>
				83	<pre>
				84	inline int add(int i, int j) { return i + j; }
				85
				86	int 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
				93	no external definition of the <code>add</code> function: the inline
				94	definition is only used for optimization, if the compiler decides to
				95	perform inlining. Therefore, we will get a (correct) link-time error
				96	with Clang, e.g.:</p>
				97
				98	<pre>
				99	Undefined 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 Gregor	c41b6ff	2010-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 Gregor	ff6f66e	2010-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 Gregor	c41b6ff	2010-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 Lattner	a02d183	2010-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><*mmintrin.h></tt>"
				128	header files, which define a standardized API for accessing vector operations
				129	on 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
				131	however they want. Since Clang supports an excellent set of <a
				132	href="../docs/LanguageExtensions.html#vectors">native vector operations</a>,
				133	the Clang headers implement these interfaces in terms of the native vector
				134	operations.
				135	</p>
				136
				137	<p>In contrast, GCC implements these functions mostly as a 1-to-1 mapping to
				138	builtin function calls, like <tt>__builtin_ia32_paddw128</tt>. These builtin
				139	functions are an internal implementation detail of GCC, and are not portable to
				140	the Intel compiler, the Microsoft compiler, or Clang. If you get build errors
				141	mentioning 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
				144	architectures respectively. For these, make sure to use the <arm_neon.h>
				145	and <altivec.h> headers.</p>
				146
Eric Christopher	a473c95	2010-10-25 21:17:59 +0000	[diff] [blame]	147	<p>For x86 architectures this <a href="builtins.py">script</a> should help with
				148	the manual migration process. It will rewrite your source files in place to
				149	use 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
				156	use the API calls instead of calls like <tt>__builtin_ia32_paddw128</tt>.</p>
Chris Lattner	a02d183	2010-09-16 18:17:55 +0000	[diff] [blame]	157
Douglas Gregor	c41b6ff	2010-06-30 22:01:08 +0000	[diff] [blame]	158	<!-- ======================================================================= -->
				159	<h3 id="lvalue-cast">Lvalue casts</h3>
				160	<!-- ======================================================================= -->
				161
Douglas Gregor	6f1adba	2010-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 Gregor	c41b6ff	2010-06-30 22:01:08 +0000	[diff] [blame]	163	different type. Clang produces an error on similar code, e.g.,</p>
				164
				165	<pre>
				166	lvalue.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
				173	example, one could use:</p>
				174
				175	<pre>
				176	addr = (float *)val;
				177	</pre>
				178
				179	<!-- ======================================================================= -->
Daniel Dunbar	5a41021	2010-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
				184	to the manner in which both GCC and Clang disallow jumps into the scope of
				185	variables which have user defined constructors (in C++).</p>
				186
				187	<p>Variables marked with <tt>__block</tt> require special runtime initialization
				188	before they can be used. A jump into the scope of a <tt>__block</tt> variable
				189	would bypass this initialization and therefore the variable cannot safely be
				190	used.</p>
				191
				192	<p>For example, consider the following code fragment:</p>
				193
				194	<pre>
				195	int 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,
				210	because the runtime setup for the storage backing the <tt>x</tt> variable will
				211	not have been initialized. Clang rejects this code with a hard error:</p>
				212
				213	<pre>
				214	t.c:3:5: error: goto into protected scope
				215	goto error;
				216	^
				217	t.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
				223	after the jump target, however the protected scope checker does not check the
Daniel Dunbar	55f1da8	2010-09-03 00:41:43 +0000	[diff] [blame]	224	uses of the variable, only the scopes in which it is visible. You should rewrite
Daniel Dunbar	5a41021	2010-09-02 21:35:16 +0000	[diff] [blame]	225	your code to put the <tt>__block</tt> variables in a scope which is only visible
				226	where they are used.</p>
				227
				228	<!-- ======================================================================= -->
Daniel Dunbar	15952c9	2010-11-09 22:45:16 +0000	[diff] [blame]	229	<h3 id="block-variable-initialization">Non-initialization of <tt>__block</tt>
				230	variables</h3>
				231	<!-- ======================================================================= -->
				232
				233	<p>In the following example code, the <tt>x</tt> variable is used before it is
				234	defined:</p>
				235	<pre>
				236	int 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
				243	zero initialized <tt>__block</tt> variables. However, any program which depends
				244	on this behavior is relying on unspecified compiler behavior. Programs must
				245	explicitly initialize all local block variables before they are used, as with
				246	other local variables.</p>
				247
				248	<p>Clang does not zero initialize local block variables, and programs which rely
				249	on such behavior will most likely break when built with Clang.</p>
				250
Chris Lattner	9b743f4	2010-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
				257	extensions, allowing the same set of constraints, modifiers and operands as GCC
				258	inline assembly.</p>
				259
				260	<p>On targets that use the integrated assembler (such as most X86 targets),
				261	inline assembly is run through the integrated assembler instead of your system
				262	assembler (which is most commonly "gas", the GNU assembler). The LLVM
				263	integrated assembler is extremely compatible with GAS, but there are a couple of
				264	minor 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
				267	that 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
				276	instruction uses the 8-bit <tt>%al</tt> register as an operand, it is clear that
				277	it is an 8-bit add. The second instruction is accepted by both because the "w"
				278	suffix indicates that it is a 16-bit add. The last instruction is accepted by
				279	GAS even though there is nothing that specifies the size of the instruction (and
				280	the assembler randomly picks a 32-bit add). Because it is ambiguous, Clang
				281	rejects the instruction with this error message:
				282	</p>
				283
				284	<pre>
				285	<inline asm>:3:1: error: ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq')
				286	add $4, (%rax)
				287	^
				288	1 error generated.
				289	</pre>
				290
				291	<p>To fix this compatibility issue, add an explicit suffix to the instruction:
				292	this makes your code more clear and is compatible with both GCC and Clang.</p>
				293
Daniel Dunbar	15952c9	2010-11-09 22:45:16 +0000	[diff] [blame]	294	<!-- ======================================================================= -->
Douglas Gregor	c41b6ff	2010-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
				303	can, among other things, be cast to a different type. Clang treats
				304	<code>super</code> as a context-sensitive keyword, and will reject a
				305	type-cast of <code>super</code>:</p>
				306
				307	<pre>
				308	super.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
				323	Objective-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
				326	ABI:</p>
				327
				328	<pre>
				329	sizeof.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
				336	be broken anyway, since that size is not actually constant. To address
				337	this problem, use the Objective-C runtime API function
Benjamin Kramer	e661750	2010-06-30 22:29:56 +0000	[diff] [blame]	338	<code>class_getInstanceSize()</code>:</p>
Douglas Gregor	c41b6ff	2010-06-30 22:01:08 +0000	[diff] [blame]	339
				340	<pre>
				341	class_getInstanceSize([NSArray class])
				342	</pre>
				343
				344	<!-- ======================================================================= -->
Argyrios Kyrtzidis	3b5b92a	2010-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
				351	internal Objective-C structures as implementation detail and won't do implicit conversions:
				352
				353	<pre>
				354	t.mm:11:2: error: no matching function for call to 'f'
				355	f((struct objc_object *)p);
				356	^
				357	t.mm:5:6: note: candidate function not viable: no known conversion from 'struct objc_object *' to 'id' for 1st argument
				358	void f(id x);
				359	^
				360	</pre>
				361
				362	<p>Code should use types <tt>id</tt>, <tt>SEL</tt>, and <tt>Class</tt>
				363	instead of the internal types.</p>
				364
				365	<!-- ======================================================================= -->
Fariborz Jahanian	ddfa6c3	2010-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
				370	C functions. Clang does not allow variable or C function declarations. External
				371	declarations, however, is allowed. Variables may only be declared in an
				372	@implementation.
				373
				374	<pre>
				375	@interface XX
				376	int x; // not allowed in clang
				377	int one=1; // not allowed in clang
				378	extern int OK;
				379	@end
				380
				381	</pre>
				382
				383	<!-- ======================================================================= -->
Douglas Gregor	c41b6ff	2010-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
				392	time. This extension is not permitted in standard C++. However, Clang
				393	supports such variable length arrays in very limited circumstances for
				394	compatibility 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
				403	template 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 Gregor	c41b6ff	2010-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>
				428	template <typename T> T Squared(T x) {
				429	return Multiply(x, x);
				430	}
				431
				432	int Multiply(int x, int y) {
				433	return x * y;
				434	}
				435
				436	int 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<int>' 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>
				453	are looked up in two ways.
				454
				455	<p>First, the compiler does <i>unqualified lookup</i> in the scope
				456	where the name was written. For a template, this means the lookup is
				457	done at the point where the template is defined, not where it's
				458	instantiated. Since <tt>Multiply</tt> hasn't been declared yet at
				459	this point, unqualified lookup won't find it.
				460
				461	<p>Second, if the name is called like a function, then the compiler
				462	also does <i>argument-dependent lookup</i> (ADL). (Sometimes
				463	unqualified lookup can suppress ADL; see [basic.lookup.argdep]p3 for
				464	more information.) In ADL, the compiler looks at the types of all the
				465	arguments to the call. When it finds a class type, it looks up the
				466	name in that class's namespace; the result is all the declarations it
				467	finds in those namespaces, plus the declarations from unqualified
				468	lookup. However, the compiler doesn't do ADL until it knows all the
				469	argument types.
				470
				471	<p>In our example, <tt>Multiply</tt> is called with dependent
				472	arguments, so ADL isn't done until the template is instantiated. At
				473	that point, the arguments both have type <tt>int</tt>, which doesn't
				474	contain any class types, and so ADL doesn't look in any namespaces.
				475	Since neither form of lookup found the declaration
				476	of <tt>Multiply</tt>, the code doesn't compile.
				477
				478	<p>Here's another example, this time using overloaded operators,
				479	which obey very similar rules.
				480
				481	<pre>#include <iostream>
				482
				483	template<typename T>
				484	void Dump(const T& value) {
				485	std::cout << value << "\n";
				486	}
				487
				488	namespace ns {
				489	struct Data {};
				490	}
				491
				492	std::ostream& operator<<(std::ostream& out, ns::Data data) {
				493	return out << "Some data";
				494	}
				495
				496	void 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<char>') and 'ns::Data const')</b>
				504	std::cout << value << "\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<ns::Data>' 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
				512	with the name <tt>operator<<</tt>. Unlike before, the argument
				513	types both contain class types: one of them is an instance of the
				514	class template type <tt>std::basic_ostream</tt>, and the other is the
				515	type <tt>ns::Data</tt> that we declared above. Therefore, ADL will
				516	look in the namespaces <tt>std</tt> and <tt>ns</tt> for
				517	an <tt>operator<<</tt>. Since one of the argument types was
				518	still dependent during the template definition, ADL isn't done until
				519	the template is instantiated during <tt>Use</tt>, which means that
				520	the <tt>operator<<</tt> we want it to find has already been
				521	declared. Unfortunately, it was declared in the global namespace, not
				522	in 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
				526	template that might call it. This is the only option if none of its
				527	argument types contain classes. You can do this either by moving the
				528	template definition, or by moving the function definition, or by
				529	adding a forward declaration of the function before the template.</li>
				530	<li>Move the function into the same namespace as one of its arguments
				531	so 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
				535	lookup 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
				541	Some versions of GCC accept the following invalid code:
				542
				543	<pre>
				544	template <typename T> struct Base {
				545	void DoThis(T x) {}
				546	static void DoThat(T x) {}
				547	};
				548
				549	template <typename T> struct Derived : public Base<T> {
				550	void Work(T x) {
				551	DoThis(x); // Invalid!
				552	DoThat(x); // Invalid!
				553	}
				554	};
				555	</pre>
				556
				557	Clang correctly rejects it with the following errors
				558	(when <tt>Derived</tt> is eventually instantiated):
				559
				560	<pre>
				561	my_file.cpp:8:5: error: use of undeclared identifier 'DoThis'
				562	DoThis(x);
				563	^
				564	this->
				565	my_file.cpp:2:8: note: must qualify identifier to find this declaration in dependent base class
				566	void DoThis(T x) {}
				567	^
				568	my_file.cpp:9:5: error: use of undeclared identifier 'DoThat'
				569	DoThat(x);
				570	^
				571	this->
				572	my_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
				576	Like 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
				579	up a name used in a class, we usually look into the base classes.
				580	However, we can't look into the base class <tt>Base<T></tt>
				581	because its type depends on the template argument <tt>T</tt>, so the
				582	standard 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
				585	class member by prefixing the calls with <tt>this-></tt>:
				586
				587	<pre>
				588	void Work(T x) {
				589	<b>this-></b>DoThis(x);
				590	<b>this-></b>DoThat(x);
				591	}
				592	</pre>
				593
				594	Alternatively, you can tell the compiler exactly where to look:
				595
				596	<pre>
				597	void Work(T x) {
				598	<b>Base<T></b>::DoThis(x);
				599	<b>Base<T></b>::DoThat(x);
				600	}
				601	</pre>
				602
				603	This works whether the methods are static or not, but be careful:
				604	if <tt>DoThis</tt> is virtual, calling it this way will bypass virtual
				605	dispatch!
				606
				607	<!-- ======================================================================= -->
				608	<h3 id="undep_incomplete">Incomplete types in templates</h3>
				609	<!-- ======================================================================= -->
				610
				611	The following code is invalid, but compilers are allowed to accept it:
				612
				613	<pre>
				614	class IOOptions;
				615	template <class T> bool read(T &value) {
				616	IOOptions opts;
				617	return read(opts, value);
				618	}
				619
				620	class IOOptions { bool ForceReads; };
				621	bool read(const IOOptions &opts, int &x);
				622	template bool read<>(int &);
				623	</pre>
				624
				625	The standard says that types which don't depend on template parameters
				626	must be complete when a template is defined if they affect the
				627	program's behavior. However, the standard also says that compilers
				628	are free to not enforce this rule. Most compilers enforce it to some
				629	extent; for example, it would be an error in GCC to
				630	write <tt>opts.ForceReads</tt> in the code above. In Clang, we feel
				631	that enforcing the rule consistently lets us provide a better
				632	experience, but unfortunately it also means we reject some code that
				633	other 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
				642	The following code contains a typo: the programmer
				643	meant <tt>init()</tt> but wrote <tt>innit()</tt> instead.
				644
				645	<pre>
				646	template <class T> class Processor {
				647	...
				648	void init();
				649	...
				650	};
				651	...
				652	template <class T> void process() {
				653	Processor<T> processor;
				654	processor.innit(); // <-- should be 'init()'
				655	...
				656	}
				657	</pre>
				658
				659	Unfortunately, we can't flag this mistake as soon as we see it: inside
				660	a template, we're not allowed to make assumptions about "dependent
				661	types" like <tt>Processor<T></tt>. Suppose that later on in
				662	this file the programmer adds an explicit specialization
				663	of <tt>Processor</tt>, like so:
				664
				665	<pre>
				666	template <> class Processor<char*> {
				667	void innit();
				668	};
				669	</pre>
				670
				671	Now the program will work — as long as the programmer only ever
				672	instantiates <tt>process()</tt> with <tt>T = char*</tt>! This is why
				673	it's hard, and sometimes impossible, to diagnose mistakes in a
				674	template definition before it's instantiated.
				675
				676	<p>The standard says that a template with no valid instantiations is
				677	ill-formed. Clang tries to do as much checking as possible at
				678	definition-time instead of instantiation-time: not only does this
				679	produce clearer diagnostics, but it also substantially improves
				680	compile times when using pre-compiled headers. The downside to this
				681	philosophy is that Clang sometimes fails to process files because they
				682	contain broken templates that are no longer used. The solution is
				683	simple: 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
				689	If a <tt>class</tt> or <tt>struct</tt> has no user-defined default
				690	constructor, C++ doesn't allow you to default construct a <tt>const</tt>
				691	instance of it like this ([dcl.init], p9):
				692
				693	<pre>
				694	class Foo {
				695	public:
				696	// The compiler-supplied default constructor works fine, so we
				697	// don't bother with defining one.
				698	...
				699	};
				700
				701	void Bar() {
				702	const Foo foo; // Error!
				703	...
				704	}
				705	</pre>
				706
				707	To fix this, you can define a default constructor for the class:
				708
				709	<pre>
				710	class Foo {
				711	public:
				712	Foo() {}
				713	...
				714	};
				715
				716	void Bar() {
				717	const Foo foo; // Now the compiler is happy.
				718	...
				719	}
				720	</pre>
				721
				722	<!-- ======================================================================= -->
Douglas Gregor	a66d3bb	2010-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>
				729	void 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 Gregor	c41b6ff	2010-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
				744	inherently unsafe, since the object might not actually be an instance
				745	of the derived class, and is rejected by Clang. For example, given
				746	this code:</p>
				747
				748	<pre>
				749	@interface Base @end
				750	@interface Derived : Base @end
				751
				752	void f(Derived *);
				753	void g(Base *base) {
				754	f(base);
				755	}
				756	</pre>
				757
				758	<p>Clang produces the following error:</p>
				759
				760	<pre>
				761	downcast.mm:6:3: error: no matching function for call to 'f'
				762	f(base);
				763	^
Douglas Gregor	92bc027	2010-07-01 03:50:01 +0000	[diff] [blame]	764	downcast.mm:4:6: note: candidate function not viable: cannot convert from
				765	superclass 'Base ' to subclass 'Derived ' for 1st argument
Douglas Gregor	c41b6ff	2010-06-30 22:01:08 +0000	[diff] [blame]	766	void f(Derived *);
				767	^
				768	</pre>
				769
				770	<p>If the downcast is actually correct (e.g., because the code has
				771	already checked that the object has the appropriate type), add an
				772	explicit cast:</p>
				773
				774	<pre>
				775	f((Derived *)base);
				776	</pre>
				777
Fariborz Jahanian	36e738a	2010-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
				783	be compatible with GCC. However, use of property dot syntax notation to call
				784	this method is not allowed in clang++, as [I class] is a suitable syntax that
				785	will work. So, this test will fail in clang++.
				786
				787	<pre>
				788	@interface I {
				789	int cls;
				790	}
				791	+ (int)class;
				792	@end
				793
				794	@implementation I
				795	- (int) Meth { return I.class; }
				796	@end
				797	<pre>
				798
				799
Douglas Gregor	c41b6ff	2010-06-30 22:01:08 +0000	[diff] [blame]	800	</div>
				801	</body>
				802	</html>