The International Standards Organization (ISO) recommends a 10-year revision cycle for its standards, so we are currently fast approaching a new version of the C++ standard. In the C++ development community, the standard has received the moniker C++0x, meaning that its publication is expected within the decade.

The first edition of the C++ standard was published in 1998. Since then, C++ developers all over the world have amassed a wealth of experience in using standard language features and the standard library, making a critical (and constructive) evaluation possible, with a vast array of proposals for future language development.

The International Standards Organization (ISO) recommends a 10-year revision cycle for its standards, so we are currently fast approaching a new version of the C++ standard. In the C++ development community, the standard has received the moniker C++0x, meaning that its publication is expected within the decade.

Aims for the new standard

The main aim of the new standard is not to create or support any particular programming paradigm, or to win any new market segments. The evolution of C++ is intended to further strengthen its foothold in its current domains of widely understood systems programming and library development.

A vital consideration in creating the new standard is that C++ should remain a highly effective library authoring tool. To this end, the majority of additions and enhancements will be placed in the standard library, with core language extensions being limited to those that generally support and facilitate library use and development. Considering the requirement for compatibility with vast amounts of existing C++ code, no significant language constructs will be removed. While this does mean that oft-criticised C++ features that many consider dangerous will stay in the language (much to the chagrin of programming language revolutionaries), it also means that more secure alternatives will be provided.

It’s also worth noting that while C++ is generally considered a complex language with a steep learning curve, experienced programmers are by no means its only user group. C++ is also used to teach programming and by domain experts (for example physicists or astronomers) who develop specialist software for their own needs, but have no interest in learning the language at an expert level. Both these uses will be addressed by language features intended to make C++ programming easier.

Proposals for new language features are submitted all the time by C++ enthusiasts and standardisation committee members alike (the comp.std.c++ newsgroup is the place to do this), independently of actual standardisation efforts, so a timeline has been established to limit the scope of discussion and allow standardisation to be completed within a sensible time. No more proposals concerning the language core are now accepted, and technical work on the new standard must be completed by the end of 2007. ISO procedures will follow, and if everything goes as planned, the new standard will officially be published in 2009.

An in-joke among committee members is that if they don’t finish work on time (which has already happened for the previous standard), the name C++0x will still be valid - but in hexadecimal.

It’s also worth mentioning the technical corrigenda and technical reports that are released between subsequent ISO standard versions. For C++, these are Technical Corrigendum 1 (TC1), containing amendments to the standard itself, and Technical Report 1 (TR1), containing proposals for a number of new features for the standard library. It’s worth noting that while TC1 is an official document to be observed by vendors of standard-compliant compilers and libraries, the features outlined in TR1 do not necessarily have to make it into the next version of the standard. Nonetheless, TR1 is an important document in that it provides a wealth of clues as to the probable additions to the standard library, some of which will be described below.

It is also possible that TR2 (also containing standard library extension definitions) will be published before the new standard, with the most likely proposals involving support for Unicode, XML, HTML, network programming and features to make C++ easier to use for beginning and occasional programmers. Proposals for TR2 will only accepted until October this year. However, it is most likely that the remainder of new features will simply be incorporated into C++0x, without an intermediate report. April 2007 is the deadline for all complementary and specifying proposals.

Extensions to the language core

The past few years have seen a huge number of proposals for change and extensions to the language core. Many of these died a natural death for lack of wider interest, while others attracted more attention and were eventually formalised as official proposal documents published on the committee website. While it is hard to be sure which exact proposals will survive through the entire voting and working cycle, some enjoy such widespread support that they are almost certain to appear in the final standard. Let’s have a look at some of them.

Concepts

Concepts are probably the most revolutionary language extension, addressing current problems with creating and using generic libraries. Concepts will provide support for templates that go beyond correct syntax for a given type to include properties expressed in more abstract terms (for example objects of the type can be copied or objects of the type can be added). Named concepts will allow programmers to restrict template use to types that fulfil the concept condition, making it much easier to debug concept-based templates and resolve conflicts that arise for example during template overloading.

Move semantics

A commonly mentioned problem with C++ is the large number of object copies created even for simple expressions. Take the example of adding a new object to a container:

container.push_back(MyClass(...));

What is really stored in the container is a copy of the object, not the actual object. The operations performed behind the scenes are: creating a temporary object, putting a copy of the object in the container and destroying the temporary object. The mechanism is obviously far from perfect performance-wise, considering that two objects are created where the programmer simply wanted to put one new object in the container. This particular problem can be solved by using different container libraries (e.g. based on the factory pattern), but the issue is actually more general and not restricted to containers. It basically appears wherever temporary objects are involved, for example:

