Webinar Recording: Design Patterns and Modern C++
The recording of our May 24th webinar, Design Patterns and Modern C++, is now available on JetBrainsTV YouTube channel.
In this webinar, Dmitri Nesteruk shows how the classical Design Patterns can be applied to Modern C++. He is covering both their canonical implementations as well as possible improvements.
Demo project is available on GitHub. And if you have any suggestions or improvements, your pull requests are welcome!
The video includes the time stamps following the agenda announced:
00:40 – The Adapter pattern.
10:53 – The Builder pattern.
44:16 – The Maybe Monad.
https://www.youtube.com/watch?v=j9arNRRoPe8
Below are some questions from our webinar answered by Dmitri.
Adapter pattern
Q: Why use Boost? Couldn’t std::tolower and std:strtok be used instead?
A: The situation with the C++ Standard Library is much worse than with equivalent standard libraries from .NET and Java. Boost is a treasure trove of useful C++ libraries, so why not use them?
Regarding std::tolower/strtok, those APIs are awful. They can be massaged to work on a std::string, but their use is pure misery, both from discoverability as well as code readability standpoints. I’m not saying Boost is that great either, but it’s much better than C-level APIs.
Q: Why the extra vector construction? Why not just return parts?
A: Because a vector<string> is not implicitly convertible to a vector<String>. And, furthermore, you cannot supply a vector<String> to boost::split(), either.
Builder pattern
Q: How do you consider adding member vs function? It’s often recommended to make a function instead of a member if you don’t need direct access to the class.
A: The advantage of a member function is discoverability. Member functions show up in code completion when invoked on a type they relate to. Global functions are not easily discoverable.
Q: Why do you make HtmlElement a struct and not a class?
A: Stylistic choice. Structs and classes are identical in C++, so I go for structs because they are more visible by default, so I can avoid messing about with visibility while doing the demos.
Q: Would it not be a good idea to implement a move constructor for p using perfect forwarding, to avoid potential copying?
A: Indeed it would, as it would in many other cases. I have omitted these concerns for the sake of brevity.
Q: Would the htlmBuilder work also with ‘auto’?
A: The part that uses operator HtmlElement would not work with auto, as the type would be inferred to be HtmlBuilder.
Other
Q: Using friends is bad practice. It breakes OCP totally. Why do you abuse it so much?
A: I agree to some extent, though I would argue that, if you are making a dedicated builder (or a set of builders) as the only way to initialize a complicated class, then it is acceptable.
Q: What is the performance trade-off of using lambdas instead of _ifs_, if there is one at all?
A: You obviously take a hit in terms of performance for using lambdas, though how much of a hit depends on how well your compiler is able to optimize these. The performance hit is compensated by the improvement in overall readability though, to be honest, C++ only does a passable job in letting us implement the monad.
Q: What’s the difference between “: person(person)” and “: person {person}”?
A: One approach is ‘legacy’ whereas the other is using uniform initialization. They are virtually identical and typically you can customize the IDE to generate one or the other. I try to use the latter as it is more fancy.
About the Presenter:
Dmitri Nesteruk is a developer, speaker, podcaster and technical evangelist. His interests lie in software development and integration practices in the areas of computation, quantitative finance and algorithmic trading. His technological interests include C#, F# and C++ programming as well high-performance computing using technologies such as CUDA. He has been a C# MVP since 2009.
Thanks to all the attendees for the questions! If you still have some, please, contact Dmitri or our team.
Learn more about C++ tools from JetBrains on our site.
Cheers,
The CLion Team
Subscribe to CLion Blog updates
