An object can be moved elsewhere (rather than copied) if its previous user no longer needs it. Moving the resources from one object to another can often be implemented far more efficiently than (deep) copying them. For a string object, for instance, moving is typically as simple as copying a char* pointer and a length (constant time); there is no need to copy the entire char array (linear time).

Unless otherwise specified, the source object that was moved from is left in an undefined but valid state and should not be used anymore unless reinitialized. A valid implementation for moving a std::string (see Chapter 6), for instance, could set the source’s char* pointer to nullptr to prevent the array from being deleted twice, but this is not required by the Standard. Likewise, it is unspecified what length() will return after being moved from. Certain operations, assignments in particular, remain allowed, as demonstrated in the following example:

Despite its name, the std::move() function technically does not move anything: instead, it simply marks that a given T, T&, or T&& value may be moved, effectively by statically casting it to an rvalue reference T&&. Because of the type cast, other functions may get selected by overload resolution, and/or value parameter objects may become initialized using their move constructors (of form T(T&& t)), if available, rather than their copy constructors. This initialization occurs at the callee side, not the caller side. An rvalue parameter T&& forces the caller to always move.

Similarly, an object can also be moved to another using a move assignment operator (of form operator=(T&&)):

If no move member is defined, either explicitly or implicitly, overload resolution for T&& falls back to T& or T, and in the latter case still creates a copy. Conditions for implicit move members to be generated include that there may not be any user-defined copy, move, or destructor members, nor any non-static member variable or base class that cannot be moved.

The move_if_noexcept() function is similar to move(), except that it only casts to T&& if the move constructor of T is known not to throw from its exceptions specification (noexcept, or the deprecated throw()); otherwise, it casts to const T&.

All classes defined by the Standard have move members if appropriate. Many containers from Chapter 3, for example, can be moved in constant time (not std::array, although it will move individual elements if possible to avoid deep copies).

The std::forward() helper function is intended to be used in templated functions to efficiently pass its arguments along to other functions while preserving any move semantics. If the argument to forward<T>() was an lvalue reference T&, this reference is returned unchanged. Otherwise, the argument is cast to an rvalue reference T&&. An example will clarify its intended use:

The idiom used by good_fwd() is called perfect forwarding . It optimally preserves rvalue references (such as those of std::move()d or temporary objects). The idiom’s first ingredient is a so-called forwarding or universal reference : a T&& parameter, with T a template type parameter. Without it, template argument deduction removes all references: for ugly_fwd() ; both A& and A&& become A. With a forwarding reference, A& and A&& are deduced, respectively: that is, even though the forwarding reference looks like T&&, if passed A&, A& is deduced and not A&&. Still, using a forwarding reference alone is not enough, as shown with bad_fwd(). When using the named variable t as is, it binds with an lvalue function parameter (all named variables do), even if its type is deduced as A&&. This is where std::forward<T>() comes in. Similar to std::move(), it casts to T&&, but only if given a value with an rvalue type (including named variables of type A&&).

The std::swap() template function swaps two objects as if implemented as:

A similar swap() function template to piecewise swap all elements of equally long T[N] arrays is defined as well.

Although already quite efficient if proper move members are available, for truly optimal performance you should consider specializing these template functions: for instance, to eliminate the need to move to a temporary. Many algorithms from Chapter 4, for example, call this non-member swap() function. For Standard types, swap() specializations are already defined where appropriate.

A function similar to swap() is std::exchange(), which assigns a new value to something while returning its old value. A valid implementation is

The std::pair<T1,T2> template struct is a copyable, moveable, swappable, (lexicographically) comparable struct that stores a pair of T1 and T2 values in its public first and second member variables. A default-constructed pair zero-initializes its values, but initial values may be provided as well:

The two template type parameters can be deduced automatically using auxiliary function std::make_pair() :

std:: tuple is a generalization of pair that allows any number of values to be stored (that is, zero or more, not just two): std::tuple<Type...>. It is mostly analogous to pair, including the make_tuple() auxiliary function. The main difference is that the individual values are not stored in public member variables. Instead, you can access them using one of the get() template functions:

An alternative way to obtain values of a tuple is by unpacking it using the tie() function. The special std::ignore constant may be used to exclude any value:

Two helper structs exist to obtain the size and element types of a given tuple as well, which is mainly useful when writing generic code:

Note that get(), tuple_size, and tuple_element are also defined for pair and std::array (see Chapter 3) in their respective headers, but not tie().

A final helper function for tuples is std::forward_as_tuple(), which creates a tuple of references to its arguments. These are lvalue references generally, but rvalue references are maintained, as with std::forward() explained earlier. It is designed to forward arguments (that is, while avoiding copies) to the constructor of a tuple, in particular in the context of functions that accept a tuple by value. A function f(tuple<std::string, int>), for instance, can then be called as follows: f(std::forward_as_tuple("test", 123));.

Tuples offer facilities for custom allocators as well, but this is an advanced topic that falls outside the scope of this book.

