зеркало из https://github.com/microsoft/clang-1.git
293 строки
9.9 KiB
HTML
293 строки
9.9 KiB
HTML
<!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>Clang - C++ 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>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="#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 allows an array's size to be determined at run time. This,
|
|
however, is not standard C++. Furthermore, it is a potential security
|
|
hole as an incorrect array size may overflow the stack. If Clang tells
|
|
you <tt>"variable length arrays are not permitted in C++"</tt>, here
|
|
are some ways in which you can fix it:</p>
|
|
|
|
<ol>
|
|
<li>replace it 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>
|
|
<!-- ======================================================================= -->
|
|
|
|
Some versions of GCC accept the following invalid code:
|
|
|
|
<pre>
|
|
template <typename T> struct Foo {
|
|
void Work(T x) {
|
|
func(x);
|
|
}
|
|
};
|
|
...
|
|
void func(int x);
|
|
...
|
|
template struct Foo<int>; // or anything else that instantiates Foo<int>::Work
|
|
</pre>
|
|
|
|
The standard says that unqualified names like <tt>func</tt> are looked up
|
|
when the template is defined, not when it's instantiated. Since
|
|
<tt>void func(int)</tt> was not declared yet when <tt>Foo</tt> was
|
|
defined, it's not considered. The fix is usually to
|
|
declare <tt>func</tt> before <tt>Foo</tt>.
|
|
|
|
<p>This is complicated by <i>argument-dependent lookup</i> (ADL),
|
|
which is done when unqualified names are called as functions,
|
|
like <tt>func(x)</tt> above. The standard says that ADL is performed
|
|
in both places if any of the arguments are type-dependent, like
|
|
<tt>x</tt> is in this example. However, ADL does nothing for builtin
|
|
types like <tt>int</tt>, so the example is still invalid. See
|
|
[basic.lookup.argdep] for more information.
|
|
|
|
<!-- ======================================================================= -->
|
|
<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="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>
|
|
|
|
</div>
|
|
</body>
|
|
</html>
|