C++ Design Patterns: From C++03 to C++17 - Fedor Pikus - CppCon 2019

CppCon.org
-
Discussion & Comments: / cpp
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2019
-
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: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@ctrlaltdebug]

Simba: so I can use any of these design patterns?
Mufasa: yes, anything under the sun in yours to use.
Simba: what about that dark place?
Mufasa: that's Singleton. Never go there.

[@ruguevara]

We need more talk like this

[@GeorgeTsiros]

Fedor should give more presentations

[@thomasmejstrik8352]

Fedor is always presenting great stuff, but is really bad in presenting them.

[@ferhat3223]

Thanks for sharing.

[@michelefornaroli2178]

Hi All, can someone explain how can an object of type HTMLBuilder be instantiated into an HTMLElement object at 9:45? is it some sort of implicit conversion, because HTMLBuilder only has one HTMLElement private data member..?

[@9uiop]

At 9:50 in the HTMLBuilder class there is a conversion operator to HTMLElement

[@elliott8175]

I don't understand why design patterns so often use inheritance or abstract methods. What ever happened to composition and compile-time polymorphism?

[@hopo2hopo]

maybe it has something to do with allowing one to deal with circular inclusion/dependency issues ?

[@user-cw3nb8rc9e]

Very interesting talk, but kind of rough :)

[@childhood1888]

Builder, visitor and error handling pattern

[@userrand4900]

Can someone explain what the issue with initializer_list is in czcams.com/video/MdtYi0vvct0/video.html ?

[@user-rq9rl1hs4j]

I think his try is trivial, because dp are not syntax , they r Semantic and concept

[@JeremyCoppin]

Sooo much code on slides that none of us have seen before with annotations...
Taking one pattern and typing and compiling the code and testing it properly would've been more useful...

[@bartomiejstyczen641]

Agree, I found it difficult to follow, can't imagine following it live, without pausing or re-watching some parts. This may be just below my level of expertise, though I think that if scope and pace were reduced, many more people would benefit from it, cause it's great stuff.