diff --git a/Doc/Devel/cpp0x.html b/Doc/Devel/cpp0x.html new file mode 100644 index 000000000..4afc5ffe4 --- /dev/null +++ b/Doc/Devel/cpp0x.html @@ -0,0 +1,788 @@ + + +
+ +This is a technical overview of the C++0x support for the Swig. +This area of Swig is a work in progress. Initial C++0x support for +Swig was written during the Google Summer of Code 2009 period by +Matevž Jekovec.
+branches/gsoc2009-matevz
+Wikipedia article: http://en.wikipedia.org/wiki/C%2B%2B0x +
+The Rvalues are used in practice to speed up the move operations +on different containers.
+In the following example, we want to swap the given elements:
+template <class T> swap(T& a, T& b) {
+ T tmp(a); // now we have two copies of a
+ a = b; // now we have two copies of b
+ b = tmp; // now we have two copies of tmp (aka a)
+}+This can now be solved using the new function std::move():
+template <class T> swap(T& a, T& b) {
+ T tmp(std::move(a));
+ a = std::move(b);
+ b = std::move(tmp);
+}+For the move function to take effect, user needs to reimplement the +move constructor (taking ClassType&& as an argument) and +operator=(ClassType&&):
+class MyClass {
+ MyClass(MyClass&& p) : ptr(p.ptr) {p.ptr = 0;}
+ MyClass& operator=(MyClass&& p) {
+ std::swap(ptr, p.ptr);
+ return *this;
+ }
+};+In practice, the Rvalues are used for temporaries (when passing the +result of one function as an argument to another).
+Done: Added type&& to Swig parser. Added testcase +cpp0x_rvalue_reference.i. Operator && is treated the same as +operator &. R11450
+Article: +http://www.artima.com/cppsource/rvalue.html
+In C++0x you can define functions as constant expressions. +Functions need to return constant value in form "return expr", +where expr is a constant expression. +
+A keyword "constexpr" is introduced for this. eg.: +constexpr int getNumber() { return 5; } const int MY_CONSTANT = +getNumber(); +
+Constants are treated as normal variables in interpreted languages +because they are not compiled into the executable. Java "final" +constants are defined runtime as well. C++ constants need to be +declared in the header file and defined in the implementation file, +so swig doesn't need to know about the constant values when parsing +the header file. +
+Done: Added the “constexpr “ keyword to Swig. Added testcase +cpp0x_constexpr. R11322
+Problem: No compilers were known to support constexpr yet, so the +testcase was temporarily commented out in common.mk. +
+Extern template forces the GCC compiler to not instantiate the +template in the translation unit at that time. It's a feature +specifically aimed at compilers to speed up the compilation process. +
+Done: Added support for 'extern template class +std::vector<MyClass>;'. Added testcase cpp0x_template_explicit. +R11385 , R11386
+Initializer list is a new type in standard library: +std::initializer_list<T>. New symbols {} are introduced for the +initializer lists. +
+One can now use: +
+ class A {
+ public:
+ A( std::initializer_list<int> );
+ };
+ A a1 = {1,2,3,4};+Languages like Java, C# and Python already support direct creation of +lists natively.
+Problem: initializer_list cannot be treated as an ordinary list. +The constructor containing initializer_list can only be accessed by +assigning the value using the {} brackets. I also don't think there +is a simple way to convert an ordinary list or a vector to the +initializer_list.
+Done: Ignored the constructor having initializer_list as its +argument. Show warning to the user. Added testcase +cpp0x_initializer_list. R11450
+Article: +http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1919.pdf
+The new C++0x standard will allow the following:
+struct IdString {
+ std::string name;
+ int identifier;
+};
+
+IdString GetString() {
+ return {"SomeName", 4}; //Note the lack of explicit type.
+}+The feature works exactly as it did now for POD types only (eg. int +a[] = {1,2,3};). The following declarations are the same in the new +C++0x:
+IdString str1 = {„SomeName“, 4};
+IdString str2{„SomeName“, 4};+The new way of using uniform initialization allows the following:
+struct BasicStruct {
+ int x;
+ double y;
+};
+
+struct AltStruct {
+ AltStruct(int x, double y) : x_{x}, y_{y} {}
+
+private:
+ int x_;
+ double y_;
+};
+
+BasicStruct var1{5, 3.2}; // only fills the struct components
+AltStruct var2{2, 4.3}; // calls the constructor+The new syntax is specific to C++. Java, C# and scripting languages +do not support this behaviour, but always need constructors. They +support {} brackets for declaration of arrays as C does + they add +support for creation of arrays on-the-fly (what c++0x introduced with +this feature and more).
+Done: Added syntax for {} member initialization in class +constructor. Added testcase cpp0x_uniform_initialization. R11413
+A new keyword 'auto' is introduced in C++0x:
+auto a1 = 100; +auto a2 = myFunc();
+The type of a1 and a2 is automatically determined according to the +initialization value during the semantic phase of the compiler.
+Another macro 'decltype()' is introduced. The macro takes the +concrete object as an argument and returns its type. User could use +this as:
+int i = 100; +decltype(i) j = 200; // decltype(i) = int
+Calling operators are allowed as well:
+decltype(i+j) k = 300;
+Done: Added support for decltype() syntax. Test cases for normal +decltype members and alternate function members work fine. Currently +only syntax in form decltype(variable name) work. No support for +custom expresions eg. decltype(i+j) yet. R11525
+TODO: William proposed to support the hidden variables as well +(ones not parsed by Swig and added to symbol table). This also allows +Swig to parse custom expressions like decltype(i+j). The idea is to +introduce a new SwigType for this.
+This feature is always present inside the implementation block +only. +
+C++0x introduces lambda functions defined as:
+[](int x, int y) -> int { return x + y; }+If the lambda function contains a single return statement only or the +function doesn't return any type, the return type '->' can be +omitted. Lambda functions are function objects.
+The following example prints the number of items stored in a list:
+std::vector<int> someList;
+int total = 0;
+std::for_each( someList.begin(), someList.end(), [&total](int x) {total += x} );
+std::cout << total;+Parameters inside the [] are the visible parameters of the lambda +functions. These can be & (references), = (copies), variable name +(variable copy), &variable name (variable reference) or this +(copy of the current object).
+Lambda functions can be stored using:
+auto myLambdaFunc = [this]() { this->SomePrivateMemberFunction() };+Proposal: Lambda functions are most commonly used inside the function +block to quickly define how the sort, find and similar functions +should work (the other way would be overriding a class – the Java +style). The latest GCC does not support lambda functions yet so it is +difficult to test the feature once implemented. I would implement the +syntax support for this feature, but produce no wrapper code. Lambda +functions still work inside the function block though.
+Article: +http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf
+Done: Added syntax support for the lambda functions. Added +testcase cpp0x_lambda_functions.i. R11491, R11492
+The problem with decltype() is that the parameters need to be +defined before the decltype. The following syntax is not valid, +because lhs and rhs hasn't been defined at the time of decltype:
+template< typename LHS, typename RHS>
+ decltype(lhs+rhs) AddingFunc(const LHS &lhs, const RHS &rhs) {return lhs + rhs;} //Not legal C++0x+The solution C++0x offers is the combination of the 'auto' keyword +before and '-> rettype' after the function declaration:
+template< typename LHS, typename RHS>
+ auto AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return lhs + rhs;}+The new syntax only makes the job for the C++ compilers easier when +parsing such functions. The new syntax can be used for ordinary +functions as well:
+struct SomeStruct {
+ auto FuncName(int x, int y) -> int;
+};
+
+auto SomeStruct::FuncName(int x, int y) -> int {
+ return x + y;
+}+Done: Added support for the 'auto' return type. Added support for the +'-> type' after the funtion declaration. Added testcases +cpp0x_alternate_function_syntax.i and +cpp0x_alternate_function_syntax_runme.py. R11414
+In C++ there is a common problem when you use a template in the +class which doesn't support all the operations the functions in the +class actually do on the type. Compiler errors are usually very long +and unreadable. C++0x adds support for the "concepts". The +idea is to define what operations and attributes should the template +have. In contrast to class inheritance and polimorphism, all lookups +are done in compile-time. +
+Basic syntax (note LessThanComparable? +instead of "class" or "typename"): +
+ template<LessThanComparable? T>
+ const T& min(const T &x, const T &y) {
+ return y < x ? y : x;
+ }+Extended syntax (requires conditions are separated with &&, +|| or !): +
+ template< typename T> requires LessThanComparable?<T>
+ const T& min(const T &x, const T &y) {
+ return y < x ? y : x;
+ }+Definition of the concepts: +
+ concept LessThanComparable?< typename T > {
+ bool operator<(T,T);
+ requires GreaterThanComparable?<T>;
+ typename value_type;
+ typename reference;
+ };+Concept maps allow usage of a specific type: +
+ template< typename T>
+ concept_map InputIterator?<T*> {
+ typedef T value_type ;
+ typedef T& reference ;
+ typedef T* pointer ;
+ typedef std::ptrdiff_t difference_type ;
+ };+Concept maps can act as mini-types, with function definitions and +other constructs commonly associated with classes: +
+ concept Stack< typename X> {
+ typename value_type;
+ void push(X&, const value_type&);
+ void pop(X&);
+ value_type top(const X&);
+ bool empty(const X&);
+ };
+ template< typename T>
+ concept_map Stack<std::vector<T> > {
+ typedef T value_type;
+ void push(std::vector<T>& v, const T& x) { v.push_back(x); }
+ void pop(std::vector<T>& v) { v.pop_back(); }
+ T top(const std::vector<T>& v) { return v.back(); }
+ bool empty(const std::vector<T>& v) { return v.empty(); }
+ };+Axioms are a facility pertaining to concepts supplied by C++0x to +express the semantic properties of concepts. For example, the concept +Semigroup can be defined with an axiom Associativity as: +
+ concept Semigroup< typename Op, typename T> : CopyConstructible?<T> {
+ T operator()(Op, T, T);
+ axiom Associativity(Op op, T x, T y, T z) {
+ op(x, op(y, z)) == op(op(x, y), z);
+ }
+ };+Axioms are more like hints to the compiler to speed-up the process of +compilation. +
+Ignored: Concepts and axioms were removed from the C++0x standard. +
+This feature allows classes constructors to call other +constructors with different arguments (similar to Java and C# +behaviour). +
+The syntax is as follows: +
+ class SomeType {
+ int number;
+ public:
+ SomeType(int newNumber) : number(newNumber) {}
+ SomeType() : SomeType(42) {}
+ };+Also when using the inheritance, the feature introduces inheritance +of all superclass constructors without being defined separately in +the inherited class: +
+ class BaseClass {
+ public:
+ BaseClass(int iValue);
+ };
+ class DerivedClass: public BaseClass {
+ public:
+ using BaseClass::BaseClass; // Adds DerivedClass(int) constructor
+ };+Swig already correctly parses and produces the correct wrapper for +the “using” keyword.
+Done: Added testcase cpp0x_constructors.i which covers both +constructor delegation and constructor inheritance. R11532
+Problem: Constructor delegation and constructor inheritance is not +supported by any compiler yet, so it's impossible to try and test +this feature.
+nullptr is part of the standard library. +
+It's defined as typedef decltype(nullptr) nullptr_t; +
+nullptr_t is defined in <cstddef>. +
+As far as the C++ is compatible with 0 as the pointer value, swig +values will work for the C++. And the other way around, nullptr +behaves as the ordinary pointer (false, if empty, true, if not +empty), so it's ok for swig to compare it.
+Done: Written a testcase cpp0x_null_pointer_constant.i and +cpp0x_null_pointer_constant_runme.py to prove the nullptr +functionality. R11484
+C++0x introduces a new syntax for strongly typed enum declaration: +
+ enum class Enumeration {
+ Val1,
+ Val2,
+ Val3 = 100,
+ Val4 /* = 101 */
+ };+Typing if (Val4 == 101) will result in compilation error. +
+The enum itself can now be explicitely of type int, long, unsigned +int etc.: +
+ enum class Enum2 : unsigned int {Val1, Val2};+And it can be forward declared as well: +
+enum Enum1; //Illegal in C++ and C++0x; no size is explicitly specified. + enum Enum2 : unsigned int; //Legal in C++0x. + enum class Enum3; //Legal in C++0x, because enum class declarations have a default type of "int". + enum class Enum4: unsigned int; //Legal C++0x. + enum Enum2 : unsigned short; //Illegal in C++0x, because Enum2 was previously declared with a different type.
+Done: Added syntax 'enum class Name' and forward declarators 'enum +Name : inherited type' or 'enum class Name : inherited type' in +R11449.
+TODO: Add semantic support for enum elements not clashing with +enum elements in other enum classes. See cpp0x_strongly_typed_enums.i +warnings.
+Problem: Swig currently doesn't support nested classes. This +feature should be implemented using a new nested class when using +“enum class” with a single anonymous “enum {elements}” +element inside. For example:
+class A { enum class EA { a,b,c,d }; };+should be mapped to
+class A { class EA { enum {a,b,c,d}; }; };Support for right angled brackets was implemented using the +following article as a base: +http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html +
+Done: Added support for angle brackets. Used the preferred +"Approach 1". Added a testcase named +cpp0x_template_double_brackets. R11245
+This is used when converting one type to another (eg. if +(myObject) {}, where myObject is your custom class converted to +bool). +
+Requires both operator and function overloading which is not +supported in any target language (eg. python, php). +
+Done: Swig already supports the keyword "explicit" for +function types as well. Added test case +cpp0x_explicit_conversion_operators. R11323
+The new C++0x will allow creation of wrapper around the template. +For example, if we want to do this:
+template< typename first, typename second, int third> +class SomeType; + +template< typename second> +typedef SomeType<OtherType, second, 5> TypedefName; //Illegal in C++
+This is still illegal! But we can now use the new syntax for +achieving the same effect:
+template< typename first, typename second, int third> +class SomeType; + +template< typename second> +using TypedefName = SomeType<OtherType, second, 5>;
+Here we created a new wrapper TypedefName taking one template +argument <second> which creates a type SomeType<OtherType, +second, 5>. OtherType and 5 are predefined here and hidden from +the user – the user only uses TypedefName type.
+The same goes for the following example:
+typedef void (*PFD)(double); // Old style +using PF = void (*)(double); // New introduced syntax
+Swig supports parsing typedefs for templates as well for example:
+typedef List<int> intList;
+Done: Expanded support for the new 'using' syntax and template +aliasing. Added testcase cpp0x_template_typedefs. R11533
+TODO: Make Swig aware of the newly defined typedef. The TYPEDEF +keyword is part of the storage_class rule and type+declarator (see +c_decl rule) is the right part of the definition – for example void +(*PFD)(double) cannot be transformed to void *(double) easily. To +fully support the new 'using' form, we'll probably have to change the +type, type_right rules and declarator, direct_declarator, +notso_direct_declarator etc., which is PITA.
+C++ currently offers usage of unions for types with trivial +constructors only. The new C++0x standard allows usage of types with +non-trivial constructors as well:
+ struct point {
+ point() {}
+ point(int x, int y): x_(x), y_(y) {}
+ int x_, y_;
+ };
+ union P {
+ int z;
+ double w;
+ point p; // Illegal in C++; point has a non-trivial constructor. However, this is legal in C++0x.
+ } p1;+Swig already parses the given syntax.
+Done: Added testcase cpp0x_unrestricted_unions. R11435, R11447
+Problem: GCC doesn't support unrestricted unions yet so there is +no way to actually test, if it works.
+The new C++0x offers the following syntax:
+template<typename... Values> class tuple;
+This can be used for example:
+class tuple<int, std::vector<int>, std::map<std::string, std::vector<int>>> someInstanceName;
+The ... is used in two cases. One is in the template header where it +marks on the left the keywords 'typename' or 'class' and a type name +on the right. The second case is usually in the function block to +decompose typename on the left of the ... . For example:
+void printf(const char *s) {
+ while (*s) {
+ if (*s == '%' && *(++s) != '%')
+ throw std::runtime_error("invalid format string: missing arguments");
+ std::cout << *s++;
+ }
+}
+
+template<typename T, typename... Args>
+void printf(const char* s, T value, Args... args) { // recursive action – split previous args to value + args
+ while (*s) {
+ if (*s == '%' && *(++s) != '%') {
+ std::cout << value;
+ printf(*s ? ++s : s, args...); // call even when *s == 0 to detect extra arguments
+ return;
+ }
+ std::cout << *s++;
+ }
+ throw std::logic_error("extra arguments provided to printf");
+}+The tricky part is that variadic templates can unpack actually +anywhere – including the class inheritance :(
+template <typename... BaseClasses> class ClassName : public BaseClasses... {
+public:
+
+ ClassName (BaseClasses&&... baseClasses) : BaseClasses(baseClasses)... {}
+}+A new extension to sizeof is also introduced with this feature. The +... after sizeof returns number of arguments:
+template<typename ...Args> struct SomeStruct {
+ static const int size = sizeof...(Args);
+}
+// SomeStruct<Type1, Type2>::size is 2 and SomeStruct<>::size is 0+Done: Added syntax support for 'typename' or 'class' + ... + id. +Added testcase cpp0x_variadic_templates. R11458
+Done: Added syntax support for BaseClass + ..., type + ... + id in +parameters and baseclass + ... for intializers after constructor. +Extended Swig syntax to support sizeof...(Args). R11467
+Done: Fixed %template to support variadic number of templates.
+TODO: Only (if present) first variadically defined argument is +currently used in %template directive. The next ones are ignored.
+Beside the implementation, the new C++0x Unicode and custom +delimeter constants can occur in templates in the header file. +
+Done: Added symbols 'u', 'u8' and 'U' to mark the beginning of the +UTF string. Also added test case cpp0x_raw_string_literals. R11327
+Done: Added R"DELIMITER[, ]DELIMITER" for a custom +delimiter for the beginning/end of the string. R11328
+TODO: Fix the Swig's C++ preprocessor bug when parsing an odd +number of “ inside the string brackets. See +Source/Preprocessor/cpp.c.
+C++ has different suffix literals. eg. 12.5f marks the number 12.5 +as float. +
+C++0x allows user to define his own suffix for the strings always +starting with the underscore (_). eg. int a = "hello"_mySuffix; +
+The syntax is similar to other operator overloading functions: +
+OutputType operator "" _mySuffix(const char * string_values);
+The null terminated const char* is the string between the "". +The _mySuffix is the name of the suffix operator. And the OutputType +is the outputType the operator returns. +
+Other forms are: +
+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); /* cooked version - ie. atoi() of string */
+Another possibility is to use variadic templates: +
+template<char...> OutputType operator "" _mySuffix(); + OutputType someVariable = "1234"_mySuffix;
+This instantiates the literal processing function as +operator""_Suffix<'1', '2', '3', '4'>. In this form, +there is no terminating null character to the string. The main +purpose to doing this is to use C++0x's constexpr keyword and the +compiler to allow the literal to be transformed entirely at compile +time, assuming OutputType is a constexpr-constructable and copyable +type, and the literal processing function is a constexpr function.
+Article: +http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf
+Done: Added syntax support for userdefined literals. Added +testcase cpp0x_userdefined_literals.i. R11494
+TODO: %rename doesn't parse operator”” yet.
+New C++0x introduces keyword "thread_local" which marks +the following variable dynamically located depending on the current +thread when using the address-of (&) operator. +
+Syntax: +
+ struct A {
+ thread_local int val;
+ };+Done: Add "thread_local" keyword to Swig. Added testcase +cpp0x_thread_local. R11393
+C++ automatically creates default constructor with empty +parameters, copy constructor, operator= and destructor for any class. +Sometimes user wants to explicitly remove one of them or enable them +(eg. default constructor with empty parameters doesn't work any more, +if any other constructor is defined). +
+Words "default" and "delete" are introduced. +The syntax is similar to declaration of pure virtual function: +
+ struct NonCopyable {
+ NonCopyable & operator=(const NonCopyable&) = delete; /* Removes operator= */
+ NonCopyable(const NonCopyable&) = delete; /* Removed copy constructor */
+ NonCopyable() = default; /* Explicitly allows the empty constructor */
+ void *operator new(std::size_t) = delete; /* Removes new NonCopyable */
+ };+User has the ability by using keyword delete to disallow calling of +the standard functions brought by C++ itself. +
+ struct A1 {
+ void f(int i);
+ void f(double i) = delete; /* Don't cast double to int. Compiler returns an error */
+ };
+ struct A2 {
+ void f(int i);
+ template<class T> void f(T) = delete; /* Only accept int */
+ };+Ignored: Swig already parses the keywords "= delete" and "= +default". These keywords are used for built-in functions (copy +constructor, operator= etc.), which are ignored by Swig anyway.
+Done: Added testcase cpp0x_default_delete. R11535
+Type long long int is an integer type that has at least 64 useful +bits. C99 added it to its standard, but the C++ didn't adopt it until +C++0x. Most C++ compilers supported it though. +
+Done: Swig already parses the C code including the long long type. +
+static_assert() can be used at class scope as well eg.: +
+ template <typename T>
+ struct Check {
+ static_assert(sizeof(int) <= sizeof(T), "not big enough");
+ };+Done: Added syntax support for "static_assert()". Added +test case cpp0x_static_assert. R11369
+C++0x allows calls of sizeof to concrete objects as well: +
+ struct A { int member; };
+ sizeof(A::member); //Does not work with C++03. Okay with C++0x+This kind of syntax is already supported by Swig.
+Done: Added testcase cpp0x_sizeof_objects. R11538 +
+C++0x will add the following classes to the standard library: +
+* std::thread + * std::mutex, std::recursive_mutex + * std::condition_variable, std::condition_variable_any + * std::lock_guard, std::unique_lock + * std::packaged_task
+Ignored: No changes to the language itself is made. +
+Tuple is array of various types. C++0x introduced this feature +using variadic templates. Tuple is defined as:
+template <class ...Types> class tuple;
+Constructor is automatically generated filling the tuple elements. +get<X> function is introduced to get the Xth element in the +tuple.
+typedef tuple< int, double, long &, const char * > test_tuple ; +long lengthy = 12 ; +test_tuple proof( 18, 6.5, lengthy, "Ciao!" ) ; +lengthy = get<0>(proof) ; // Assign to 'lengthy' the value 18. +get<3>(proof) = " Beautiful!" ; // Modify the tuple’s fourth element.
+Tuples can be copied to each other, if all the elements are copiable:
+typedef tuple< int , double, string > tuple_1 t1 ; +typedef tuple< char, short , const char * > tuple_2 t2( 'X', 2, "Hola!" ) ; +t1 = t2 ; // Ok, first two elements can be converted, + // the third one can be constructed from a 'const char *'.
+TODO: Implement wrappers for the tuplet<> class.
+C++0x introduces the "unordered" version of existing +types, which in practice work faster than the linear types: +
+- unordered set + - unordered multiset + - unordered map + - unordered multimap
+Swig should use the "unordered" types exactly the same as +the original linear types.
+Problem: Unordered types do not contain exactly same members as +ordered ones (eg. _Hashtable_iterator does not offer operator--() and +constructor with compare function which is required). So simply +aliasing unordered classes to ordered ones doesn't work.
+TODO: Implement wrappers for unordered_ types. Initial work is +already done in Lib/std/unordered_*.i files.
+Two new classes are introduced in C++0x: basic_regex and +match_results. Both are defined in regex header file. +
+Ignored: The new feature extends the standardy library only. No +changes to Swig needed. +
+This feature deprecates auto_ptr and adds shared_ptr, weak_ptr and +unique_ptr to the standard library. +
+This feature only adds the smart pointers to the standard library +and doesn't effect the C++ syntax.
+Done: Added test case which uses all three smart pointers in the +class. R11394
+Problem: GCC standard library doesn't contain the new smart +pointers yet. +
+This feature standardize the pseudo random number algorithm +(currently, the random number generator was dependent on the +platform/compiler). It adds functions linear_congruential, +subtract_with_carry and mersenne_twister and symbols +uniform_int_distribution, bernoulli_distribution, +geometric_distribution, poisson_distribution, binomial_distribution, +uniform_real_distribution, exponential_distribution, +normal_distribution and gamma_distribution to the standard library. +
+Ignored: The new feature extends the standardy library only. No +changes to Swig needed. +
+This feature adds ref and cref classes to the standard library +(#include <utility>) usually used in tempalte functions. +
+Ignored: The new feature extends the standardy library only. No +changes to Swig needed. +
+Two features are introduced: +
+The function template wrapper: +
+function<int ( int, int )> pF;+
and the function object: +
+ struct Test {
+ bool operator()( short x, short y );
+ };+Swig already supports the two.
+Done: Added a runtime testcase for function objects +cpp0x_function_objects. R11419.
+C++0x adds a new header file <type_traits> which includes +helper functions to determine the template type while initializing +the object at compile time. +
+Swig already supports the following code: +
+ template< int B, int N >
+ struct Pow {
+ // recursive call and recombination.
+ enum{ value = B*Pow< B, N-1 >::value };
+ };
+ template< int B > struct Pow< B, 0 > // N == 0 condition of termination.
+ {
+ enum{ value = 1 };
+ };
+ int quartic_of_three = Pow< 3, 4 >::value ;+Functions is_convertible, is_integral, is_integral_const etc. are +part of the new header: +
+// First way of operating.
+template< bool B > struct algorithm {
+ template< class T1, class T2 > int do_it( T1 &, T2 & ) { /*...*/ }
+};
+// Second way of operating.
+template<> struct algorithm<true> {
+ template< class T1, class T2 > int do_it( T1, T2 ) { /*...*/ }
+};
+// Instantiating 'elaborate' will automatically instantiate the correct way to operate.
+template< class T1, class T2 > int elaborate( T1 A, T2 B ) {
+ // Use the second way only if 'T1' is an integer and if 'T2' is
+ // in floating point, otherwise use the first way.
+ return algorithm< is_integral<T1>::value && is_floating_point<T2>::value >::do_it( A, B );
+}+Swig correctly parses the syntax for template<bool>, +template<class T> and template<>. +
+Ignored: Swig requires explicitly defined template class +(%template directive) to export it to the target language.
+The template function is introduced: std::result_of() which +depends on decltype: +
+template< class Obj >
+class calculus_ver2 {
+ public:
+ template< class Arg >
+ typename std::result_of<Obj(Arg)>::type operator()( Arg& a ) const {
+ return member(a);
+ }
+ private:
+ Obj member;
+};+Swig correctly parses the result_of class.
+TODO: The return type (the result_of::type member) is not +calculated by Swig. This needs a much more complex semantic parser.
+Done: Added testcase cpp0x_result_of. R11534
+ + \ No newline at end of file