Scott Meyers - Effective Modern C++

constexprdouble yValue() const noexcept { return y; }

void setX(double newX) noexcept { x = newX; }

void setY(double newY) noexcept { y = newY; }

private:

double x, y;

};

Here, the Pointconstructor can be declared constexpr, because if the arguments passed to it are known during compilation, the value of the data members of the constructed Pointcan also be known during compilation. Points so initialized could thus be constexpr:

constexprPoint p1(9.4, 27.7); // fine, "runs" constexpr

// ctor during compilation

constexprPoint p2(28.8, 5.3); // also fine

Similarly, the getters xValueand yValuecan be constexpr, because if they're invoked on a Pointobject with a value known during compilation (e.g., a constexpr Pointobject), the values of the data members xand ycan be known during compilation. That makes it possible to write constexprfunctions that call Point's getters and to initialize constexprobjects with the results of such functions:

constexpr

Point midpoint(const Point& p1, const Point& p2) noexcept

{

return { (p1. xValue()+ p2. xValue()) / 2, // call constexpr

(p1. yValue()+ p2. yValue()) / 2 }; // member funcs

}

constexprauto mid = midpoint(p1, p2); // init constexpr

// object w/result of

// constexpr function

This is very exciting. It means that the object mid, though its initialization involves calls to constructors, getters, and a non-member function, can be created in readonly memory! It means you could use an expression like mid.xValue() * 10in an argument to a template or in an expression specifying the value of an enumerator! [6] Because Point::xValue returns double , the type of mid.xValue() * 10 is also double . Floating-point types can't be used to instantiate templates or to specify enumerator values, but they can be used as part of larger expressions that yield integral types. For example, static_cast(mid.xValue() * 10) could be used to instantiate a template or to specify an enumerator value. It means that the traditionally fairly strict line between work done during compilation and work done at runtime begins to blur, and some computations traditionally done at runtime can migrate to compile time. The more code taking part in the migration, the faster your software will run. (Compilation may take longer, however.)

In C++11, two restrictions prevent Point's member functions setXand setYfrom being declared constexpr. First, they modify the object they operate on, and in C++11, constexprmember functions are implicitly const. Second, they have voidreturn types, and voidisn't a literal type in C++11. Both these restrictions are lifted in C++14, so in C++14, even Point's setters can be constexpr:

class Point {

public:

…

constexprvoid setX(double newX) noexcept // C++14

{ x = newX; }

constexprvoid setY(double newY) noexcept // C++14

{ y = newY; }

…

};

That makes it possible to write functions like this:

// return reflection of p with respect to the origin (C++14)

constexpr Point reflection(const Point& p) noexcept {

Point result; // create non-const Point

result. setX(-p.xValue()); // set its x and y values

result. setY(-p.yValue());

return result; // return copy of it

}

Client code could look like this:

constexpr Point p1(9.4, 27.7); // as above

constexpr Point p2(28.8, 5.3);

constexpr auto mid = midpoint(p1, p2);

constexpr auto reflectedMid = // reflectedMid's value is

reflection(mid); // (-19.1 -16.5) and known

// during compilation

The advice of this Item is to use constexprwhenever possible, and by now I hope it's clear why: both constexprobjects and constexprfunctions can be employed in a wider range of contexts than non- constexprobjects and functions. By using constexprwhenever possible, you maximize the range of situations in which your objects and functions may be used.

It's important to note that constexpris part of an object's or function's interface. constexprproclaims “I can be used in a context where C++ requires a constant expression.” If you declare an object or function constexpr, clients may use it in such contexts. If you later decide that your use of constexprwas a mistake and you remove it, you may cause arbitrarily large amounts of client code to stop compiling. (The simple act of adding I/O to a function for debugging or performance tuning could lead to such a problem, because I/O statements are generally not permitted in constexprfunctions.) Part of “whenever possible” in “Use constexprwhenever possible” is your willingness to make a long-term commitment to the constraints it imposes on the objects and functions you apply it to.

• constexprobjects are constand are initialized with values known during compilation.

• constexprfunctions can produce compile-time results when called with arguments whose values are known during compilation.

• constexprobjects and functions may be used in a wider range of contexts than non- constexprobjects and functions.

• constexpris part of an object's or function's interface.

If we're working in a mathematical domain, we might find it convenient to have a class representing polynomials. Within this class, it would probably be useful to have a function to compute the root(s) of a polynomial, i.e., values where the polynomial evaluates to zero. Such a function would not modify the polynomial, so it'd be natural to declare it const:

class Polynomial {

public:

using RootsType = // data structure holding values

std::vector; // where polynomial evals to zero

… // (see Item 9 for info on "using")

RootsType roots() const;

…

};

Computing the roots of a polynomial can be expensive, so we don't want to do it if we don't have to. And if we do have to do it, we certainly don't want to do it more than once. We'll thus cache the root(s) of the polynomial if we have to compute them, and we'll implement rootsto return the cached value. Here's the basic approach:

class Polynomial {

public:

using RootsType = std::vector;

RootsType roots() const {

if (!rootsAreValid) { // if cache not valid