The functions std::ref() and cref() return std::reference_wrapper<T> instances that simply wrap a (const) T& reference to their input argument. This reference can then be extracted explicitly with get() or implicitly by casting to T&.

Because these wrappers can safely be copied, they can be used, for example, to pass references to template functions that take their arguments by value, badly forward their arguments (forwarding is discussed earlier in this chapter), or copy their arguments for other reasons. Standard template functions that do not accept references as arguments, but do work with ref()/cref(), include std::thread() and async() (see Chapter 7), and the std::bind() function discussed shortly.

These wrappers can be assigned to as well, thus enabling storing references into the containers from Chapter 3. In the following example, for instance, you could not declare a vector<int&>, because int& values cannot be assigned to:

The <functional> header provides an entire series of functor structs similar to the my_plus example used earlier in this section’s introduction:

These functors often result in short, readable code, even more so than with lambda expressions. The following example sorts an array in descending order (with the default being ascending) using the sort() algorithm explained in Chapter 4:

As of C++14, all of these functor classes have a special specialization for T equal to void, and void has also become the default template type argument. These are called transparent operator functors , because their function call operator conveniently deduces the parameter type. In the previous sort() example, for instance, you could simply use std::greater<>. The same functor can even be used for different types:

As Chapter 3 explains, the transparent std::less<> and greater<> functors are also the preferred comparison functors for ordered associative containers.

Passing a unary/binary functor, predicate, to std::not1()/not2() creates a new functor (of type unary_negate/binary_negate) that negates predicate’s result (that is, evaluates to !predicate()). For this to work, the type of predicate must define a public member type argument_type. All functor types in <functional> have this.

The std::function template class is designed for wrapping a copy of any kind of callable entity: that is, any kind of function object or pointer. This includes the results of, for example, bind or lambda expressions (both explained in more detail shortly):

If a default-constructed function object is called, a std::bad_function_call exception is thrown. To verify whether a function may be called, it conveniently casts to a Boolean. Alternatively, you may compare a function to a nullptr using == or !=, just as you would with a function pointer.

Other members include target<Type>() to obtain a pointer to the wrapped entity (the correct Type must be specified; otherwise the member returns nullptr), and target_type() which returns the type_info for this wrapped entity (type_info is explained under “Type Utilities” later in this chapter).

The std::bind() function may be used to wrap a copy of any callable while changing its signature: parameters may be reordered, assigned fixed values, and so on. To specify which arguments to forward to the wrapped callable, a sequence of either values or so-called placeholders (_1, _2, and so forth) is passed to bind(). The first argument passed to the bound functor is forwarded to all occurrences of placeholder _1, the second to those of _2, and so on. The maximum number of placeholders is implementation specific; and the type of the returned functors is unspecified. Some examples will clarify:

Both std::function and bind(), introduced earlier, may be used to create functors that evaluate to a given object’s member variable or that call a member function on a given object. A third option is to use std::mem_fn(), which is intended specifically for this purpose:

The member functors created by bind() and mem_fn(), but not std::functions, may also be called with a pointer or one of the standard smart pointers (see the previous section) as the first argument (that is, without dereferencing). Interesting also about the bind() option is that it can bind the target object itself (see b_call_fun_on_s). If that is not required, std::mem_fn() generally results in the shortest code because it deduces the entire type. A more realistic example is this (vector, count_if(), and string are explained in Chapters 3, 4, and 6, respectively):

A std::chrono::duration<Rep, Period=std::ratio<1>> expresses a time span as a tick count, represented as a Rep value which is obtainable through count() (Rep is or emulates an arithmetic type). The time between two consecutive ticks, or period, is statically determined by Period, a std::ratio type denoting a number (or fraction) of seconds (std::ratio is explained in Chapter 1). The default Period is one second:

The duration constructor can convert between durations of a different Period and/or count Representation, as long as no truncation is required. The duration_cast() function can be used for truncating conversions as well:

For convenience, several typedefs analogous to those in the previous example are predefined in the std::chrono namespace: hours, minutes, seconds, milliseconds, microseconds, and nanoseconds. Each uses an unspecified signed integral Rep type, at least big enough to represent a duration of about 1,000 years (Rep has at least 23, 29, 35, 45, 55, and 64 bits, respectively). For further convenience, the namespace std::literals::chrono_literals contains literal operators to easily create instances of such duration types: h, min, s, ms, us, and ns, respectively. They are also made available with a using namespace std::chrono declaration. When applied on a floating-point literal, the result has an unspecified floating point type as Rep:

All arithmetic and comparison operators that you would intuitively expect for working with durations are supported: +, -, *, /, %, +=, -=, *=, /=, %=, ++, --, ==, !=, <, >, <=, and >=. The following expression, for example, evaluates to a duration with count() == 22:

A std::chrono::time_point<Clock, Duration=Clock::duration> represents a point in time, expressed as a Duration since a Clock’s epoch. This Duration may be obtained from its time_since_epoch() member. The epoch is defined as the instant in time chosen as the origin for a particular clock, the reference point from which time is measured. The available standard Clocks are introduced in the next section.

