[ Ссылка ]
—
Discussion & Comments: [ Ссылка ]
—
Presentation Slides, PDFs, Source Code and other presenter materials are available at: [ Ссылка ]
—
Design patterns are commonly recognized, or “standard”, solutions to frequently occurring software problems. The patterns are the recommended starting point for solving these problems. More than that, the patterns are also useful as a concise high-level vocabulary that we, as software engineers, use to communicate with each other.
Design patterns are not static: they appear when a problem is recognized as sufficiently common, they evolve together with the tools we have available to build solutions, and sometimes they die when the solutions that were universally accepted become obsolete and are superseded by new and better techniques. One of the drivers of the pattern evolution is the development of the programming languages.
As software design challenges, the patterns are usually not very language-specific, except when they are. C++ makes some software problems easy to solve (to the extent that anything is easy in our favorite complex language). More often, C++ provides unique ways to solve programming problems, which give rise to language-specific design patterns. On the other hand, C++ has its own little idiosyncrasies that we have to work around, and so we have an assortment of design patterns that complement the language (remember that the patterns are a high-level language themselves, and so we can use them to express ideas that the programming language does not convey very well).
In this class, we will follow the evolution of several design patterns and see how they were affected by language evolution, from C++98 to C++17. Some patterns, like policy-based design and scopeguard, have benefited from new language features and are approaching the state of “this is what we always wanted but could not have.” Other patterns, like typelists, have either evolved beyond recognition or became essentially obsolete. Many patterns are mostly unchanged, with few cosmetic tweaks. The takeaway from this class might be learning a new design pattern that is a perfect solution for a problem you’ve been working on, discovering a better way to do something you needed done, or a coding trick that is “just what you were looking for.” If nothing else, you will get a better understanding and appreciation for the interplay between the language capabilities and the choices we make in software design.
—
Fedor Pikus
Mentor Graphics
Chief Scientist
Portland, Oregon Area
Fedor G Pikus is a Chief Engineering Scientist in the Design to Silicon division of Mentor
Graphics Corp (Siemens business). His earlier positions included a Senior Software Engineer at Google and a Chief Software Architect for Calibre PERC, LVS, DFM at Mentor Graphics. He joined Mentor Graphics in 1998 when he made a switch from academic research in computational physics to the software industry. Fedor is a recognized expert on high-performance computing and C++, he presented his works at CPPCon, SD West, DesignCon, in Software Development Journal, and is also an O’Reilly author. His responsibilities as a Chief Scientist include planning the long-term technical direction of Calibre products, directing and training the engineers who work on these products, design, and architecture of the software, and research in the new design and software technologies. Fedor has over 25 patents and over 100 papers and conference presentations on physics, EDA, software design, and C++ language.
—
Videos Filmed & Edited by Bash Films: [ Ссылка ]
*-----*
Register Now For CppCon 2022: [ Ссылка ]
*-----*
