html fixes

git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2009-matevz@12183 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
William S Fulton 2010-07-24 00:31:10 +00:00
commit 368f442508

View file

@ -19,7 +19,7 @@
<li><a href="#Cpp0x_Initializer_lists">Initializer lists</a>
<li><a href="#Cpp0x_Uniform_initialization">Uniform initialization</a>
<li><a href="#Cpp0x_Type_inference">Type inference</a>
<li><a href="#Cpp0x_Range-based_for-loop">Range-based for-loop</a>
<li><a href="#Cpp0x_Range_based_for_loop">Range-based for-loop</a>
<li><a href="#Cpp0x_Lambda_functions_and_expressions">Lambda functions and expressions</a>
<li><a href="#Cpp0x_Alternate_function_syntax">Alternate function syntax</a>
<li><a href="#Cpp0x_Object_construction_improvement">Object construction improvement</a>
@ -31,8 +31,8 @@
<li><a href="#Cpp0x_Unrestricted_unions">Unrestricted unions</a>
<li><a href="#Cpp0x_Variadic_templates">Variadic templates</a>
<li><a href="#Cpp0x_New_string_literals">New string literals</a>
<li><a href="#Cpp0x_User-defined_literals">User-defined literals</a>
<li><a href="#Cpp0x_Thread-local_storage">Thread-local storage</a>
<li><a href="#Cpp0x_User_defined_literals">User-defined literals</a>
<li><a href="#Cpp0x_Thread_local_storage">Thread-local storage</a>
<li><a href="#Cpp0x_Defaulting/deleting_of_standard_functions_on_C++_objects">Defaulting/deleting of standard functions on C++ objects</a>
<li><a href="#Cpp0x_Type_long_long_int">Type long long int</a>
<li><a href="#Cpp0x_Static_assertions">Static assertions</a>
@ -43,7 +43,7 @@
<li><a href="#Cpp0x_Threading_facilities">Threading facilities</a>
<li><a href="#Cpp0x_Tuple_types">Tuple types and hash tables</a>
<li><a href="#Cpp0x_Regular_expressions">Regular expressions</a>
<li><a href="#Cpp0x_General-purpose_smart_pointers">General-purpose smart pointers</a>
<li><a href="#Cpp0x_General_purpose_smart_pointers">General-purpose smart pointers</a>
<li><a href="#Cpp0x_Extensible_random_number_facility">Extensible random number facility</a>
<li><a href="#Cpp0x_Wrapper_reference">Wrapper reference</a>
<li><a href="#Cpp0x_Polymorphous_wrappers_for_function_objects">Polymorphous wrappers for function objects</a>
@ -77,7 +77,7 @@ yet.</p>
<p>SWIG correctly parses the new operator &amp;&amp; the same as the reference operator &amp;.</p>
<p>The wrapper for the following code is correctly produced:</p>
<div class="code"><PRE>
<div class="code"><pre>
class MyClass {
MyClass(MyClass&amp;&amp; p) : ptr(p.ptr) {p.ptr = 0;}
MyClass&amp; operator=(MyClass&amp;&amp; p) {
@ -85,25 +85,25 @@ class MyClass {
return *this;
}
};
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Generalized_constant_expressions"></a>7.2.2 Generalized constant expressions</H3>
<p>SWIG correctly parses the keyword <tt>constexpr</tt>, but ignores its functionality. Constant functions cannot be used as constants.</p>
<div class="code"><PRE>
<div class="code"><pre>
constexpr int myConstFunc() { return 10; }
const int a = myConstFunc(); // results in error
</PRE></div>
</pre></div>
<p>Users needs to use values or predefined constants when defining the new constant value:</p>
<div class="code"><PRE>
<div class="code"><pre>
#define MY_CONST 10
constexpr int myConstFunc() { return MY_CONST; }
const int a = MY_CONST; // ok
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Extern_template"></a>7.2.3 Extern template</H3>
@ -111,7 +111,7 @@ const int a = MY_CONST; // ok
<p>SWIG correctly parses the keywords <tt>extern template</tt>. However, the explicit template instantiation is not used by SWIG, a <tt>%template</tt> is still required.</p>
<div class="code"><PRE>
<div class="code"><pre>
extern template class std::vector&lt;MyClass&gt;; // explicit instantiation
...
@ -121,7 +121,7 @@ public:
int a;
int b;
};
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Initializer_lists"></a>7.2.4 Initializer lists</H3>
@ -134,29 +134,29 @@ filling the class members manually.</p>
<p>For now, if a user wants to fill the class components like this:</p>
<div class="code"><PRE>
<div class="code"><pre>
class A {
public:
A( std::initializer_list&lt;int&gt; );
};
A a1 = {1,2,3,4};
</PRE></div>
</pre></div>
<p>You should add another constructor using the std::vector for example:</p>
<div class="code"><PRE>
<div class="code"><pre>
class A {
public:
A( std::initializer_list&lt;int&gt; );
A( std::vector&lt;int&gt; );
};
A a1 = {1,2,3,4};
</PRE></div>
</pre></div>
<p>And call it from your target language, for example, in Python:</p>
<div class="targetlang"><PRE>
<div class="targetlang"><pre>
&gt;&gt;&gt; a2 = A( [1,2,3,4] )
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Uniform_initialization"></a>7.2.5 Uniform initialization</H3>
@ -164,7 +164,7 @@ A a1 = {1,2,3,4};
<p>The curly brackets {} for member initialization are fully
supported by SWIG:</p>
<div class="code"><PRE>
<div class="code"><pre>
struct BasicStruct {
int x;
double y;
@ -179,17 +179,17 @@ struct AltStruct {
BasicStruct var1{5, 3.2}; // only fills the struct components
AltStruct var2{2, 4.3}; // calls the constructor
</PRE></div>
</pre></div>
<p>Uniform initialization does not affect usage from the target language, for example in Python:</p>
<div class="targetlang"><PRE>
<div class="targetlang"><pre>
&gt;&gt;&gt; a = AltStruct(10, 142.15)
&gt;&gt;&gt; a.x_
10
&gt;&gt;&gt; a.y_
142.15
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Type_inference"></a>7.2.6 Type inference</H3>
@ -197,16 +197,16 @@ AltStruct var2{2, 4.3}; // calls the constructor
<p>SWIG supports <tt>decltype()</tt> with some limitations. Single
variables are allowed, however, expressions are not supported yet. For
example, the following code will work:</p>
<div class="code"><PRE>
<div class="code"><pre>
int i;
decltype(i) j;
</PRE></div>
</pre></div>
<p>However, using an expression inside the decltype results in syntax error:</p>
<div class="code"><PRE>
<div class="code"><pre>
int i; int j;
decltype(i+j) k; // syntax error
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Range_based_for_loop"></a>7.2.7 Range-based for-loop</H3>
@ -218,9 +218,9 @@ ignores it.</p>
<p>SWIG correctly parses the Lambda functions syntax. For example:</p>
<div class="code"><PRE>
auto myLambdaFunc = [this]() { this->SomePrivateMemberFunction() };
</PRE></div>
<div class="code"><pre>
auto sum = [](int x, int y) -&gt; int { return x+y; };
</pre></div>
<p>The lambda functions are removed from the wrapper class for now, because of the lack of support
for closures (scope of the lambda functions) in the target languages.</p>
@ -229,36 +229,36 @@ for closures (scope of the lambda functions) in the target languages.</p>
<p>SWIG fully supports the new definition of functions. For example:</p>
<div class="code"><PRE>
<div class="code"><pre>
struct SomeStruct {
int FuncName(int x, int y);
};
</PRE></div>
</pre></div>
<p>can now be written as in C++0x:</p>
<div class="code"><PRE>
<div class="code"><pre>
struct SomeStruct {
auto FuncName(int x, int y) -> int;
auto FuncName(int x, int y) -&gt; int;
};
auto SomeStruct::FuncName(int x, int y) -> int {
auto SomeStruct::FuncName(int x, int y) -&gt; int {
return x + y;
}
</PRE></div>
</pre></div>
<p>The usage in the target languages remains the same, for example in Python:</p>
<div class="targetlang"><PRE>
<div class="targetlang"><pre>
&gt;&gt;&gt; a = SomeStruct()
&gt;&gt;&gt; a.FuncName(10,5)
15
</PRE></div>
</pre></div>
<p>SWIG will also deal with type inference for the return type, as per the limitations described earlier. For example:</p>
<div class="code"><PRE>
<div class="code"><pre>
auto square(float a, float b) -&gt; decltype(a);
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Object_construction_improvement"></a>7.2.10 Object construction improvement</H3>
@ -267,7 +267,7 @@ auto square(float a, float b) -&gt; decltype(a);
(constructor delegation and constructor inheritance) into the class
using the <tt>using</tt> keyword.</p>
<div class="code"><PRE>
<div class="code"><pre>
class BaseClass {
public:
BaseClass(int iValue);
@ -277,7 +277,7 @@ class DerivedClass: public BaseClass {
public:
using BaseClass::BaseClass; // Adds DerivedClass(int) constructor
};
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Null_pointer_constant"></a>7.2.11 Null pointer constant</H3>
@ -289,15 +289,15 @@ constant in the target language.</p>
<p>SWIG parses the new <tt>enum class</tt> syntax and forward declarator for the enums:</p>
<div class="code"><PRE>
<div class="code"><pre>
enum class MyEnum : unsigned int;
</PRE></div>
</pre></div>
<p>The strongly typed enumerations are treated the same as the ordinary and anonymous enums.
This is because SWIG doesn't support nested classes. This is usually not a problem, however,
there may be some name clashes. For example, the following code:</p>
<div class="code"><PRE>
<div class="code"><pre>
class Color {
enum class PrintingColors : unsigned int {
Cyan, Magenta, Yellow, Black
@ -312,11 +312,11 @@ class Color {
Yellow, Orange, Red, Magenta, Blue, Cyan, Green, Pink, Black, White
};
};
</PRE></div>
</pre></div>
<p>A workaround is to write these as a series of separated classes containing anonymous enums:</p>
<div class="code"><PRE>
<div class="code"><pre>
class PrintingColors {
enum : unsigned int {
Cyan, Magenta, Yellow, Black
@ -334,7 +334,7 @@ class AllColors {
Yellow, Orange, Red, Magenta, Blue, Cyan, Green, Pink, Black, White
};
};
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Double_angle_brackets"></a>7.2.13 Double angle brackets</H3>
@ -343,17 +343,17 @@ class AllColors {
template block, if found inside it at the top level, or as the right
shift operator &gt;&gt; otherwise.</p>
<div class="code"><PRE>
<div class="code"><pre>
std::vector&lt;std::vector&lt;int&gt;&gt; myIntTable;
</PRE></div>
</pre></div>
<p>The bit shifting operator using the parenthesis
around the expressions can be forced. For example</p>
<div class="code"><PRE>
<div class="code"><pre>
template&lt;(5&gt;&gt;3)&gt;
class A {};
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Explicit_conversion_operators"></a>7.2.14 Explicit conversion operators</H3>
@ -361,7 +361,7 @@ class A {};
<p>SWIG correctly parses the keyword <tt>explicit</tt> both for operators and constructors.
For example:</p>
<div class="code"><PRE>
<div class="code"><pre>
class U {
public:
int u;
@ -381,7 +381,7 @@ public:
int t;
};
</PRE></div>
</pre></div>
<p>
The usage of explicit constructors and operators is somehow specific to C++ when assigning the value
@ -397,15 +397,15 @@ to achieve particular copy and compare behaviours.
<p>SWIG currently parses the new <tt>using name =</tt> syntax, but
ignores the definition:</p>
<div class="code"><PRE>
<div class="code"><pre>
using PFD = void (*)(double); // New introduced syntax
</PRE></div>
</pre></div>
<p>You should still define the typedefs using the old syntax:</p>
<div class="code"><PRE>
<div class="code"><pre>
typedef void (*PFD)(double); // The old style
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Unrestricted_unions"></a>7.2.16 Unrestricted unions</H3>
@ -414,7 +414,7 @@ typedef void (*PFD)(double); // The old style
define the trivial constructor. For example, the wrapper for the following
code is correctly produced:</p>
<div class="code"><PRE>
<div class="code"><pre>
struct point {
point() {}
point(int x, int y): x_(x), y_(y) {}
@ -426,7 +426,7 @@ union P {
double w;
point p; // Illegal in C++; point has a non-trivial constructor. However, this is legal in C++0x.
} p1;
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Variadic_templates"></a>7.2.17 Variadic templates</H3>
@ -435,34 +435,34 @@ union P {
block, variadic class inheritance and variadic constructor and
initializers) with some limitations. The following code is correctly parsed:</p>
<div class="code"><PRE>
<div class="code"><pre>
template &lt;typename... BaseClasses&gt; class ClassName : public BaseClasses... {
public:
ClassName (BaseClasses&amp;&amp;... baseClasses) : BaseClasses(baseClasses)... {}
}
</PRE></div>
</pre></div>
<p>Support for the variadic sizeof() function was also introduced:</p>
<div class="code"><PRE>
<div class="code"><pre>
const int SIZE = sizeof...(ClassName&lt;int, int&gt;);
</PRE></div>
</pre></div>
<p>For now however, the <tt>%template</tt> directive only accepts at most the number of
arguments defined in the original template&lt;&gt; block:</p>
<div class="code"><PRE>
<div class="code"><pre>
%template(MyVariant1) ClassName&lt;&gt; // ok
%template(MyVariant2) ClassName&lt;int&gt; // ok
%template(MyVariant3) ClassName&lt;int, int&gt; // too many arguments
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_New_string_literals"></a>7.2.18 New string literals</H3>
<p>SWIG fully supports unicode string constants and raw string literals.</p>
<div class="code"><PRE>
<div class="code"><pre>
// New string literals
wstring aa = L"Wide string";
const char *bb = u8"UTF-8 string";
@ -476,7 +476,7 @@ wstring ff = LR"XXX(I'm a "raw wide" \ string.)XXX";
const char *gg = u8R"XXX(I'm a "raw UTF-8" \ string.)XXX";
const char16_t *hh = uR"XXX(I'm a "raw UTF-16" \ string.)XXX";
const char32_t *ii = UR"XXX(I'm a "raw UTF-32" \ string.)XXX";
</PRE></div>
</pre></div>
<p>Note: SWIG currently incorrectly parses the odd number of double quotes
inside the string due to SWIG's C++ preprocessor.</p>
@ -486,13 +486,13 @@ inside the string due to SWIG's C++ preprocessor.</p>
<p>SWIG correctly parses the new <tt>operator""_mysuffix()</tt> functions.</p>
<div class="code"><PRE>
<div class="code"><pre>
OutputType operator "" _mySuffix(const char * string_values, size_t num_chars);
OutputType operator "" _mySuffix(const wchar_t * string_values, size_t num_chars);
OutputType operator "" _mySuffix(const char16_t * string_values, size_t num_chars);
OutputType operator "" _mySuffix(const char32_t * string_values, size_t num_chars);
OutputType operator "" _mySuffix(int value);
</PRE></div>
</pre></div>
<p>The %rename currently doesn't parse the double quotes. Please
rename the functions in the code using the #define preprocessor directive.</p>
@ -503,11 +503,11 @@ rename the functions in the code using the #define preprocessor directive.</p>
<p>SWIG correctly parses the <tt>thread_local</tt> keyword. For example, a variable
reachable by the current thread can be defined as:</p>
<div class="code"><PRE>
<div class="code"><pre>
struct A {
thread_local int val;
};
</PRE></div>
</pre></div>
<p>The new C++0x threading libraries are ignored because each SWIG target language offers
its own threading facilities.</p>
@ -518,14 +518,14 @@ its own threading facilities.</p>
<p>SWIG correctly parses the <tt>= delete</tt> and <tt>= default</tt>
keywords. For example:</p>
<div class="code"><PRE>
<div class="code"><pre>
struct NonCopyable {
NonCopyable&amp; operator=(const NonCopyable&amp;) = delete; /* Removes operator= */
NonCopyable(const NonCopyable&amp;) = delete; /* Removed copy constructor */
NonCopyable() = default; /* Explicitly allows the empty constructor */
void *operator new(std::size_t) = delete; /* Removes new NonCopyable */
};
</PRE></div>
</pre></div>
<p>This feature is specific to C++ only. The defaulting/deleting is currently ignored, because SWIG
automatically produces wrappers for special constructors and operators specific to the target language.</p>
@ -540,12 +540,12 @@ automatically produces wrappers for special constructors and operators specific
<p>SWIG correctly parses and calls the new <tt>static_assert</tt> function.</p>
<div class="code"><PRE>
<div class="code"><pre>
template &lt;typename T&gt;
struct Check {
static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
};
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Allow_sizeof_to_work_on_members_of_classes_without_an_explicit_object"></a>7.2.24 Allow sizeof to work on members of classes without an explicit object</H3>
@ -553,19 +553,19 @@ struct Check {
<p>SWIG correctly calls the sizeof() on types as well as on the
objects. For example:</p>
<div class="code"><PRE>
<div class="code"><pre>
struct A {
int member;
};
const int SIZE = sizeof(A::member); // does not work with C++03. Okay with C++0x
</PRE></div>
</pre></div>
<p>In Python:</p>
<div class="targetlang"><PRE>
<div class="targetlang"><pre>
&gt;&gt;&gt; SIZE
8
</PRE></div>
</pre></div>
<H2><a name="Cpp0x_Standard_library_changes"></a>7.3 Standard library changes</H2>
@ -603,7 +603,7 @@ include the tuple header file; it is parsed without any problems.</p>
<p>The new ref and cref classes are used to instantiate a parameter as a reference of a template function. For example:</p>
<div class="code"><PRE>
<div class="code"><pre>
void f( int &amp;r ) { r++; }
// Template function.
@ -619,7 +619,7 @@ int main() {
// then 'i' will be modified.
cout &lt;&lt; i &lt;&lt; endl ; // Output -&gt; 1
}
</PRE></div>
</pre></div>
<p>The ref and cref classes are not wrapped by SWIG because the SWIG target languages do not support referencing.</p>
@ -628,20 +628,20 @@ int main() {
<p>SWIG fully supports function template wrappers and function objects:</p>
<div class="code"><PRE>
<div class="code"><pre>
function&lt;int ( int, int )&gt; pF; // function template wrapper
struct Test {
bool operator()( short x, short y ); // function object
};
</PRE></div>
</pre></div>
<H3><a name="Cpp0x_Type_traits_for_metaprogramming"></a>7.3.8 Type traits for metaprogramming</H3>
<p>The new C++ metaprogramming is useful at compile time and is aimed specifically for C++ development:</p>
<div class="code"><PRE>
<div class="code"><pre>
// First way of operating.
template&lt; bool B &gt; struct algorithm {
template&lt; class T1, class T2 &gt; int do_it( T1&amp;, T2&amp; ) { /*...*/ }
@ -656,7 +656,7 @@ template&lt; class T1, class T2 &gt; int elaborate( T1 A, T2 B ) {
// in floating point, otherwise use the first way.
return algorithm&lt; is_integral&lt;T1&gt;::value &amp;&amp; is_floating_point&lt;T2&gt;::value &gt;::do_it( A, B );
}
</PRE></div>
</pre></div>
<p>SWIG correctly parses the template specialization, template types and values inside the &lt;&gt; block and the new helper functions: is_convertible, is_integral, is_const etc.
However, SWIG still explicitly requires concrete types when using the <tt>%template</tt> directive, so the C++ metaprogramming features are not really of interest at runtime in the target languages.</p>
@ -665,7 +665,7 @@ However, SWIG still explicitly requires concrete types when using the <tt>%templ
<p>SWIG does not wrap the new result_of class introduced in the &lt;functional&gt; header and map the result_of::type to the concrete type yet. For example:</p>
<div class="code"><PRE>
<div class="code"><pre>
%inline %{
#include &lt;functional&gt;
double square(double x) {
@ -680,15 +680,15 @@ typename std::result_of&lt;Fun(Arg)&gt;::type test_result_impl(Fun fun, Arg arg)
%template(test_result) test_result_impl&lt;double(*)(double), double&gt;;
%constant double (*SQUARE)(double) = square;
</PRE></div>
</pre></div>
<p>will result in:</p>
<div class="targetlang"><PRE>
<div class="targetlang"><pre>
&gt;&gt;&gt; test_result_impl(SQUARE, 5.0)
&lt;SWIG Object of type 'std::result_of&lt; Fun(Arg) &gt;::type *' at 0x7faf99ed8a50&gt;
</PRE></div>
</pre></div>
<p>Instead, please use <tt>decltype()</tt> where possible for now.</p>
</BODY>
</HTML>
</body>
</html>