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

Summary

SFINAE is a somewhat esoteric feature of the C++ standard - it is complex and has many subtle details. While it is usually mentioned in the context of manual control of the overload resolution, its main purpose is actually not to enable very elaborate guru-level code but to make the regular (automatic) overload resolution work the way the programmer intended. In this role, it usually works exactly as desired and with no additional effort - in fact, the programmer usually does not need to even be aware of this feature. Most of the time, when you write a generic overload and a special overload for the pointers, you expect the latter not to be called for types that are not pointers. Most of the time, you probably don’t even pause to notice that the rejected overload would be ill-formed - who cares, it’s not supposed to be used. But to find out that it’s not supposed to be used, the type has to be substituted, which would result in an invalid code. SFINAE breaks...