Beautiful C++

J. Guy Davidson, head of engineering practice at Creative Assembly, works on its Total War game franchise, curates its catalogue, and improves programming standards across its engineering team. He serves on the ISO C++ committee, moderates the #include discord server, speaks at C++ events, and offers C++ mentoring support through Prospela and BAME in Games. Kate Gregory has 40+ years of development experience in multiple languages. She has keynoted on five continents, and volunteers in many C++ activities, especially #include , which is making the industry more welcoming and inclusive. Since 1986 she and her husband have run Gregory Consulting, helping clients worldwide become more effective.

• List of Selected C++ Core Guidelines xiiiForeword xvPreface xviiAcknowledgments xxiAbout the Authors xxiii Section 1: Bikeshedding is bad 1 Chapter 1.1: P.2: Write in ISO Standard C++ 3 Chapter 1.2: F.51: Where there is a choice, prefer default arguments over overloading 13 Chapter 1.3: C.45: Don't define a default constructor that only initializes data members; use in-class member initializers instead 23 Chapter 1.4: C.131: Avoid trivial getters and setters 31 Chapter 1.5: ES.10: Declare one name (only) per declaration 41 Chapter 1.6: NR.2: Don't insist to have only a single return-statement in a function 49 Section 2: Don't hurt yourself 59 Chapter 2.1: P.11: Encapsulate messy constructs, rather than spreading through the code 61 Chapter 2.2: I.23: Keep the number of function arguments low 71 Chapter 2.3: I.26: If you want a cross-compiler ABI, use a C-style subset 79 Chapter 2.4: C.47: Define and initialize member variables in the order of member declaration 87 Chapter 2.5: CP.3: Minimize explicit sharing of writable data 97 Chapter 2.6: T.120: Use template metaprogramming only when you really need to 107 Section 3: Stop using that 119 Chapter 3.1: I.11: Never transfer ownership by a raw pointer (T*) or reference (T&) 121 Chapter 3.2: I.3: Avoid singletons 129 Chapter 3.3: C.90: Rely on constructors and assignment operators, not memset and memcpy 139 Chapter 3.4: ES.50: Don't cast away const 149 Chapter 3.5: E.28: Avoid error handling based on global state (e.g. errno)159 Chapter 3.6: SF.7: Don't write using namespace at global scope in a header file 169 Section 4: Use this new thing properly 179 Chapter 4.1: F.21: To return multiple "out" values, prefer returning a struct or tuple 181 Chapter 4.2: Enum.3: Prefer class enums over "plain" enums 193 Chapter 4.3: ES.5: Keep scopes small 201 Chapter 4.4: Con.5: Use constexpr for values that can be computed at compile time 213 Chapter 4.5: T.1: Use templates to raise the level of abstraction of code 225 Chapter 4.6: T.10: Specify concepts for all template arguments 235 Section 5: Write code well by default 45 Chapter 5.1: P.4: Ideally, a program should be statically type safe 247 Chapter 5.2: P.10: Prefer immutable data to mutable data 259 Chapter 5.3: I.30: Encapsulate rule violations 267 Chapter 5.4: ES.22: Don't declare a variable until you have a value to initialize it with 275 Chapter 5.5: Per.7: Design to enable optimization 285 Chapter 5.6: E.6: Use RAII to prevent leaks 293 Envoi 305 Afterword 307 Index 309

Select Guide Rating