Beautiful C++: 30 Core Guidelines for Writing Clean, Safe, and Fast Code

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