[cfe-commits] r107325 - in /cfe/trunk/www: compatibility.html cxx_compatibility.html menu.html.incl
Douglas Gregor
dgregor at apple.com
Wed Jun 30 15:01:08 PDT 2010
Author: dgregor
Date: Wed Jun 30 17:01:08 2010
New Revision: 107325
URL: http://llvm.org/viewvc/llvm-project?rev=107325&view=rev
Log:
New language-compatibility page, including language-compatibility information for the various language dialects Clang supports in a single, easy-to-find page
Added:
cfe/trunk/www/compatibility.html
Modified:
cfe/trunk/www/cxx_compatibility.html
cfe/trunk/www/menu.html.incl
Added: cfe/trunk/www/compatibility.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/compatibility.html?rev=107325&view=auto
==============================================================================
--- cfe/trunk/www/compatibility.html (added)
+++ cfe/trunk/www/compatibility.html Wed Jun 30 17:01:08 2010
@@ -0,0 +1,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>Provide an external (non-inline) definition of <code>add</code>
+ somewhere in your program.</li>
+
+ <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>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>GCC permits 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>clang_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')</b>
+ std::cout << value << "\n";
+ <span class="caret">~~~~~~~~~ ^ ~~~~~</span>
+<b>my_file.cpp:17:3: <span class="note">note:</span> in instantiation of function template specialization 'Dump<ns::Data>' requested here</b>
+ Dump(ns::Data());
+ <span class="caret">^</span>
+</pre>
+
+<p>Just like before, unqualified lookup didn't find any declarations
+with the name <tt>operator<<</tt>. Unlike before, the argument
+types both contain class types: one of them is an instance of the
+class template type <tt>std::basic_ostream</tt>, and the other is the
+type <tt>ns::Data</tt> that we declared above. Therefore, ADL will
+look in the namespaces <tt>std</tt> and <tt>ns</tt> for
+an <tt>operator<<</tt>. Since one of the argument types was
+still dependent during the template definition, ADL isn't done until
+the template is instantiated during <tt>Use</tt>, which means that
+the <tt>operator<<</tt> we want it to find has already been
+declared. Unfortunately, it was declared in the global namespace, not
+in either of the namespaces that ADL will look in!
+
+<p>There are two ways to fix this problem:</p>
+<ol><li>Make sure the function you want to call is declared before the
+template that might call it. This is the only option if none of its
+argument types contain classes. You can do this either by moving the
+template definition, or by moving the function definition, or by
+adding a forward declaration of the function before the template.</li>
+<li>Move the function into the same namespace as one of its arguments
+so that ADL applies.</li></ol>
+
+<p>For more information about argument-dependent lookup, see
+[basic.lookup.argdep]. For more information about the ordering of
+lookup in templates, see [temp.dep.candidate].
+
+<!-- ======================================================================= -->
+<h3 id="dep_lookup_bases">Unqualified lookup into dependent bases of class templates</h3>
+<!-- ======================================================================= -->
+
+Some versions of GCC accept the following invalid code:
+
+<pre>
+template <typename T> struct Base {
+ void DoThis(T x) {}
+ static void DoThat(T x) {}
+};
+
+template <typename T> struct Derived : public Base<T> {
+ void Work(T x) {
+ DoThis(x); // Invalid!
+ DoThat(x); // Invalid!
+ }
+};
+</pre>
+
+Clang correctly rejects it with the following errors
+(when <tt>Derived</tt> is eventually instantiated):
+
+<pre>
+my_file.cpp:8:5: error: use of undeclared identifier 'DoThis'
+ DoThis(x);
+ ^
+ this->
+my_file.cpp:2:8: note: must qualify identifier to find this declaration in dependent base class
+ void DoThis(T x) {}
+ ^
+my_file.cpp:9:5: error: use of undeclared identifier 'DoThat'
+ DoThat(x);
+ ^
+ this->
+my_file.cpp:3:15: note: must qualify identifier to find this declaration in dependent base class
+ static void DoThat(T x) {}
+</pre>
+
+Like we said <a href="#dep_lookup">above</a>, unqualified names like
+<tt>DoThis</tt> and <tt>DoThat</tt> are looked up when the template
+<tt>Derived</tt> is defined, not when it's instantiated. When we look
+up a name used in a class, we usually look into the base classes.
+However, we can't look into the base class <tt>Base<T></tt>
+because its type depends on the template argument <tt>T</tt>, so the
+standard says we should just ignore it. See [temp.dep]p3 for details.
+
+<p>The fix, as Clang tells you, is to tell the compiler that we want a
+class member by prefixing the calls with <tt>this-></tt>:
+
+<pre>
+ void Work(T x) {
+ <b>this-></b>DoThis(x);
+ <b>this-></b>DoThat(x);
+ }
+</pre>
+
+Alternatively, you can tell the compiler exactly where to look:
+
+<pre>
+ void Work(T x) {
+ <b>Base<T></b>::DoThis(x);
+ <b>Base<T></b>::DoThat(x);
+ }
+</pre>
+
+This works whether the methods are static or not, but be careful:
+if <tt>DoThis</tt> is virtual, calling it this way will bypass virtual
+dispatch!
+
+<!-- ======================================================================= -->
+<h3 id="undep_incomplete">Incomplete types in templates</h3>
+<!-- ======================================================================= -->
+
+The following code is invalid, but compilers are allowed to accept it:
+
+<pre>
+ class IOOptions;
+ template <class T> bool read(T &value) {
+ IOOptions opts;
+ return read(opts, value);
+ }
+
+ class IOOptions { bool ForceReads; };
+ bool read(const IOOptions &opts, int &x);
+ template bool read<>(int &);
+</pre>
+
+The standard says that types which don't depend on template parameters
+must be complete when a template is defined if they affect the
+program's behavior. However, the standard also says that compilers
+are free to not enforce this rule. Most compilers enforce it to some
+extent; for example, it would be an error in GCC to
+write <tt>opts.ForceReads</tt> in the code above. In Clang, we feel
+that enforcing the rule consistently lets us provide a better
+experience, but unfortunately it also means we reject some code that
+other compilers accept.
+
+<p>We've explained the rule here in very imprecise terms; see
+[temp.res]p8 for details.
+
+<!-- ======================================================================= -->
+<h3 id="bad_templates">Templates with no valid instantiations</h3>
+<!-- ======================================================================= -->
+
+The following code contains a typo: the programmer
+meant <tt>init()</tt> but wrote <tt>innit()</tt> instead.
+
+<pre>
+ template <class T> class Processor {
+ ...
+ void init();
+ ...
+ };
+ ...
+ template <class T> void process() {
+ Processor<T> processor;
+ processor.innit(); // <-- should be 'init()'
+ ...
+ }
+</pre>
+
+Unfortunately, we can't flag this mistake as soon as we see it: inside
+a template, we're not allowed to make assumptions about "dependent
+types" like <tt>Processor<T></tt>. Suppose that later on in
+this file the programmer adds an explicit specialization
+of <tt>Processor</tt>, like so:
+
+<pre>
+ template <> class Processor<char*> {
+ void innit();
+ };
+</pre>
+
+Now the program will work — as long as the programmer only ever
+instantiates <tt>process()</tt> with <tt>T = char*</tt>! This is why
+it's hard, and sometimes impossible, to diagnose mistakes in a
+template definition before it's instantiated.
+
+<p>The standard says that a template with no valid instantiations is
+ill-formed. Clang tries to do as much checking as possible at
+definition-time instead of instantiation-time: not only does this
+produce clearer diagnostics, but it also substantially improves
+compile times when using pre-compiled headers. The downside to this
+philosophy is that Clang sometimes fails to process files because they
+contain broken templates that are no longer used. The solution is
+simple: since the code is unused, just remove it.
+
+<!-- ======================================================================= -->
+<h3 id="default_init_const">Default initialization of const variable of a class type requires user-defined default constructor</h3>
+<!-- ======================================================================= -->
+
+If a <tt>class</tt> or <tt>struct</tt> has no user-defined default
+constructor, C++ doesn't allow you to default construct a <tt>const</tt>
+instance of it like this ([dcl.init], p9):
+
+<pre>
+class Foo {
+ public:
+ // The compiler-supplied default constructor works fine, so we
+ // don't bother with defining one.
+ ...
+};
+
+void Bar() {
+ const Foo foo; // Error!
+ ...
+}
+</pre>
+
+To fix this, you can define a default constructor for the class:
+
+<pre>
+class Foo {
+ public:
+ Foo() {}
+ ...
+};
+
+void Bar() {
+ const Foo foo; // Now the compiler is happy.
+ ...
+}
+</pre>
+
+<!-- ======================================================================= -->
+<h2 id="objective-c++">Objective-C++ compatibility</h3>
+<!-- ======================================================================= -->
+
+<!-- ======================================================================= -->
+<h3 id="implicit-downcasts">Implicit downcasts</h3>
+<!-- ======================================================================= -->
+
+<p>Due to a bug in its implementation, GCC allows implicit downcasts
+(from base class to a derived class) when calling functions. Such code is
+inherently unsafe, since the object might not actually be an instance
+of the derived class, and is rejected by Clang. For example, given
+this code:</p>
+
+<pre>
+ at interface Base @end
+ at interface Derived : Base @end
+
+void f(Derived *);
+void g(Base *base) {
+ f(base);
+}
+</pre>
+
+<p>Clang produces the following error:</p>
+
+<pre>
+downcast.mm:6:3: error: no matching function for call to 'f'
+ f(base);
+ ^
+downcast.mm:4:6: note: candidate function not viable: no known conversion from
+ 'Base *' to 'Derived *' for 1st argument
+void f(Derived *);
+ ^
+</pre>
+
+<p>If the downcast is actually correct (e.g., because the code has
+already checked that the object has the appropriate type), add an
+explicit cast:</p>
+
+<pre>
+ f((Derived *)base);
+</pre>
+
+</div>
+</body>
+</html>
Modified: cfe/trunk/www/cxx_compatibility.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_compatibility.html?rev=107325&r1=107324&r2=107325&view=diff
==============================================================================
--- cfe/trunk/www/cxx_compatibility.html (original)
+++ cfe/trunk/www/cxx_compatibility.html Wed Jun 30 17:01:08 2010
@@ -2,6 +2,7 @@
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
+<meta HTTP-EQUIV="REFRESH" content="5; url=compatibility.html#c++">
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<title>Clang - C++ Compatibility</title>
<link type="text/css" rel="stylesheet" href="menu.css" />
@@ -19,401 +20,8 @@
<h1>Clang's C++ Compatibility</h1>
<!-- ======================================================================= -->
-<ul>
-<li><a href="#intro">Introduction</a></li>
-<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>
-
-<!-- ======================================================================= -->
-<h2 id="intro">Introduction</h2>
-<!-- ======================================================================= -->
-
-<p>Clang strives to strictly conform to the C++ standard. That means
-it will reject invalid C++ code that another compiler may accept.
-This page helps you decide whether a Clang error message means a
-C++-conformance bug in your code and how you can fix it.</p>
-
-<!-- ======================================================================= -->
-<h2 id="vla">Variable-length arrays</h2>
-<!-- ======================================================================= -->
-
-<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>
-
-<!-- ======================================================================= -->
-<h2 id="init_static_const">Initialization of non-integral static const data members within a class definition</h2>
-<!-- ======================================================================= -->
-
-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.
-
-<!-- ======================================================================= -->
-<h2 id="dep_lookup">Unqualified lookup in templates</h2>
-<!-- ======================================================================= -->
-
-<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')</b>
- std::cout << value << "\n";
- <span class="caret">~~~~~~~~~ ^ ~~~~~</span>
-<b>my_file.cpp:17:3: <span class="note">note:</span> in instantiation of function template specialization 'Dump<ns::Data>' requested here</b>
- Dump(ns::Data());
- <span class="caret">^</span>
-</pre>
-
-<p>Just like before, unqualified lookup didn't find any declarations
-with the name <tt>operator<<</tt>. Unlike before, the argument
-types both contain class types: one of them is an instance of the
-class template type <tt>std::basic_ostream</tt>, and the other is the
-type <tt>ns::Data</tt> that we declared above. Therefore, ADL will
-look in the namespaces <tt>std</tt> and <tt>ns</tt> for
-an <tt>operator<<</tt>. Since one of the argument types was
-still dependent during the template definition, ADL isn't done until
-the template is instantiated during <tt>Use</tt>, which means that
-the <tt>operator<<</tt> we want it to find has already been
-declared. Unfortunately, it was declared in the global namespace, not
-in either of the namespaces that ADL will look in!
-
-<p>There are two ways to fix this problem:</p>
-<ol><li>Make sure the function you want to call is declared before the
-template that might call it. This is the only option if none of its
-argument types contain classes. You can do this either by moving the
-template definition, or by moving the function definition, or by
-adding a forward declaration of the function before the template.</li>
-<li>Move the function into the same namespace as one of its arguments
-so that ADL applies.</li></ol>
-
-<p>For more information about argument-dependent lookup, see
-[basic.lookup.argdep]. For more information about the ordering of
-lookup in templates, see [temp.dep.candidate].
-
-<!-- ======================================================================= -->
-<h2 id="dep_lookup_bases">Unqualified lookup into dependent bases of class templates</h2>
-<!-- ======================================================================= -->
-
-Some versions of GCC accept the following invalid code:
-
-<pre>
-template <typename T> struct Base {
- void DoThis(T x) {}
- static void DoThat(T x) {}
-};
-
-template <typename T> struct Derived : public Base<T> {
- void Work(T x) {
- DoThis(x); // Invalid!
- DoThat(x); // Invalid!
- }
-};
-</pre>
-
-Clang correctly rejects it with the following errors
-(when <tt>Derived</tt> is eventually instantiated):
-
-<pre>
-my_file.cpp:8:5: error: use of undeclared identifier 'DoThis'
- DoThis(x);
- ^
- this->
-my_file.cpp:2:8: note: must qualify identifier to find this declaration in dependent base class
- void DoThis(T x) {}
- ^
-my_file.cpp:9:5: error: use of undeclared identifier 'DoThat'
- DoThat(x);
- ^
- this->
-my_file.cpp:3:15: note: must qualify identifier to find this declaration in dependent base class
- static void DoThat(T x) {}
-</pre>
-
-Like we said <a href="#dep_lookup">above</a>, unqualified names like
-<tt>DoThis</tt> and <tt>DoThat</tt> are looked up when the template
-<tt>Derived</tt> is defined, not when it's instantiated. When we look
-up a name used in a class, we usually look into the base classes.
-However, we can't look into the base class <tt>Base<T></tt>
-because its type depends on the template argument <tt>T</tt>, so the
-standard says we should just ignore it. See [temp.dep]p3 for details.
-
-<p>The fix, as Clang tells you, is to tell the compiler that we want a
-class member by prefixing the calls with <tt>this-></tt>:
-
-<pre>
- void Work(T x) {
- <b>this-></b>DoThis(x);
- <b>this-></b>DoThat(x);
- }
-</pre>
-
-Alternatively, you can tell the compiler exactly where to look:
-
-<pre>
- void Work(T x) {
- <b>Base<T></b>::DoThis(x);
- <b>Base<T></b>::DoThat(x);
- }
-</pre>
-
-This works whether the methods are static or not, but be careful:
-if <tt>DoThis</tt> is virtual, calling it this way will bypass virtual
-dispatch!
-
-<!-- ======================================================================= -->
-<h2 id="undep_incomplete">Incomplete types in templates</h2>
-<!-- ======================================================================= -->
-
-The following code is invalid, but compilers are allowed to accept it:
-
-<pre>
- class IOOptions;
- template <class T> bool read(T &value) {
- IOOptions opts;
- return read(opts, value);
- }
-
- class IOOptions { bool ForceReads; };
- bool read(const IOOptions &opts, int &x);
- template bool read<>(int &);
-</pre>
-
-The standard says that types which don't depend on template parameters
-must be complete when a template is defined if they affect the
-program's behavior. However, the standard also says that compilers
-are free to not enforce this rule. Most compilers enforce it to some
-extent; for example, it would be an error in GCC to
-write <tt>opts.ForceReads</tt> in the code above. In Clang, we feel
-that enforcing the rule consistently lets us provide a better
-experience, but unfortunately it also means we reject some code that
-other compilers accept.
-
-<p>We've explained the rule here in very imprecise terms; see
-[temp.res]p8 for details.
-
-<!-- ======================================================================= -->
-<h2 id="bad_templates">Templates with no valid instantiations</h2>
-<!-- ======================================================================= -->
-
-The following code contains a typo: the programmer
-meant <tt>init()</tt> but wrote <tt>innit()</tt> instead.
-
-<pre>
- template <class T> class Processor {
- ...
- void init();
- ...
- };
- ...
- template <class T> void process() {
- Processor<T> processor;
- processor.innit(); // <-- should be 'init()'
- ...
- }
-</pre>
-
-Unfortunately, we can't flag this mistake as soon as we see it: inside
-a template, we're not allowed to make assumptions about "dependent
-types" like <tt>Processor<T></tt>. Suppose that later on in
-this file the programmer adds an explicit specialization
-of <tt>Processor</tt>, like so:
-
-<pre>
- template <> class Processor<char*> {
- void innit();
- };
-</pre>
-
-Now the program will work — as long as the programmer only ever
-instantiates <tt>process()</tt> with <tt>T = char*</tt>! This is why
-it's hard, and sometimes impossible, to diagnose mistakes in a
-template definition before it's instantiated.
-
-<p>The standard says that a template with no valid instantiations is
-ill-formed. Clang tries to do as much checking as possible at
-definition-time instead of instantiation-time: not only does this
-produce clearer diagnostics, but it also substantially improves
-compile times when using pre-compiled headers. The downside to this
-philosophy is that Clang sometimes fails to process files because they
-contain broken templates that are no longer used. The solution is
-simple: since the code is unused, just remove it.
-
-<!-- ======================================================================= -->
-<h2 id="default_init_const">Default initialization of const variable of a class type requires user-defined default constructor</h2>
-<!-- ======================================================================= -->
-
-If a <tt>class</tt> or <tt>struct</tt> has no user-defined default
-constructor, C++ doesn't allow you to default construct a <tt>const</tt>
-instance of it like this ([dcl.init], p9):
-
-<pre>
-class Foo {
- public:
- // The compiler-supplied default constructor works fine, so we
- // don't bother with defining one.
- ...
-};
-
-void Bar() {
- const Foo foo; // Error!
- ...
-}
-</pre>
-
-To fix this, you can define a default constructor for the class:
-
-<pre>
-class Foo {
- public:
- Foo() {}
- ...
-};
-
-void Bar() {
- const Foo foo; // Now the compiler is happy.
- ...
-}
-</pre>
-
+ <p>The Clang C++ compatibility page has moved. You will be directed <a href="compatibility.html#c++">to its new home</a> in 5 seconds.</p>
+
</div>
</body>
</html>
Modified: cfe/trunk/www/menu.html.incl
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/menu.html.incl?rev=107325&r1=107324&r2=107325&view=diff
==============================================================================
--- cfe/trunk/www/menu.html.incl (original)
+++ cfe/trunk/www/menu.html.incl Wed Jun 30 17:01:08 2010
@@ -9,6 +9,7 @@
<a href="/features.html">Features</a>
<a href="/comparison.html">Comparisons</a>
<a href="/docs/UsersManual.html">Users Manual</a>
+ <a href="/compatibility.html">Language Compatibility</a>
<a href="/docs/LanguageExtensions.html">Language Extensions</a>
<a href="/cxx_status.html">C++ Status</a>
</div>
More information about the cfe-commits
mailing list