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