Teach-Myself-CPP
Teach-Myself-CPP copied to clipboard
This is the repository containing self-study notes for modern C++ to better prepare myself for workplace once graduate.
Teach-Myself-CPP
Hey! Welcome to this repository. This is the notes-keeping place for teaching myself C++, modern C++ in specific. It might also include some auxiliary topics about useful tools.
I learned traditional C++98 a few years ago and didn't quite work on this programming language recently. In order to better prepare myself for workplace once I graduate from school, I will teach myself modern C++ in leisure time and update notes here. Hopefully, this notes could also help other people wishing to get onboard with modern C++.
Aside from book reading notes, mostly I will be borrowing good resources from all over the repos on github, and re-implement them for deepening understanding. Sources are pointed out in each one.
I finished reading on
Currently I am reading the comprehensive book <C++ Software Design: Design Principles and Patterns for High-Quality Software> to learn some design principles and best practices.
Content
- Google C++ Style Guidance
- Git tutorial
- Gdb tutorial
- Makefile tutorial
- Socket Programming tutorial
- How to intergate with GoogleTest using CMake
- How to use Google's Protocol Buffer
- How to write a Reader-Writer lock
- How to design a Key-Value store using SkipList
- How to design a multi-user chatroom using Socket Programming
- How does Webbench-1.5 work - source code annotation
-
How to write Smart Pointers
- my unique_ptr
- my shared_ptr
- C++ New Features Clarification
- Variadic Template
-
<C++ Concurrency in Action>
- Thread Management
- Sharing Data Between Threads
- Synchronizing Concurrent Operations
- Memory Model and Operations on Atmoic Types
-
<Effective Modern C++>
- Deducing Types
- Understand template type deduction
- Understand auto type deduction
- Understand decltype
- Know how to view deduced types
-
auto
- Prefer auto to explicit type declarations
- Use the explicitly typed initializer idiom when auto deduces undesired types
- Moving to Modern C++
- Distinguish between () and {} when creating objects
- Prefer nullptr to 0 and NULL
- Prefer alias declarations to typedefs
- Prefer scoped enums to unscoped enums
- Prefer deleted functions to private undefined ones
- Declare overriding functions override
- Prefer const_iterators to iterators
- Declare functions noexcept if they won't emit exceptions
- Use constexpr whenever possible
- Make const member functions thread safe
- Understand special member function generation
- Smart Pointers
- Use std::unique_ptr for exclusive-ownership resource management
- Use std::shared_ptr for shared-ownership resource management
- Use std::weak_ptr for std::shared_ptr-like pointers that can dangle
- Prefer std::make_unique and std::make_shared to direct use of new
- When using the Pimpl Idiom, define special member functions in the implementation file
- Rvalue References, Move Semantics, and Perfect Forwarding
- Understand std::move and std::forward
- Distinguish universal references from rvalue references
- Use std::move on rvalue references, std::forward on universal references
- Avoid overloading on universal references
- Familiarize yourself with alternatives to overloading on universal references
- Understand reference collapsing
- Assume that move operations are not present, not cheap, and not used
- Familiarize yourself with perfect forwarding failure cases
- Lambda Expressions
- Avoid default capture modes
- Use init capture to move objects into closures
- Use decltype on auto&& parameters to std::forward them
- Prefer lambdas to std::bind
- The Concurrency API
- Prefer task-based programming to thread-based
- Specify std::launch::async if asynchronicity is essential
- Make std::threads unjoinable on all paths
- Be aware of varying thread handle destructor behavior
- Consider void futures for one-shot event communication
- Use std::atomic for concurrency, volatile for special memory
- Deducing Types
-
<C++ Software Design Principles>
- The Art of Software Design
- Understand the Importance of Software Design
- Design for Change
- Separate Interfaces to Avoid Artificial Coupling
- Design for Testability
- Design for Extension
- The Art of Building Abstractions
- Adhere to the Expected Behavior of Abstractions
- Understand the Similarities Between Base Classes and Concepts
- Understand the Semantic Requirements of Overload Sets
- Pay Attention to the Ownership of Abstractions
- Consider Creating an Architectural Document
- The Purpose of Design Patterns
- Understand the Purpose of Design Patterns
- Beware of Design Pattern Misconceptions
- Design Patterns Are Everywhere
- Use a Design Pattern's Name to communicate Intent
- The Visitor Design Pattern
- Design for the Addition of Types of Operations
- Use Visitor to Extend Operations
- Consider std::variant for Implementing Visitor
- Beware the Performance of Acyclic Visitor
- The Strategy and Command Design Patterns
- Use Strategy to Isolate How Things Are Done
- Favor Composition over Inheritance
- Use Command to Isolate What Things Are Done
- Prefer Value Semantics over Reference Semantics
- Prefer a Value-Based Implementation of Strategy and Command
- The Adapter, Observer, and CRTP Design Patterns
- Use Adapters to Standardize Interfaces
- Apply Observers as an Abstract Notification Mechanism
- Use CRTP to Introduce Static Type Categories
- Use CRTP for Static Mixin Classes
- The Bridge, Prototype, and External Polymorphism Design Patterns
- Build Bridges to Remove Physical Dependencies
- Be Aware of Bridge Performance Gains and Losses
- Apply Prototype for Abstract Copy Operations
- Use External Polymorphism for Nonintrusive Runtime Polymorphism
- The Type Erasure Design Pattern
- Consider Replacing Inheritance Hierarchies with Type Erasure
- Be Aware of the Optimization Potential of Type Erasure
- Be Aware of the Setup Costs of Owning Type Erasure Wrappers
- The Decorator Design Pattern
- Use Decorators to Add Customization Hierarchically
- Understand the Trade-off Between Runtime and Compile Time Abstraction
- The Singleton Pattern
- Treat Singleton as Implementation Pattern, Not a Design Pattern
- Design Singletons for Change and Testability
- The Art of Software Design