Book Image

Hands-On Design Patterns with C++ (Second Edition) - Second Edition

By : Fedor G. Pikus
5 (1)
Book Image

Hands-On Design Patterns with C++ (Second Edition) - Second Edition

5 (1)
By: Fedor G. Pikus

Overview of this book

C++ is a general-purpose programming language designed for efficiency, performance, and flexibility. Design patterns are commonly accepted solutions to well-recognized design problems. In essence, they are a library of reusable components, only for software architecture, and not for a concrete implementation. This book helps you focus on the design patterns that naturally adapt to your needs, and on the patterns that uniquely benefit from the features of C++. Armed with the knowledge of these patterns, you’ll spend less time searching for solutions to common problems and tackle challenges with the solutions developed from experience. You’ll also explore that design patterns are a concise and efficient way to communicate, as patterns are a familiar and recognizable solution to a specific problem and can convey a considerable amount of information with a single line of code. By the end of this book, you’ll have a deep understanding of how to use design patterns to write maintainable, robust, and reusable software.
Table of Contents (26 chapters)
1
Part 1: Getting Started with C++ Features and Concepts
5
Part 2: Common C++ Idioms
10
Part 3: C++ Design Patterns
18
Part 4: Advanced C++ Design Patterns

Chapter 5, Comprehensive Look at RAII

  1. Memory is the most common resource, but any object can be a resource. Any virtual or physical quantity that the program operates on is a resource.
  2. Resources should not be lost (leaked). If a resource is accessed through a handle, such as a pointer or an ID, that handle should not be dangling (referring to a resource that does not exist). Resources should be released when they are no longer needed, in the manner that corresponds to the way they were acquired.
  3. Resource Acquisition Is Initialization is an idiom; it is the dominant C++ approach to resource management, where each resource is owned by an object, acquired in the constructor, and released in the destructor of that object.
  4. An RAII object should always be created on the stack or as a data member of another object. When the flow of the program leaves the scope containing the RAII object or the larger object containing the RAII object is deleted, the destructor of the RAII...