string s1, s2, s3;

// ...

s1 = s2 + s3;

The code above creates a new temporary object, copies its value into s1 and destroys it, again creating a potential performance issue. The underlying problem is actually that C++ has no way of expressing a move operation, so there is no way to differentiate between moving and copying, and temporary object copies are frequently required to move values. For types based on dynamic structures (such as std::string), the move operation can be implemented simply by swapping pointers and leaving the source object empty. The operation is much faster than copying an entire object, especially if the source object is no longer required, as in the examples shown above.

Move semantics are a new language feature designed to address these problems and hopefully bring significant performance improvements. From a programmer’s point of view, move semantics could take the form of a new type of reference and a new qualifier to aid the selection of the most appropriate overloaded function, to be used for example when dealing with temporary objects. It would then be up to the programmer to define the exact semantics of the operation for a given type.

A typical class definition containing a copy constructor and a move constructor could then be:

class MyString {

public:

MyString(const MyString &other); // copy constructor

MyString(MyString &&other); // move constructor

};

In the code above, a double ampersand (&&) signifies a new type of reference (an rvalue reference), used whenever the argument is a temporary object (among other things). The first constructor version can then be used to as a traditional copy constructor and the second constructor will simply swap pointers, leaving the original object (in this case other) empty.

Thread support

Thread support comes in the form of a better defined memory model, which is required to fully specify the circumstances under which the compiler can perform advanced optimisations, and those can potentially extend even to reordering operations. For synchronising instructions such as locking or releasing a mutex, optimisation has to be done so as to ensure that no code is moved out of a critical section. The present standard makes no mention of multithreading, so compilers either have to be conservative in their optimisations or rely on other standards (e.g. POSIX) or conventions to allow code to be generated correctly. While it is clear that the language core needs to be extended to include uniform support for synchronisation and multithreading, we are unlikely to see new keywords or control structures for multithreaded programming. Support for threading will primarily be included in the standard library.

Changes in parsing closing angled brackets

A common error made in template programming is to use two closing angled brackets side by side, as in vector<pair<int, int>> v. In such cases, the >> is currently interpreted as the bitwise shift operator, obviously causing a compilation error in this context. Parser behaviour will be changed to cater for this special case, so the declaration above will be valid (as it is intuitively).

Initialisation lists for containers

The ability to use initialisation lists for ordinary arrays was traditionally one argument against the use of STL containers. Initialising a short array with literal values is very simple:

int a[] = {1, 2, 3, 4};

To use an STL container, such as a vector, programmers have to use a more long-winded notation, as in:

vector<int> v;

v.push_back(1);

v.push_back(2);

// ...

Specialised libraries make it possible to shorten the notation, but the intuitive one-line declaration remains unavailable. Extending containers to support initialisation lists will make them easier and more intuitive to use, allowing for example the declaration:

vector<int> v = {1, 2, 3, 4};

Template typedefs

Template typedefs will make it possible to define a new type based on a specified template so as to bind only selected parameters for the output template. Here is an example of using such an alias (and new angled bracket rules):

template <typename T> using MyVec = vector<T, MyAlloc<T>>;

MyVec is based on vector, but only binds one of its parameters, in this case the allocator name. However, it is still a template, so it can be instantiated using its single parameter:

MyVec<int> v;

The result is a template definition compliant with vector<int, MyAlloc<int>>.

Automatic type deduction in variable declarations

Type deduction is one of the most eagerly anticipated features for easing the use of templates, making it possible to skip the variable type in variable declarations whenever the type can be determined from the context. For example, in standard C++, the following container:

map<string, pair<int, double> > my_map;

currently requires much of the definition to be repeated in order to specify its iterator type:

map<string, pair<int, double> >::iterator it = my_map.begin();

With automatic type deduction, the above will be reduced simply to:

auto it = my_map.begin();

The nullptr keyword

Introducing the nullptr keyword will resolve problems that currently appear when overloading functions. Take the declarations:

void fun(char *p);

void fun(int i);

If you now call fun(NULL), the mechanism responsible for choosing one of the functions will actually select the second version, as NULL is defined as a constant with a value of 0, so the second version is the closest match. Introducing the separate nullptr keyword for pointer operations only will get rid of the ambiguity.

The long long type

The new integral type long long (and its unsigned counterpart) is an extension aimed at maximising compatibility with C, in which the type already exists. The type very naturally extends existing integral types. (Committee members joke: We’ve been working on this for a long long time.)

A d v e r t i s e m e n t

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence