To allow more expressive constant expressions C++-11 introduces the keyword constexpr. Now with constant expression we really mean constant expression evaluated at compile time. So by saying that a function is constexpr means the compiler will compute the value at compile time. It can look like this:
constexpr int doubleIt(int x) {return x * 2;}This function doubles its argument. Because it is declared with constexpr it can be used in places where a constant expression is needed. So now we can do this:
char char_array[doubleIt(6)];
Now there are some limiting rules for these constexpr functions. The body should be a single statement of the form "return expression;". The expression must only refer to other constexpr expressions. The later sounds reasonable since how could it be evaluated at compile time if not all parts of it was constant?
That could sound rather limiting but since functions can call other functions or even call themselves recursively some complexity can be computed. The conditional operator "?" is also allowed.
The constexpr functions is not limited to be used only for compile time computing. If called with a non const argument the function is computed in runtime.
There were some, small!?, problems regarding controlling derivation and defining virtual functions. Two new constructs override and final are introduced to resolve that.
The problem here was that you could by mistake create a new function when you really just wanted to override a function. By appending override to the function declaration we say that this function must override a function with the very same signature. Like this:
class Derived : public Base {
public:
virtual void func(int) override;
};With final derivation can be hindered. This can be applied both to whole classes and explicit functions.
class CantInheritFromThis final {
};
class Base {
virtual void cantOverride(int) final;
};Note that final and override are not keywords. They are treated as identifiers with a special meaning in the places just described. In other places they can be used just like normal identifiers.
The old enum definition was a bit lame. Enums were almost interchangeable with an int and still not. This could cause some problems. With C++11 these problems have been resolve by introducing the enum class. An enum can be defined like this:
enum class Fruit
{
Apple,
Banana,
Kiwi = 100,
Pear /* = 101 */
};That new type has the following properties:
- It is type safe. The type is not implicitly converted to int nor comparable with int. If you want to turn such an enum into an int you need to use a cast. - The underlying type of the enum is known and can even be specified. Default type is int. - The scope of the enumerators are within the enumeration. So enumerations defined at the same scope can have enumerators with the same name.
I've been struggling with getting the treading examples working but with no luck. An exception is thrown. Finally I got a hit on the net that suggested that the static linkage didn't work properly. It seems to be so. With dynamic linkage it works fine.
We thus need to change how we build and run the programs. Remember the tool chain description 2010-06-18_CPlusPlus0X?
We now need to drop the -static flag when we compile and link. We also need to add the -pthread flag for using threads.
$HOME/bin/gcc -std=c++0x -pthread
But this is not enough. We need to tell the runtime where the shared library files are located as they are not in the standard place. The environment variable LD_LIBRARY_PATH is used for that. Add this below in order to run the program.
export LD_LIBRARY_PATH=$HOME/lib
Replace with whatever location you have on your toolchain.
With this in place we are ready to look into the world of threads and threads support.