1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<title>Language Compatibility</title>
<link type="text/css" rel="stylesheet" href="menu.css" />
<link type="text/css" rel="stylesheet" href="content.css" />
<style type="text/css">
</style>
</head>
<body>
<!--#include virtual="menu.html.incl"-->
<div id="content">
<!-- ======================================================================= -->
<h1>Language Compatibility</h1>
<!-- ======================================================================= -->
<p>Clang strives to both conform to current language standards (C99,
C++98) and also to implement many widely-used extensions available
in other compilers, so that most correct code will "just work" when
compiler with Clang. However, Clang is more strict than other
popular compilers, and may reject incorrect code that other
compilers allow. This page documents common compatibility and
portability issues with Clang to help you understand and fix the
problem in your code when Clang emits an error message.</p>
<ul>
<li><a href="#c">C compatibility</a>
<ul>
<li><a href="#inline">C99 inline functions</a></li>
<li><a href="#lvalue-cast">Lvalue casts</a></li>
</ul>
</li>
<li><a href="#objective-c">Objective-C compatibility</a>
<ul>
<li><a href="#super-cast">Cast of super</a></li>
<li><a href="#sizeof-interface">Size of interfaces</a></li>
</ul>
</li>
<li><a href="#c++">C++ compatibility</a>
<ul>
<li><a href="#vla">Variable-length arrays</a></li>
<li><a href="#init_static_const">Initialization of non-integral static const data members within a class definition</a></li>
<li><a href="#dep_lookup">Unqualified lookup in templates</a></li>
<li><a href="#dep_lookup_bases">Unqualified lookup into dependent bases of class templates</a></li>
<li><a href="#undep_incomplete">Incomplete types in templates</a></li>
<li><a href="#bad_templates">Templates with no valid instantiations</a></li>
<li><a href="#default_init_const">Default initialization of const
variable of a class type requires user-defined default
constructor</a></li>
</ul>
</li>
<li><a href="#objective-c++">Objective-C++ compatibility</a>
<ul>
<li><a href="#implicit-downcasts">Implicit downcasts</a></li>
</ul>
</li>
</ul>
<!-- ======================================================================= -->
<h2 id="c">C compatibility</h3>
<!-- ======================================================================= -->
<!-- ======================================================================= -->
<h3 id="inline">C99 inline functions</h3>
<!-- ======================================================================= -->
<p>By default, Clang builds C code according to the C99 standard,
which provides different inlining semantics than GCC's default
behavior. For example, when compiling the following code with no optimization:</p>
<pre>
inline int add(int i, int j) { return i + j; }
int main() {
int i = add(4, 5);
return i;
}
</pre>
<p>In C99, this is an incomplete (incorrect) program because there is
no external definition of the <code>add</code> function: the inline
definition is only used for optimization, if the compiler decides to
perform inlining. Therefore, we will get a (correct) link-time error
with Clang, e.g.:</p>
<pre>
Undefined symbols:
"_add", referenced from:
_main in cc-y1jXIr.o
</pre>
<p>There are several ways to fix this problem:</p>
<ul>
<li>Change <code>add</code> to a <code>static inline</code>
function. Static inline functions are always resolved within the
translation unit, so you won't have to add an external, non-inline
definition of the function elsewhere in your program.</li>
<li>Provide an external (non-inline) definition of <code>add</code>
somewhere in your program.</li>
<li>Compile with the GNU89 dialect by adding
<code>-std=gnu89</code> to the set of Clang options. This option is
only recommended if the program source cannot be changed or if the
program also relies on additional C89-specific behavior that cannot
be changed.</li>
</ul>
<!-- ======================================================================= -->
<h3 id="lvalue-cast">Lvalue casts</h3>
<!-- ======================================================================= -->
<p>Old versions of GCC permit casting the left-hand side of an assignment to a
different type. Clang produces an error on similar code, e.g.,</p>
<pre>
lvalue.c:2:3: error: assignment to cast is illegal, lvalue casts are not
supported
(int*)addr = val;
^~~~~~~~~~ ~
</pre>
<p>To fix this problem, move the cast to the right-hand side. In this
example, one could use:</p>
<pre>
addr = (float *)val;
</pre>
<!-- ======================================================================= -->
<h2 id="objective-c">Objective-C compatibility</h3>
<!-- ======================================================================= -->
<!-- ======================================================================= -->
<h3 id="super-cast">Cast of super</h3>
<!-- ======================================================================= -->
<p>GCC treats the <code>super</code> identifier as an expression that
can, among other things, be cast to a different type. Clang treats
<code>super</code> as a context-sensitive keyword, and will reject a
type-cast of <code>super</code>:</p>
<pre>
super.m:11:12: error: cannot cast 'super' (it isn't an expression)
[(Super*)super add:4];
~~~~~~~~^
</pre>
<p>To fix this problem, remove the type cast, e.g.</p>
<pre>
[super add:4];
</pre>
<!-- ======================================================================= -->
<h3 id="sizeof-interface">Size of interfaces</h3>
<!-- ======================================================================= -->
<p>When using the "non-fragile" Objective-C ABI in use, the size of an
Objective-C class may change over time as instance variables are added
(or removed). For this reason, Clang rejects the application of the
<code>sizeof</code> operator to an Objective-C class when using this
ABI:</p>
<pre>
sizeof.m:4:14: error: invalid application of 'sizeof' to interface 'NSArray' in
non-fragile ABI
int size = sizeof(NSArray);
^ ~~~~~~~~~
</pre>
<p>Code that relies on the size of an Objective-C class is likely to
be broken anyway, since that size is not actually constant. To address
this problem, use the Objective-C runtime API function
<code>class_getInstanceSize()</code>:</p>
<pre>
class_getInstanceSize([NSArray class])
</pre>
<!-- ======================================================================= -->
<h2 id="c++">C++ compatibility</h3>
<!-- ======================================================================= -->
<!-- ======================================================================= -->
<h3 id="vla">Variable-length arrays</h3>
<!-- ======================================================================= -->
<p>GCC and C99 allow an array's size to be determined at run
time. This extension is not permitted in standard C++. However, Clang
supports such variable length arrays in very limited circumstances for
compatibility with GNU C and C99 programs:</p>
<ul>
<li>The element type of a variable length array must be a POD
("plain old data") type, which means that it cannot have any
user-declared constructors or destructors, base classes, or any
members if non-POD type. All C types are POD types.</li>
<li>Variable length arrays cannot be used as the type of a non-type
template parameter.</li> </ul>
<p>If your code uses variable length arrays in a manner that Clang doesn't support, there are several ways to fix your code:
<ol>
<li>replace the variable length array with a fixed-size array if you can
determine a
reasonable upper bound at compile time; sometimes this is as
simple as changing <tt>int size = ...;</tt> to <tt>const int size
= ...;</tt> (if the definition of <tt>size</tt> is a compile-time
integral constant);</li>
<li>use an <tt>std::string</tt> instead of a <tt>char []</tt>;</li>
<li>use <tt>std::vector</tt> or some other suitable container type;
or</li>
<li>allocate the array on the heap instead using <tt>new Type[]</tt> -
just remember to <tt>delete[]</tt> it.</li>
</ol>
<!-- ======================================================================= -->
<h3 id="init_static_const">Initialization of non-integral static const data members within a class definition</h3>
<!-- ======================================================================= -->
The following code is ill-formed in C++'03:
<pre>
class SomeClass {
public:
static const double SomeConstant = 0.5;
};
const double SomeClass::SomeConstant;
</pre>
Clang errors with something similar to:
<pre>
.../your_file.h:42:42: error: 'SomeConstant' can only be initialized if it is a static const integral data member
static const double SomeConstant = 0.5;
^ ~~~
</pre>
Only <i>integral</i> constant expressions are allowed as initializers
within the class definition. See C++'03 [class.static.data] p4 for the
details of this restriction. The fix here is straightforward: move
the initializer to the definition of the static data member, which
must exist outside of the class definition:
<pre>
class SomeClass {
public:
static const double SomeConstant;
};
const double SomeClass::SomeConstant<b> = 0.5</b>;
</pre>
Note that the forthcoming C++0x standard will allow this.
<!-- ======================================================================= -->
<h3 id="dep_lookup">Unqualified lookup in templates</h3>
<!-- ======================================================================= -->
<p>Some versions of GCC accept the following invalid code:
<pre>
template <typename T> T Squared(T x) {
return Multiply(x, x);
}
int Multiply(int x, int y) {
return x * y;
}
int main() {
Squared(5);
}
</pre>
<p>Clang complains:
<pre> <b>my_file.cpp:2:10: <span class="error">error:</span> use of undeclared identifier 'Multiply'</b>
return Multiply(x, x);
<span class="caret"> ^</span>
<b>my_file.cpp:10:3: <span class="note">note:</span> in instantiation of function template specialization 'Squared<int>' requested here</b>
Squared(5);
<span class="caret"> ^</span>
</pre>
<p>The C++ standard says that unqualified names like <q>Multiply</q>
are looked up in two ways.
<p>First, the compiler does <i>unqualified lookup</i> in the scope
where the name was written. For a template, this means the lookup is
done at the point where the template is defined, not where it's
instantiated. Since <tt>Multiply</tt> hasn't been declared yet at
this point, unqualified lookup won't find it.
<p>Second, if the name is called like a function, then the compiler
also does <i>argument-dependent lookup</i> (ADL). (Sometimes
unqualified lookup can suppress ADL; see [basic.lookup.argdep]p3 for
more information.) In ADL, the compiler looks at the types of all the
arguments to the call. When it finds a class type, it looks up the
name in that class's namespace; the result is all the declarations it
finds in those namespaces, plus the declarations from unqualified
lookup. However, the compiler doesn't do ADL until it knows all the
argument types.
<p>In our example, <tt>Multiply</tt> is called with dependent
arguments, so ADL isn't done until the template is instantiated. At
that point, the arguments both have type <tt>int</tt>, which doesn't
contain any class types, and so ADL doesn't look in any namespaces.
Since neither form of lookup found the declaration
of <tt>Multiply</tt>, the code doesn't compile.
<p>Here's another example, this time using overloaded operators,
which obey very similar rules.
<pre>#include <iostream>
template<typename T>
void Dump(const T& value) {
std::cout << value << "\n";
}
namespace ns {
struct Data {};
}
std::ostream& operator<<(std::ostream& out, ns::Data data) {
return out << "Some data";
}
void Use() {
Dump(ns::Data());
}</pre>
<p>Again, Clang complains about not finding a matching function:</p>
<pre>
<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')</
|