A time_point is generally originally obtained from a member of its Clock’s class. It may be constructed from a given Duration as well, though. If default-constructed, it represents the Clock’s epoch. Several arithmetic (+, -, +=, -=) and comparison (==, !=, <, >, <=, >=) are again available. Subtracting two time_points results in a Duration, and Durations may be added to and subtracted from a time_point. Adding time_points together is not allowed, nor is subtracting one from a Duration:

Conversion between time_points with different Duration types works analogously to the conversion of durations: implicit conversions is allowed as long as no truncation is required; otherwise, time_point_cast() can be used:

The std::chrono namespace offers three clock types: steady_clock, system_clock, and high_resolution_clock. All clocks define the following static members:

The only clock that is guaranteed to be steady is steady_clock. That is, this clock cannot be adjusted. The system_clock, on the other hand, corresponds to the system-wide real-time clock, which can generally be set at will by the user. The high_resolution_clock, finally, is the clock with the shortest period supported by the library implementation (it may be an alias for steady_clock or system_clock).

To measure the time an operation took, a steady_clock should therefore be used, unless the high_resolution_clock of your implementation is steady:

The system_clock should be reserved for working with calendar time. Because the facilities of <chrono> in that respect are somewhat limited, this clock offers static functions to convert its time_points to time_t objects and vice versa (to_time_t() and from_time_t() respectively), which can then be used with the C-style date and time utilities discussed in the next subsection:

The <ctime> header defines two interchangeable types to represent a date and time: time_t, an alias for an arithmetic type (generally a 64-bit signed integer), represents time in a platform-specific manner; and tm, a portable struct with these fields: tm_sec (range [0,60], where 60 is used for leap seconds), tm_min, tm_hour, tm_mday (day of the month, range [1,31]), tm_mon (range [0,11]), tm_year (year since 1900), tm_wday (range [0,6], with 0 being Sunday), tm_yday (range [0,365]), and tm_isdst (positive if Daylight Saving Time is in effect, zero if not, and negative if unknown).

The following functions are available with <ctime>. The local time zone is determined by the currently active C locale (locales are explained in Chapter 6):

Consult your implementation’s documentation for safer alternatives for localtime() and gmtime() (such as localtime_s() for Windows or localtime_r() for Linux). For converting dates and times to strings, the preferred C-style function is strftime() (at the end of this section, we point out C++-style alternatives):

An equivalent for converting to wide strings (wchar_t sequences), wcsftime(), is defined in <cwchar>. These functions write a null-terminated character sequence into result, which must point to a preallocated buffer of size n. If this buffer is too small, zero is returned. Otherwise, the return value equals the number of characters written, not including the terminating null character.

The grammar for specifying the desired textual representation is defined as follows: any character in the format string is copied to the result, except certain special specifiers that are replaced as shown in the following table:

The result of many specifiers, including those that expand to names or preferred formats, depends on the active locale (see Chapter 6). When executed with a French locale, for example, the output for the previous example could be “Today is mer. 21/11" and "10/21/15 16:29:00--10/21/15 16:29:00”. To use a locale-dependent alternative representation (if one is defined by the current locale), C, c, X, x, Y, and y may be preceded by an E (%EC, %Ec, and so on); to use alternative numeric symbols, d, e, H, I, M, m, S, u, U, V, W, w, and y may be modified with the letter O.

As covered in Chapter 5, the C++ libraries offer facilities for reading/writing a tm from/to a stream as well, namely get_time() and put_time(). The only C-style function from <ctime> you generally need to output calendar dates and time in C++-style is therefore localtime() (to convert a system_clock’s time_t to tm).

The C++ typeid() operator is used to obtain information about the runtime type of a value. It returns a reference to a global instance of the std::type_info class defined in <typeinfo>. These instances cannot be copied, but it is safe to use references or pointers to them. Comparison is possible using their ==, !=, and before() members, and a hash_code() can be computed for them. Of particular interest is name(), which returns an implementation-specific textual representation of the value’s type:

The name() printed may be something like “std::basic_string<char, std::char_traits<char>, std::allocator<char>>” (see Chapter 6), but for other implementations it might just as well be “Ss”.

When used on a B* pointer to an instance of a derived class D, typeid() only gives the dynamic type D* rather than the static type B* if B is polymorphic—that is, has at least one virtual member.

Because type_infos cannot be copied, they cannot be used as keys for the associative arrays from Chapter 3 directly. For precisely this purpose, the <typeindex> header defines the std::type_index decorator class: it mimics the interface of a wrapped type_info&, but it is copyable; has <, <=, >, and >= operators; and has a specialization of std::hash defined for it.

A type trait is a construct used to obtain compile-time information on a given type or to transform a given type or types to a related one. Type traits are generally used to inspect and manipulate template type arguments when writing generic code.