Update on the C++-0x Language Standard
Hello: the standards body that controls the C++ language (SC22/WG21) is in the process of revising the C++ language – this new revision of the C++ language, which is currently known as C++-0x, should be finished and approved by the end of the decade. As part of this process at the recent meeting of this committee (near Oxford, England) several new language features were added to the current Working Paper for the C++-0x Standard.
New character types in C++
This adds the keywords char16_t and char32_t as well as u”…” and U”…” and u’<char>’ and U’<char>’ literals. Together these new language features give a user a way to encode a 16-bit (i.e. UTF-16) string literal/character constant and a 32-bit (i.e. UTF-32) string-literal/character-constant. The proposal also includes some library functionality.
Template Aliases
This feature has been around for a while and was finally approved for inclusion in the C++ Standard. It allows for code like the following:
#include <vector>
template<typename T>
class MyAllocator {
};
template<typename T>
using MyVector = std::vector<T, MyAllocator<T>>;
MyVector<int> vec;
Note: those amongst you with sharp eyes might notice that the nested template argument list in the example above ends with ‘>>’ instead of ‘> >’ this is because one of the first changes to the C++-0x Standard was to get rid of the need to insert whitespace between the nested ‘>’ terminators when closing multiple template arguments lists.
Sequence Points Revised
This shouldn’t actually change anything in the C++ language it just provides clearer wording – it gets rid of the term “sequence point” and instead describes an operation A being sequenced before an operation B (i.e. the evaluation of the arguments of a function call are sequenced before the execution of every expression or statement in the body of the function) or being un-sequenced (i.e. the evaluation of the different arguments of a function call are un-sequenced wrt each other).
It is hoped that this paper will lay the foundation for the future C++ memory model work – especially the concurrency aspects. The should review papers and proposed wording on the memory model and concurrency at the upcoming meetings.
Variadic Templates
This was the biggest feature that was added this time around. It allows for code like the following:
template<typename... Mixins>
class X : public Mixins...{
public:
X(const Mixins&... mixins) : Mixins(mixins)...
{
}
};
If you specialized this class with say:
class A { };
class B { };
class C { };
X<A, B, C> x;
Then the compiler will generate the following specialization:
class X<A, B, C> : public A, public B, public C {
public:
X(A const& __a, B const& __b, C const& __c) : A(__a), B(__b), C(__c)
{
}
};
This feature has a big impact on class templates like tuple and according to Doug Gregor it can lead to a huge compiler-time performance boost – as the compiler now only has to process one class template instead of N (where I believe for tuple N is usually 20). One unintentional side-effect of this feature is that it makes the following well formed:
class<typename… Types>
struct X {
void f(Types......);
};
Yes – that is six ‘.’ in a row J.
As this feature was approved the Library Working-Group went ahead and updated the Library sections of the Working Paper to make appropriate use of Variadic Templates.
Allow sizeof to apply to non-static data members
Currently the C++ Standard does not allow the following:
struct S {
int m;
};
sizeof(S::m)
This featurette makes such code legal.
Generalized Constant Expressions
This feature was almost approved but at the last minute Core decided to withdraw it. A Generalized Constant Expression is something like the following:
constexpr int square(int x)
{
return x * x;
}
This feature really helps in situations (like bitmasks) where the result of the expression is not strictly a constant expression because, for example. it involves a cast; or for cases where a function call is required and thus turns a static initialization into a dynamic initialization (Note: I suspect that Visual C++ would currently convert these dynamic initializations back into static initializations).
The problem that came up is that as these are constant-expressions they are valid as non-type template arguments but as they are also functions there use could require a compiler to do overload resolution during template-argument deduction. This is very similar to core issue – 339 which deals with function calls within sizeof expressions. It was decided that Core would hold off on approving Generalized Constant Expressions until this issue is resolved – which we hope to do at the next meeting.
The next meeting of SC22/WG21 will be in Toronto in July. At this meeting it is hoped that the committee will start to approve some of the larger changes to the C++ language: this includes features like concepts and the memory model/concurrency proposals. Hopefully after the Toronto meeting I’ll be able to update you on the further progress of the C++ Committee.
Jonathan Caves
