Log In
Or create an account ->
Imperial Library
Home
About
News
Upload
Forum
Help
Login/SignUp
Index
Cover Page
About This eBook
Halftitle Page
Title Page
Copyright Page
Pearson’s Commitment to Diversity, Equity, and Inclusion
Contents
Selected C++ Core Guidelines
Foreword
Preface
About This Book
Access the Code
Acknowledgments
About the Authors
Section 1: Bikeshedding is bad
Chapter 1.1. P.2: Write in ISO Standard C++
What is ISO Standard C++?
Encapsulating variations
Learning the old ways
Staying on top of developments to the standard
Chapter 1.2. F.51: Where there is a choice, prefer default arguments over overloading
Introduction
Refining your abstraction: Additional arguments or overloading?
The subtleties of overload resolution
Back to the example
The unambiguous nature of default arguments
Alternatives to overloading
Sometimes you must overload
Summary
Chapter 1.3. C.45: Don’t define a default constructor that only initializes data members; use in-class member initializers instead
Why have default constructors anyway?
How do you initialize a data member?
What happens when two people maintain a class?
Summary
Chapter 1.4. C.131: Avoid trivial getters and setters
An archaic idiom
Abstraction
Mere Encapsulation
Class Invariants
Nouns and Verbs
Summary
Chapter 1.5. ES.10: Declare one name (only) per declaration
Let me introduce you
Backward compatibility
Writing clearer declarations
Structured binding
Summary
Chapter 1.6. NR.2: Don’t insist to have only a single return-statement in a function
Rules evolve
Ensuring cleanup
Using RAII
Writing good functions
Summary
Section 2: Don’t hurt yourself
Chapter 2.1. P.11: Encapsulate messy constructs, rather than spreading through the code
All in one gulp
What it means to encapsulate a messy construct
The purpose of language and the nature of abstraction
Levels of abstraction
Abstraction by refactoring and drawing the line
Summary
Chapter 2.2. I.23: Keep the number of function arguments low
How much should they earn?
Simplifying matters through abstraction
Do as little as possible, but no less
Real-life examples
Summary
Chapter 2.3. I.26: If you want a cross-compiler ABI, use a C-style subset
Creating libraries
What is an ABI?
Paring back to the absolute minimum
Exception propagation
Summary
Chapter 2.4. C.47: Define and initialize member variables in the order of member declaration
Summary
Chapter 2.5. CP.3: Minimize explicit sharing of writable data
Traditional execution model
Wait, there’s more
Avoiding deadlocks and data races
Setting aside locks and mutexes
Summary
Chapter 2.6. T.120: Use template metaprogramming only when you really need to
std::enable_if => requires
Summary
Section 3: Stop using that
Chapter 3.1. I.11: Never transfer ownership by a raw pointer (T*) or reference (T&)
Using the free store
The performance cost of smart pointers
Using unadorned reference semantics
gsl::owner
Summary
Chapter 3.2. I.3: Avoid singletons
Global objects are bad
Singleton Design Pattern
Static initialization order fiasco
How to hide a singleton
But only one of these should ever exist
Wait a moment…
Summary
Chapter 3.3. C.90: Rely on constructors and assignment operators, not memset and memcpy
Chasing maximum performance
The horrendous overhead of the constructor
The simplest possible class
What is the standard talking about anyway?
But what about memcpy?
Never underestimate the compiler
Summary
Chapter 3.4. ES.50: Don’t cast away const
Story time
Dealing with rather more data
The const firewall
Implementing a dual interface
Caching and lazy evaluation
Two types of const
Surprises with const
Summary
Chapter 3.5. E.28: Avoid error handling based on global state (e.g. errno)
Error handling is hard
C and errno
Return codes
Exceptions
<system_error>
Boost.Outcome
Why is error handling so hard?
Light at the end of the tunnel
Summary
Chapter 3.6. SF.7: Don’t write using namespace at global scope in a header file
Don’t do this
Disambiguation
Using using
Where do the symbols go?
An altogether more insidious problem
Solving the problem of cluttered scope resolution operators
The temptation and The Fall
Summary
Section 4: Use this new thing properly
Chapter 4.1. F.21: To return multiple “out” values, prefer returning a struct or tuple
The shape of a function signature
Documenting and annotating
Now you can return an object
You can also return a tuple
Passing and returning by non-const reference
Summary
Chapter 4.2. Enum.3: Prefer class enums over “plain” enums
Constants
Scoped enumerations
Underlying type
Implicit conversion
Summary
Postscript
Chapter 4.3. ES.5: Keep scopes small
The nature of scope
Block scope
Namespace scope
Class scope
Function parameter scope
Enumeration scope
Template parameter scope
Scope as context
Summary
Chapter 4.4. Con.5: Use constexpr for values that can be computed at compile time
From const to constexpr
Default C++
Using constexpr
inline
consteval
constinit
Summary
Chapter 4.5. T.1: Use templates to raise the level of abstraction of code
Story time
Raising the level of abstraction
Function templates and abstraction
Class templates and abstraction
Naming is hard
Summary
Chapter 4.6. T.10: Specify concepts for all template arguments
How did we get here?
Constraining your parameters
How to abstract your concepts
Factoring via concepts
Summary
Section 5: Write code well by default
Chapter 5.1. P.4: Ideally, a program should be statically type safe
Type safety is a security feature of C++
Union
Casting
Unsigned
Buffers and sizes
Summary
Chapter 5.2. P.10: Prefer immutable data to mutable data
The wrong defaults
constness in function declarations
Summary
Chapter 5.3. I.30: Encapsulate rule violations
Hiding the unsightly things in life
Keeping up appearances
Summary
Chapter 5.4. ES.22: Don’t declare a variable until you have a value to initialize it with
The importance of expressions and statements
C-style declaration
Declare-then-initialize
Maximally delayed declaration
Localization of context-specific functionality
Eliminating state
Summary
Chapter 5.5. Per.7: Design to enable optimization
Maximizing the frame rate
Working further from the metal
Optimization through abstraction
Summary
Chapter 5.6. E.6: Use RAII to prevent leaks
Deterministic destruction
Leaking away files
Why are we bothering?
This all seems a bit much: Future possibilities
Where can I get this?
Envoi
Afterword
Index
Code Snippets
← Prev
Back
Next →
← Prev
Back
Next →