San Diego C++ Meetup – Meeting #69

Hello all,

Summary of San Diego C++ Meetup – Meeting session number 69. Took place on December 10 2024.

This is the last session for 2024!

Event link can be found here.

Topics we covered:

  • Modern C++ Programming: A tutorial/training session by Federico Busato.
  • ADL and the  std::swap idiom: Including a mention of  std::ranges::swap(). The discussion covered ADL, anonymous namespaces, and the global namespace, highlighting the subtleties when mixing them.
  • Mapping a runtime value to compile time: More details on this topic are provided below.
  • Variadic templates and fold expressions: Exploring techniques to eliminate duplicate code.
  • Lightning talk by GC: GC’s slide deck on “Stateless Allocators and Memory Resources” can be found here.

How can I map a runtime value to a compile-time value?

This was the main topic. The idea was as follows: given something like:

How can I take a runtime value n and pass it to the function? func<n> would not work since n is not a compile-time value!

The original problem to solve was the following (values are just for the example, it could be anything): for a range [0…5] map to 128, [6…10] map to 256, [11…max] map to 512.

People attending the session immediately suggested using an array/map/hash-map (aka unordered_map). I did not have any material to demonstrate anything with these elements, but before I show the solution presented in the session, let’s try to solve it first with the unordered_map type (since people claim it has O(1) efficiency).

This obviously cannot work. The compiler will complain: “call to non-‘constexpr’ function ’ … “. CE link.

So, what about trying to embed some constants in the “value” part of the unordered_map?

So the problem is, what do we place instead of the ????

What is the actual type? Even if I use integral_constant, which can be used in constant expression contexts, I don’t have a way to provide the type. std::integral_constant<std::size_t, 128> is different from std::integral_constant<std::size_t, 256>.

The next attempt was using Jason Turner’s idea of a “constexpr map.” For reference, here is Jason’s C++ Weekly:

Here is a link to CE trying to get it working. But again, this only works with compile-time inputs. The requirement was runtime inputs!

Let’s take a look at the actual implementation presented in the session. For this, you need to be familiar with:

  • std::lower_bound: Given the values [5, 10, max] and a needle, we need lower_bound to find the correct item among the values. Note that lower_bound is not a must here; we could also use a linear search like find/ find_if.
  • std::integral_constant<>: An important ingredient in the overall solution. This is where we can actually pass a constant to the template NTTP!
  • std::variant<> + std::visit() + overloaded{} idiom: For more information, check out cppreference and cppstories.com, which has tons of great articles on these.

Here is a CE link to the overall solution. Thanks to GC for suggesting constexpr on the return of lower_bound when working with C++20! My solution needed to compile with C++17.

Here is a simple explanation of what’s going on:

We have an array of variants. The std::variant is of type:

Think of it as mapping some number to std::integral_constant<size_t, some_value>.

Given a needle, find the index in the array of variants. We use:

  • lower_bound
  • overloaded{} idiom
  • std::visit to extract the first value in the pair<>

Once we have the result of lower_bound, given the iterator return value, we can compute the index using std::distance(base, iter).

Invoke a call that takes the index. We use the index with the array: arr[n].

Since arr[n] yield a variant type, we can run std::visit, getting the value and extracting the integral_constant, which is the second type in the pair.

Now, we can pass it to an NTTP by calling func<p.second()>(). The magic happens with integral_constant<>! It can be used as an NTTP!

That’s it for this session. I bet there are some other cool ways to achieve something similar!

Thank you for reading!

Kobi

San Diego C++ Meetup #68 – The Art of Writing Efficient Programs – design choices for Performance (Nov 13 2024)

Hello all!

Here is the summary of the last San Diego C++ Meetup, virtual meeting, took place on Wednesday, Nov 13 2024.

Link to the meetup event page here.

Recording uploaded to the San Diego C++ Meetup channel (sdcppmu)

The agenda:

  1. cppquiz fun – C++ Quiz – 297 – std::async, future .wait() vs .get()
  2. Recommending YT channel – “C++Next by Alex Dathskovsky”
  3. The Art of Writing Efficient Programs – chapter 12 – Design choices for Performance.
  4. Tip: transparent comparator/operators.

More details:

First, Alex’s YT channel mentioned above is something you should checkout. It’s fun, short episodes and packed with good information.

We mentioned few Design choices as mentioned in Fedor G. Pikus book: “The Art of Writing Efficient Programs: An advanced programmer’s guide to efficient hardware utilization and compiler optimizations using C++ examples”:

Chapter 12 discuss “Design for Performance”. We mentioned:

  1. Choosing APIs for performance. operator[] vs iterator interface, std::deque as an example to have better performance using iterator vs operator[].
  2. Using std::set<> in conjunction with std::vector<>, using member vs non-member functions.
  3. Lock vs non-lock interfaces, runtime vs Template, policy based classes. Also, using decorators (inheritance in this case).
  4. Redundant get-ters/set-ters and when these are actually could be useful.
  5. 13:34 – we mentioned std::span<>! 🙂
  • Transparent operator – using std::less<> which is like std::less<void>, the benefit of using it, how can it save you from debugging subtle bugs.

This is for this session, thank you for reading!

Kobi

San Diego C++ Meetup – Data Structures and Algorithms with C++ STL (#67)

Hello all,

We had a fun evening on Tuesday October 15th, discussing C++ STL, Data structure and various modern techniques. The inspiration coming from a recently published book by John Farrier:

recording:

San Diego C++ Meetup recording

Event page here.

Hey everyone,

Here’s a quick recap of our discussion:

We kicked things off with cppquiz 167. It’s a tough one but packed with important modern C++ concepts like RValue, LValue, and what happens when you pass an RValue to a function. We also touched on std::move and std::forward. Give it a shot and make sure to read the explanation!

C++ Data Structures and STL:

  • We talked about getters and exposing internal data structures from your class. We also introduced alternatives like iterators and discussed how to write them in different ways.

SFINAE and std::void_t:

  • We covered how SFINAE tweaks the compiler’s function candidate list, mentioned C++20 concepts, and how std::void_t can help. We also discussed type_traits, if constexpr, static_assert(), declval, and how cppinsights.io can be useful.

Allocator Interface:

  • How to use it with STL containers.

std::span<> Example:

  • We went through an example of std::span<>.

Gotchas:

  • Comparing two strings or comparing pointers? Check out the last 2-3 minutes of the recording for the full details!

Book Recommendation:

  • I liked the book, though it was a bit basic for me. However, I think it’s great for newcomers to the language/STL to get familiar with various containers, algorithms, and other parts of the Standard Template Library.

Thanks for reading!

Kobi

San Diego C++ Meetup #66 – Modern CMake for C++

Hello everyone,

Last Tuesday (September 17, 2024), we gathered for the 66th meeting of The San Diego C++ Meetup.

The topic was CMake. Yes, CMake can be fun sometimes! 😊

The inspiration for this session came from the relatively new 2nd edition of “Modern CMake for C++” by Rafal Swidzinski.

First off, the book is fantastic! It’s packed with valuable material that can make your life easier if your build system is CMake. Despite considering myself quite knowledgeable about CMake, I learned a lot from it.

This wasn’t my first time giving a talk on CMake. I’ve had several opportunities in the past, ranging from one-hour to multi-hour sessions. It always feels like there’s so much to cover that even 1, 2, or 4 hours isn’t enough to touch on every aspect of CMake. CMake is extensive, and it’s crucial to understand and use it well. Otherwise, your build system can become difficult to improve, extend, and maintain, leading to a lot of frustration.

When discussing CMake (or any topic in a C++ session), my goal is for everyone to learn something new—at least one thing!

The meetup page link: here

And the recording:

San Diego C++ Meetup recording

BTW – We had an excellent session on July 11, 2023, with Alex Reinking, titled “Modern CMake Best Practices for Library Authors” at the San Diego C++ Meetup. It’s definitely worth watching!

Summary of our discussion:

  • Introduction to the book.
  • CMake’s popularity (based on 2023 surveys).
  • Overview of CMake: its purpose and stages (configuration, generation, and build).
  • Simple CMake files and FetchContent.
  • Generators: what they are and how to write agnostic command lines that work with any generator.
  • CMake Cache file (CMakeCache.txt): using the --force option, cache variables, and debugging/tracing CMake build generation with options like --trace, --log-context, --trace-expand, and --debug-output.
  • Cleaning with the --clean-first option.
  • Targets: what they are and how to build them.
  • Installation: a high-level overview (there’s much more to explore here).
  • Running CMake as a script with the -P option.
  • Brief mentions of CTest/CPack and other tools in the CMake suite.
  • CMakeConfigureLog.yaml (introduced in version 3.26) for advanced debugging of the configure stage.
  • Utility modules included with the CMake package, and projects like cmake-awesome and cmake-modules.
  • Find modules.
  • A slide on important elements of the CMake language (the book has an excellent chapter on this).
  • CLion and CMake: debugging CMake with CLion.

Additional topics covered in the book:

  • Generator expressions
  • Dependency graph and how to print it
  • CMake presets
  • Program analysis tools
  • C++20 modules
  • Testing frameworks
  • Generating documentation

Many thanks to Packtpub for their support providing me the material to review!

That’s it for this session!

Happy CMake-ing!

Kobi

San Diego C++ Meetup #65

Hello everyone,

Super late in writing this summary, can’t believe we are 1 week past the session. I’ve been super busy at work and with Family.

What did we have on the Agenda:

  1. Guo Ci, our guest speaker, presented 2 techniques that are being used to optimize C++ code. The first is doing binary searches with equal_range (in std::ranges and std) and the second is customizing the three-way comparison operator (<=>). Slides: guoci SDCPPMU presentation
  • bio: Guo Ci. Guo is a bioinformatician at the University of Michigan, working in labs doing proteomics and genomics research.
  1. Adding Default Constructor using =default; to your class type.

sdcppmu Youtube recording:

Event page from meetup.com

Summary of the discussions:

  1. From Guo Ci talk – demonstrated techniques related to spaceship/comparison operator
    • Changing order of the non-static data members, changes the default operator<=>
    • usage of std::tie and restoring the required order
    • Transformation of the data members before comparison, using make_tuple and std::cref
    • While float provides partial_ordering, what if we want strong_order?
    • Caveats related to std::tuple’s <=>
    • Synth-three-way
  2. Second item from Guo Ci talk – A more generic equal_range
    • An optimized way to reduce algorithm complexity, running on a sorted array
    • Showed benchmarking comparisons
    • Overview from the slides:

Next part of the meeting talked about “Adding Default Constructor using =default; to your class type”. We compared aggregate changes between 17 and 20. For 20, an aggregate cannot have “user-declared or inherited constructors”. 17 could. So 20 is stricter. Examples in the slides from godbolt.

The last part of the session talked about top level const in function deceleration, why clang-tidy complains and the rational behind it.

Thanks for reading!

Kobi

San Diego C++ Meetup #64 – July 16 2024

Hello all!

Summary of the recent San Diego C++ meetup session, took place Tue, July 16 2024 5PM Pacific Time.

Agenda in this meeting:

  1. New C++ Book – C++ Brain Teasers! – by Anders Schau Knatten – image above.
  2. Discussion on Throwing destructors
  3. Yet another hard to find(?) bug

Meetup event page here.

Recording can be found here:

San Diego C++ #64 Meetup recording

Details:

  1. I introduce “C++ Brain Teasers” book by Anders Schau Knatten. The PragProg page has 3 items that can be accessed. Puzzles 2,3,14. We went over each and discussed it. Super fun book, very recommended! Amazon link if you’d like also the colored printed book.
  2. Throwing destructors Discussion – noexcept and C++11, is it a good idea to throw from destructors? what happens when you aggregate a type with “noexcept(false)” ? How to workaround such issue? What do Core Guidelines say? It triggered lots of good discussions.
  3. And finally, a very hard to find(?) bug related to temporaries and lifetime. I saw it in production code few times in the past few months and wanted to share it with the group. Lots of good discussions here as well!

That’s it for July 2024. Working on the agenda for the next meeting!

Thank you for reading!

Kobi

100 C++ Mistakes and How to Avoid Them – by Rich Yonts – San Diego C++ Meetup #63

This month we hosted Rich Yonts, the author of a Manning publication title (MEAP/Beta) – 100 C++ Mistakes and How to Avoid Them

The recording can be found in our San Diego C++ Meetup channel:

San Diego C++ Meetup #63

The meetup even link can be found here.

About Rich Yonts:

Rich Yonts is a Senior Software Engineer at Teradata and a long-time software engineer using C++, Java, and Python. Rich held a number of technical and leadership roles during his many years at IBM and Sony. As an assistant professor, he has dealt with questions and issues of undergraduate and graduate students learning programming. He has deep experience on large code bases and considers himself both a student and a teacher of C++.

Rich cherry-picked few examples from the book and presented to the group.

Here is the summary of the topics:

  1. The challenges when dealing with old codebase in various companies. i.e. dealing with 98/03 and not beyond that.
  2. Narrowing values, uniform initialization to detect narrowing.
  3. Referring to an uninitialized data member and UB.
  4. Post vs pre increment of type instances.
  5. The fit fall of using setter when class invariant is not checked/violated and how to solve it.
  6. Shallow vs deep copy and how to ensure a deep copy with copy constructor and op=.
  7. The benefit of using the “override” keyword.
  8. Using “=delete” keyword to disable a specific function, vs the old 98/03 “method”.
  9. Variadic Templates.
  10. Using sprintf vs iostream vs std::format.

That’s it for June 2024 session.

Thank you for reading!

Kobi

San Diego C++ Meetup #62

Introducing: “Modern C++ Programming Cookbook” – Master modern C++ including the latest features of C++23 with 140+ practical recipes, Third Edition – By Marius Bancila

Meetup session page: san-diego-cpp

Recording (sdcppmu Youtube Channel):

San Diego C++ meetup #62

I continued using “google meet” where I can share the slides directly from my google drive, record a session, chat with attendances and it works beautifully!

Recent session introduced Marius’ newly published book which is really a good one (as usual :)!

The session started with a warm up, c++quiz Question #287. A bit of a tricky one. If you cannot remember the exact constructor diffs of std::string, you are out of luck 🙁

The main session/talk was on “Implementing the higher-order functions map and fold“. Taken from chapter 3 from the book (just part of the chapter). Oh – and we had a raffle of 3 ebooks!

Minutes:

  1. Map, fold implementation.
  2. Various overloads to support different containers that might behave a bit differently in the way we iterate over the items (std::queue<> is one example).
  3. The difference between the presented fold() and “C++17 fold expressions”.
  4. Composing(composing(composing(functions))) – with many examples.
  5. Fold left/right functions.
  6. Functions as first class citizens. Returning functions and composing a chain of functions.
  7. Overload operator* as a syntactic sugar when composing.

That’s it for this session. Next session should be a really nice one. Working on bringing a new speaker with an interesting topic!

Take care,

Kobi

San Diego C++ Meetup – #61 Apr 16 2024

Hello all,

Yet another summary of our latest session of San Diego C++ Meetup. America’s finest city endorsing America’s favorite language 😉

The meetup page can be found here.

San Diego C++ Meetup #61 recording.

Agenda summary

  1. C++ quiz – Arrays and copies during range-for-loop.
  2. The right auto/auto* – When using auto, and the deduced type is pointer, should we use auto? or auto*. Spoiler – use auto*. But why? This items takes us through the reasoning behind it. Hint – it helps readability and correctness especially with const involved.
  3. Does a default virtual destructor prevent compiler-generated move operations? – Fascinating journey investigating the implication of user defined destructor and move operation, talking about Howard’s famous table. Then – what does it mean in base classes when =default is used for virtual destructor. And finally, what is the best way to understand whether a specific class type is move constructible. Hint – it’s not that easy and straightforward, but we introduced a neat trick.
  4. And finall In-Place Construction for std::any, std::variant and std::optional – this item was inspired by Bartłomiej Filipek C++ Stories blog post.

That’s it for this session. Thank you for reading!

Kobi

San Diego C++ Meetup #60 – March 12 2024

Hello everyone,

San Diego C++ Meetup – 5 Years! 60 meetings! took place Tuesday March 12th 2024.

Here is the link to the meetup.com page.

Recently, I’m moving away from Windows+Teams.

Last session, we used Zoom utilizing Andreas Fertig’s account. Andreas was our guest speaker on Feb 2024.

For March, I tried using Google Meet but I missed the fact that I needed premium “GoogleOne” account and it was too late to add it. I have it now for next sessions. Hence the recording did not work.

No worries, after the meeting I spent ~20 minutes to record myself going over the agenda so we have it on record. Here is the recap:

San Diego C++ meetup session #60 – Recap post session recording

Our Agenda:

1. C++ Quiz
2. What is IILE/IIFE ? Deep dive to some of immediate invocation tricks.
3. Strongly typed syntax – How can we achieve a better, less error prone code? NamedType to the rescue!

More details:

C++Quiz – Question 126 was about Lookup rules. Question 29 was about invoking virtual functions in constructors and destructors (Don’t!), and finally Question 312 was about class/struct inheritance and access specifiers – “would this compile?”

The second part was about Immediately Invoked Lambda/Function Expression(IILE/IIFE). Few tricks, why is it useful, should we use std::invoke and benchmarks using Bartek’s cppstroies blog post.

And finally, we discussed C++ and strong types, user defined string literals and finalized with NamedTyped library example.

That’s if for the 60th session update, thank you for reading!

Kobi

Exploring Polymorphism in C++ – San Diego C++ Meetup Feb 2024

Hello everyone,

We had a special guest speaker on Tuesday, Feb 20th 2024. Andreas Fertig!

This is not Andreas’ first appearance in our Meetup and I was super happy to host him again!

This session went over an interesting and extremely useful information – Runtime vs Compile time polymorphism.

The event page can be found here.

Recording, as usual can be found in the San Diego C++ Meetup Youtube channel.

Exploring Polymorphism in C++: Run-time vs. Compile-time by Andreas Fertig – San Diego C++ meetup

Presentation material can be found in our dropbox location (join the meetup to gain access).

Summary of the material discussed:

  1. Cost of runtime polymorphism.
  2. CRTP as an alternative, lower runtime cost alternative.
  3. Policy based design.
  4. Example of policy – std::unique_ptr and the deleter policy.
  5. std::sort and the sorting policy.
  6. Another example of the Policy based idiom, checked array boundaries with multiple types of handling errors – all with Policy design.

That’s it for this month!

Next time, it’d be our #60 session. Yes! 5 years of San Diego C++ Meetup. We have over 1650 members. We started off on March 2019, with around 70 members!

Thanks for reading,

Kobi

San Diego C++ Meetup #58 – Modern C++ Design, chapter 2

Hello all,

Quick summary on a great Tuesday night on Jan 16 where we went over chapter 2 of Andrei’s A. book – Modern C++ design.

meetup-event link

Recording:

San Diego C++ Meetup sdcppmu Youtube recording

Here is the overall summary of what we went over in this session:

  1. Compile time assertions
  2. Partial template specialization.
  3. Local classes.
  4. Map integral constants to types. Compile time dispatch based on numeric values. Boolean conditions.
  5. Type to type mapping. For overloading and function template partial specialization.
  6. Type selection, based on compile time boolean conditions.
  7. Detect convertibilities and inheritance at compile time.
  8. TypeInfo wrapper over type_info. Value semantic and ordering comparisons.
  9. NullType, EmptyType placeholders classes.
  10. The last part – “TypeTraits template to offer multiple general purpose traits to help us tailor the code to specific categories of types” – as I expected – we did not have time since we were already overtime (around 1hr and 10 mins) but feel free to go over the last 4-5 slides with the type_info and the overall type traits class.

Overall, in the past 2 sessions (Dec 2023, Jan 2024) we showed the power of Templates with the great help of Andrei’s book. As I mentioned, the book is unique and even after 20+ years, still ranked top IMO. The first 2 chapters are the basic building blocks, the pillars for a better understanding of Generic programming. Worth investing time and reading it.

Thank you!

Kobi

San-Diego C++ Meetup #57 “What can Class Template Policy Design do for your codebase?”

Hello all,

Short summary on the previous San Diego C++ meetup, the last one for 2023.

It took place on December 12th 2023.

The topic for the meetup was Class Template Policy based design. All based on the first chapter of Andrei’s Modern C++ Design book from 2001.

Here is a link to the meetup event.

Recording on our sdcppmu channel here:

Policy Based Class Design recording on sdcppmu YT channel

The talk goes over the first chapter of Andrei’s book highlighting the huge advantage of using this technique in your code. And in particular, it described the following items:

  1. Templates, specialization of Class Templates, functions, what is template-template parameters.
  2. Examples of how Policy design can improve readability, flexibility of your design.
  3. Static vs Dynamic dispatch/polymorphism.
  4. How to mix different, orthogonal policies
  5. How to mix policies with some dependencies (though this is not a recommended approach).
  6. Enrichment APIs and how Templates do not instantiate functions unless being used.
  7. Customizing structure with Policy Classes.
  8. Examples of Policy classes in the wild. ACE library, Standard library.

Next month will discuss chapter 2 that describes more of the important Template techniques.

That’s if for now.

Have a great holidays, hoping for a better 2024!

Kobi

San Diego C++ Meetup #56 hosting Šimon Tóth – “Patterns of interview solutions”

Hello all,

This post is about the latest San Diego C++ Meetup session, held on Tuesday, November 14 2023. It was a virtual meeting, recorded and uploaded to the sdcppmu Youtube channel. Here is the recording:

San Diego C++ Meetup #56 hosting Šimon Tóth – “Patterns of interview solutions”

Here is a link to the event on meetup.com

This time, we hosted Šimon Tóth who gave a wonderful talk named “Patterns of interview solutions”.

A bit on Šimon:

He can be found on the following Social media: linkedinhachyderm.iosubstackmedium and github.com .

Books on leanpub.com:

Summary of the content presented

The talk is divided to 2 parts. First part presented the available algorithms in C++. Including some from the ranges library. Total of 126 algorithms were bunched into categories and Šimon quickly went over the benefits of each category with some examples.

The second part presented couple interview-like questions and their respective Modern C++ solutions:

  1. Sum of distances to all nodes – Šimon demonstrated solving a problem while looking at it from different persoective.
  2. Longest palindromic substring – showing few ways to improve your algorithms using different methods.

In all of the above, Šimon is using ranges, algorithms and Modern C++ syntax and mechanism.

Hope you enjoy the recording!

Take care,

Kobi

Let’s embed it with C++! – San Diego Meetup #55 October 30th 2023

Hello everyone!

As usual, I’m providing a short summary to the previously held San Diego C++ Meetup session.

But before this, I’d like to promote the next, upcoming one – we are hosting Šimon Tóth that will present his talk – “Patterns of interview solutions“. This will happen on Tuesday, November 14th, 930am Pacific time. Looking forward!

The recording of the October meetup, named “Let’s embed it with C++” can be found here:

“Let’s embed it with C++” recording on youtube, sdcppmu channel.

Here, you can find the past event Link on the meetup.com page.

The original meetup session was scheduled to October 10th but I had an emergency travel to Israel supporting my family as I lost my nephew during the first few hours of October 7th war.

So what did we discussed about during this 1:30 hrs of this session?

The idea was to provide an overview, mostly for beginners to intermediate levels on how can we use Modern C++ features in Embedded environment. The talk was heavily inspired by this excellent book By Christopher Kormanyos:

I also started by mentioning 2 great talks. One from Dan Saks, cppcon2016 – extern c: Talking to C programmers about C++, and the second one from cppcon2022 – Erik Rainey, “Using C++14 in an Embedded ‘SuperLoop’ Firmware”.

High level topics discussed:

  • Using class types for encapsulations, organization of code, as well as namespaces
  • (No)Overhead demonstrated using various features like class types, constexpr, using templates to improve code generation.
  • Showing various code/options side by side using Compiler Explorer and the new CLion feature to “Show assembly” (what a great feature JetBrains!).
  • Discussing the subset of C++ that is useful for embedded. The various trade-offs using STL(Standard Template Library).
  • Using integral macros from “cstdint”. Thinking about portability of your code working with various OS and compiler vendors.
  • static_asserts, limits for more compile time evaluation.
  • Using std::array as a replacement to the C array.
  • Why STL algorithms are a good fit for your programs? How do they compare to raw loops, runtime speed and generated code.
  • The advantage of using User Defined string literals (one of my favorite features of the language!). How does it contribute to strongly typed elements with zero cost abstraction!
  • C++ Core guidelines, using std::span<> (and gsl:: library if you are working on <20 standard).
  • Demonstrating template integer sequences with Modern C++.

Conclusion is that C++ is more than suitable for embedded. You need to know how to use the language correctly, take advantage of templates when applicable, know STL well to avoid pitfalls!

That’s it for now. Hope this session is useful for various people at least as a good introductory session to various Modern C++ features.

Until next time, stay safe,

Kobi

Introduction to Package Management with Conan 2.0 – by Chris McArthur – JFrog

Hello,

We had another great night in San Diego C++ Meetup, the 54th meeting (Sep 12 2023). This time hosting JFrog and specifically having Chris McArthur presenting Conan 2.0.

The session was super informative and easy enough that even if you’re hearing about Conan for the first time, you’d be able to pick it up quickly and start using it in your projects.

The meetup page for this event can be found here.

San Diego C++ meetup #54 – Introduction to Package Management with Conan 2.0 – by Chris McArthur – JFrog

So what did we learn?

  1. Describing what is Conan, how does it solve the gap in C++ wrt package management.
  2. Demo – building a small application pulling in dependencies using Conan.
    • spdlog was used in the first demo
  3. What is conanfile.txt, how to bring in dependencies, installing and integrating into CMake files.
  4. Dependencies graph and the transitive trait of it.
  5. Using VSCode as IDE. Clion has also newer version of their Conan plugin that is worth looking at.
  6. More demos, with more packages, demonstrating different versioning, local caching of the packages. All working flawlessly.
    • glad
    • glfw
    • tinycthread
    • linmath
  7. Using presets
  8. How to use test_requires packages – e.g. bringing gtest package for build and testing – but not for production distribution.
  9. What is Conan lock-file and how to utilize it. CI, Reproducible builds.
  10. Picking up packages from conan-center/conan.io
  11. Writing a simple conanfile.py to distribute an app as a Conan package. (Conan Recipe).
  12. Introducing Conan extension.
  13. Developing Packages Locally.
  14. Resources on the web – ACCU talks, Conan blog, and future talks in Cppcon2023.

Thanks again for Qualcomm for paying the meetup fees, Charles Bergan, for supporting this group.

Thank you for reading!

Kobi

San Diego C++ Meetup #53 – notes

Hello all!

We had a great night on Tuesday August 15. The San Diego C++ meetup #53 took place.

Here is the recording

San Diego C++ Meetup #53 recording

Here is a short summary of the topics and discussions we went through:

  1. Introducing the next month session – JFRog will introduce Conan 2.0. Chris McArthur will present it on September the 12th. Here is a link to the event on meetup.
  2. I introduced the new, 3rd edition of range-v3 booklet. You can find it here. This is by far one of the best and fun resource to use for learning range-v3. The material, content and quality is just premium. Run, don’t walk and purchase it. I love the printed edition. It’s a piece of art! In the meeting we went though the FizzBuzz example that can be found on walletfox website itself.
  3. Next, cppquiz #354 . std::exit() related.
  4. User Type categories – we discussed “Trivial and standard layout“, explaining the differences and why it is important to know about these categories.
  5. And finally, I presented a topic which I really like and close to my heart – properly writing multi-threading code. Well – there are many many things not mentioned in this 40 minute talk. But the goal was to bring some awareness on bad patterns or practices vs better, safer and maintainable patterns. We mentioned associating Mutex to its controller data, showed how Rust is doing it (in one slide), and eventually, went over POSA2Thread Safe Interface“.

Thank you for reading!

See you next time!

Kobi

Modern CMake Best Practices for Library Authors by Alex Reinking – San Diego C++ Meetup #52

Hello everyone,

I’ve been super busy at work hence the delay in this blog post that summarizes our 52nd San Diego C++ Meetup.

This time, we hosted a Qualcommer co-worker – Alex Reinking.

Alex is very knowledgeable in many fields and in specific, he likes build systems. We had an offline chat before he submitted the talk for the July session. We talked about CMake, FetchContent, Package managers and it was very clear to me that Alex would be great speaker in our meetup.

Here is the recording:

San Diego C++ Meetup recording – Alex Reinking talking about Modern CMake

Alex started by taking us through the general idea of CMake as a build generator and also mentioned its popularity in the community.

Few important bullet points and take away:

  1. Under the hood, Package managers do more that you realize. Like patching code and similar.
  2. As a library, we would like to provide the users the best experience when using our library with CMake.
  3. Alex has a very nice demo posted here: alexreinking/sdcppmu-diffuse. Building on Linux and MSVC with Emscripten targeting WebAssembly(Linux)/SDL(Windows).
  4. Always use the latest CMake. This is something that I like in CLion which is usually bundled with the latest, or almost latest CMake.
  5. CMake’s find_package() is the one true way to locate dependencies.
  6. FetchContent is nice but it will clutter your CMake “env”, unless upstream project is written well enough.
  7. Halide (see Alex’s Bio) has CMake helper functions like “add_halide_generator“, “add_halide_library“) – a generator that must run on the host system, even when cross compilation is involved.
  8. Alex walks us through the path of getting your library “FetchContent” friendly for consumers.
  9. Interesting discussion on Why we should not create 2 targets (shared and static for example).
  10. Why not GLOB for sources.
  11. Discussion on what to place and NOT to place in your CMakeLists.txt. For example – compile options – probably should go into Presets.
  12. Other CMake related constructs that were new to me: ALIAS for add-Library, BASE_DIRS + target_sources, GenerateExportHeader, CMakeDependentOption, CMakePackageConfigHelpers, configure_package_config_file, write_basic_package_version_file.

More information can be found in the recording.

Thank you!

Kobi


Abstract
In this talk, we will discuss the best practices as of the latest CMake version for writing C and C++ libraries that are easy for everyone to consume. We will build a toy application that demonstrates switching between static and shared library types, dependency management, creating accurate CMake config packages, and cross-compilation involving code generators. We will see how writing CMake lists that are minimal and declarative leads to more correct and maintainable builds.

Bio
Alex is a research scientist at Qualcomm Compiler Labs. He got his Ph.D. in Programming Languages from UC Berkeley in 2022. Since 2020, Alex has served as an open-source maintainer for Halide, a popular DSL for optimizing image and tensor processing; in this capacity, he has overhauled the build system, CI infrastructure, and the release process. Alex has contributed build system improvements to prominent open-source projects, including WABT, tinyxml2, and Herb Sutter’s cppfront, and has found and fixed large CMake bugs. His blog page: https://alexreinking.com

Link to the event

Ben Deane – San Diego C++ Meetup! June 13 2023 #51

Hello all,

It was yet another exciting night this time hosting Ben Deane!

His talk named “Applicative – the Forgotten Functional Pattern

Here is the recording:

Ben is a great speaker and he loves Functional programming 🙂

First – the Abstract:

Abstract

Monads get all the press. Functors are often presented as a prerequisite to monads. Applicative (functor) almost never gets mentioned. But it’s massively useful – to the point where a lot of the time when we think about a “monadic interface” what we really want is an applicative interface.
This talk will put applicative in the limelight, showing how it works and why it’s so powerful, with lots of examples grounded in code; there are no category theory diagrams in this talk. Attendees will come away with a solid understanding of the applicative pattern and its many uses. And as a byproduct, their opinions of monads will probably change too.
Optionals. Expected. Ranges. Futures. Parsing. Validation. Error Handling. Transforms. Functions themselves. These are all examples where thinking in terms of applicatives (and importantly, NOT just reaching for “a monadic interface”) helps us write simpler, more composable code. If you’re kind of fuzzy about functors and monads, what’s missing is probably the third piece of the puzzle: applicative.

Summary

I’d classify this talk as intermediate++. Ben mentioned many concepts like optional, ranges, Monads and std::expected just to name a few.

Throughout the talk, Ben presents Haskell syntax and C++. The Haskell part is easy to grok though if you are seeing this syntax for the first time, you might want to pause the recording and make sure you understand it since the sub-sequence slides will build on top of it. There are also some heavy generic programming slides that might need more attention when you go through the recording. No spoilers here on the conclusion and the take away (regarding Monads vs Applicative)

Overall I learned a ton from this talk and have some homework to go and explore more on this domain.

We have an incredible future ahead of us in terms of new syntax and new language and library capabilities.

I’d end with a meme 😉

About BEN DEANE

Principal Software Engineer at Intel
Ben has been programming in C++ for this whole millennium. He spent just over 20 years in the games industry working for companies like EA and Blizzard; many of the games he worked on used to be fondly remembered but now he’s accepted that they are probably mostly forgotten. After getting more interested in modern C++, in the teens he started giving internal company talks and then talks at various conferences, spreading ideas about types, algorithms and declarative and functional techniques. In 2018 he left the games industry and worked in finance for a short spell, writing high-frequency trading platforms using the most modern C++ that compilers could support. Now he is a Principal Software Engineer at Intel where he puts monads inside your CPU.

Thank you!

Kobi

YACRB – Yet Another CoRoutines Blog

Based on a true story from the San Diego C++ Meetup #46 1/2023

After our Jan 2023 virtual meeting I wanted to summarize all the cool stuff we learned during the session. This is the short version of the talk that I (Kobi) presented on Tuesday, Jan 17 2023.

First, I’d like to have few shout outs to few people that inspired this talk.

The first one, is Pablo Arias. Pablo had a 3 parts Coroutines blog post that explains how to use C++20 Coroutines and Linux Kernel’s feature io_uring. First part can be found here. It includes link to the source and discussion on reddit. This blog post is written so well that it helped me to finally understand how Coroutines work and I wanted to present it to the members of the San Diego C++ Meetup.

Next, I’d like to thank Rainer Grimm from the modernescpp blog. Rainer has many books that I mentioned during the San Diego C++ sessions, he has Educative.io class and he is a known speaker in many C++ conferences. His C++20 Coroutines blog posts are very helpful.

Coroutines change the way you write Parallel and Multi-threaded code, to the better IMO. Once this topic is well understood, you will want to use it in your code base as it’d simplify many constructs.

I’d like to touch upon few main issues when it comes to Coroutines. Why this is so hard?

  1. First, it is a complicated domain. Async, MT and similar are usually harder to reason about.
  2. There are new keywords that we need to learn and understand how to use.
  3. There is a new Coroutines API. How do we use it? What do we need implement? do we need to inherit? what is the new contract between different pieces of the app when it comes to Coroutines?
  4. Compiler magic. The compiler does a lot of things under the hood and we need to be aware of the various things that are happening. We usually know that compiler might generate special functions for us (e.g. copy constructor) but Coroutines is a new level of “compiler magic”.
  5. When Coroutine function is running, what is the thread context? what is the thread context of “Awaitables”? what happens when we resume? which thread is being used here? These are real questions that we need to answer to fully understand this domain. The regular execution flow is very different from what we are used to see before, even when threads are involved.
  6. C++20 gave us “the assembly of Coroutines”. This is how I name it. During the meetup session i mentioned that in his latest book, Bjarne does not recommend writing your own Coroutines boilerplate code and use libraries instead. During the talk, I used the low-level Coroutines API.

I presented the following from modernescpp:

This is a good image illustrating the new flow of function calls.

There are numerous amount of blog posts out there that explain what is a Coroutine function/object/frame. For our purpose in this post, I’ll touch upon few elements but will not cover everything under the sun when it comes to Coroutines. The goal is for the readers to have basic++ knowledge that jump-start them to work on more complicated constructs.

What does qualify a function to be a coroutine?

It has one or more specific keywords for example:

  • co_await – suspend and resume execution of the function while keeping the context (think stack) intact!
  • co_return – return results from Coroutine frame/function.
  • co_yield – supports generator functions.

coroutines proposal N4402 describes design goals.

C++20 Coroutines framework includes many functions to support various use case and it is highly customizable. Main parts:

  • Coroutine handle – this is your handle to the Coroutine context.
  • promise object – think about it as a way to communicate results back to a waiter.
  • Coroutine frame – holds the state of the Coroutine function.

Task and Promise

Promise provides result or exception. It is the result of the work done in the Coroutine function.

A pseudo code that represent a possible promise struct, residing inside a “Task” will look like the following:

Promise is highly customizable. User can control whether:

  • Coroutine should be suspended before it runs (initial_suspend), or before it ends (final_suspend).
  • unhandled_exception – invoked when uncaught exception happens.
  • get_return_object – returns, constructs the Coroutine object itself, many will name it “Task”.
  • return_value – This is “magically” invoked by compiler-generated code when we write something like co_return val;
  • yield_value – related to generators when we invoke co_yield val;

get_return_object() mentioned above is super important. It is creating a “Task” instance. Promise type is nested inside a Task.

Promise will communicate the results (or void) using the return_value/return_void/yield_value.

Awaitable

Awaitables are structs/classes that we, the author of the code/framework will write.

An Awaitable, is a type that you co_await on its instance.

So how does a birds-view Coroutine structure in your program would look like?

Here is a pseudo code of Task with a nested promise, an awaitable with operator co_await() and finally, a Coroutine function named “func”. This Coroutine function returns a “Task” as its return value, and will co_await on 2 different awaitables. It returns result using co_return.

Coroutine Handle

This is a super important element that enabled the caller to access the Coroutine frame/API – for example resuming a suspended Coroutine.

In the above code snippets, you’d find the handle in class Task – which is mapped to a Coroutine object. In the following code snippets, you’d also find this handle being passed as a parameter to the Awaiter::await_suspend(handle) function.

Coroutine Frame

This is internal, i.e. not really visible to us, authors of the code, most likely a compiler’s heap allocated state.

It containes a promise object with all the Application related context, aka my Application business logic.

Example – Coroutine with UDP server and io_uring Example

As mentioned, this part was heavily inspired by Pablo Arias blog post.

In this exercise we will demonstrate how we can combine Coroutines with file reading/writing as well as working with networking protocols.

In the meetup recording you can find the conan 1.x configuration, using crc_cpp and fmt.

Demonstrating Synchronous first

Before we jump into demonstrating how coroutines + io_uring makes our life easier, let’s show the synchronous part first.

In the above we show a udp_connection runs a blocking read() function. Once it is done, it will populate a vector and compute CRC16 to show some “work done” (CRC is a 3rdparty library).

udp_connection::read() would look like this:

Pretty simple and straight forward. Compute CRC16 is just looping over the buffer and computing the value. It is omitted here for brevity but the information can be found on meetup slidedeck (and my github.com).

Struct Result is just a simple struct to aggregate and collect information that will be eventually printed to screen:

Here is the complete “main loop” for the Sync example:

I’m just showing 2 connections but you can easily extrapolate it to be >2.

Enter Coroutines and Linux io_uring

First let’s discuss io_uring. The simplest way to think about it, is submitting a request to the kernel to do it on user-space behalf, and then gathering results back when work is done and results are ready:

Once we have this concept understood, we will tie it into Coroutines using the following flow:

The part where we Read UDP will be offloaded using Coroutines mechanism in conjunction with another Coroutine piece that will write results into files. For each context, the UDP read and File Write operations would be 2 different awaitables triggered by the same Coroutine frame.

The nice part about Coroutines is that the function “launching” these awaitable will be suspended and resumed while the entire function’s context stays “intact”. This feels very natural when reading the code. There are no messy state machines and complex locking code. It’s all abstracted out using the Coroutine framework.

The following diagram depict how Coroutine frames would look like. A Coroutine frame is mapped here to a function names readUdpWriteFileAsync().

There are couple arrows going out from the frame into functions. Think about these functions as awaitables.

The diagram shows 2 frames. Reason is that we’d have the main() function looping over 2 connections. Each connection will invoke the Coroutine function, creating a whole separate Coroutine frame and context.

When we invoke the read_udp_socket inside readUdpWriteFileAsync() Coroutine function, it would be suspended so we can continue our main() iteration moving to the next udp_connection, this is while the previous one is “taking its time” reading from a socket in a separate thread.

This is the true exciting moment of Coroutines. I have a loop calling a function, this function will shoot an async operation, running on some thread (details below) doing its thing while I continue looping and handling the next iteration. When I need to go back to _a_ Coroutine frame, it will be there waiting for me with the entire stack context intact!

Let’s take a look at main()

I just create 2 UDP connections objects and you can easily extend it to >2. No socket activity here, just initialized UDP class type objects.

The following code is important. It will actually trigger the creation of the Coroutine frames. 2 in our example. Each time we invoke readUdpWriteFileAsync(), a Coroutine frames created, returning a “Task” class instance. More on “Task” below. We just keep the tasks in a vector so we can use each later.

liburing is used here to abstract out some io_uring boilerplate code.

Pablo had a nice liburing wrapper that I’m going to use here. It’s a simple wrapper over io_uring handle, implementing RAII (init, destroy). This is going to be very handy when interacting with io_uring via liburing library.

Promise & Task

After introducing the concept and some of the non-coroutine framework, let’s delve into the actual Coroutine-framework details.

We will start with defining the “Task” class type:

There is an inner struct names promise_type. As mentioned above, promise would include my business logic and you can see class data member named result.

Few important functions that I implemented (there is also the inheritance way btw).

  • get_current_object – Instantiating and returning of a Task. Just calling it constructor with this argument.
  • I don’t care about exceptions. It’s an empty method here.
  • return_value – will be “magically” invoked by compiler-generated code. My function definition is going to set the incoming parameter to my internal data member.
  • Don’t care about initial_suspend/final_suspend. I’m returning suspend_never which means – do not suspend at init/cleanup points.

Let’s zoom out and see what else we have inside class Task:

struct promise is collapsed as we’ve already discussed it.

Task has a constructor that takes promise* parameter. No surprises here since promise_type‘s get_return_object() returns Task(this).

The Coroutine handle is obtained from promise. The Coroutine handle is our mechanism to control the Coroutine ‘sflow. If we hold a Coroutine handle, we can, for example, check if the Coroutine is done() processing or we can resume() the Coroutine. We use this handle few times in our application.

Task has one important data member. The Coroutine handle! This is our opaque handle to the Coroutine frame/context.

  • get_result() – will return the (final business logic) result, residing inside the promise_type.
  • done() – will return true if the Coroutine is done executing. Essentially when we exit from the Coroutine function/frame. In our case existing readUdpWriteFileAsync().
  • Destructor destroys the handle.

The awaitables

We have 2 awaitables.

  1. For UDP read
  2. For writing data to files on disk.

Here is how it would look like:

The Coroutine function/frame is readUdpWriteFileAsync().

  • When we want to co_await on the UDP read part we will call co_await read_udp_socket. A thread will be created and used to fulfill and run this context. When we are done, we are going to resume the suspended frame. We use the Coroutine handle to resume the suspended Coroutine. read_udp_socket is our first awaitable.
  • When this specific frame instance is resumed, we will interact with io_uring framework, submitting job to the kernel to execute. Here we don’t need to worry about any user space threads since this job is executed in the context of kernel space. We just need to collect the results when we are ready. When results are ready, we will resume the suspended frame, running it to completion. Task will be done here.

Coroutine function readUdpWriteFileAsync

Here is the implementation of our Coroutine function with 2 Awaitables.

First Awaitable is read_udp_socket(). You can notice the special keyword “co_await”. More details to follow.

Next, we create a file and move to the next Awaitable: write_file_awaitable(). co_await new C++20 keyword is also used here.

At the end of the frame, we return the result using co_return keyword.

When running the applications, lots of stuff happening by a compiler-generated code. For example, when we call the Coroutine function, a Task::promise_type::get_return_object() function is immediately invoked. A debugger is a handy tool here to view the stack-trace. You’ll notice some strange jumps of the debugger as if the Task function readUdpWriteFileAsync() is “exiting” but it’s not. It’s just the debugger showing that a Task object was created and it will jump “all over the place”.

To assist us with collecting results AND holding the coroutine_handle, I will create a simple struct to aggregate both:

Awaitable read_udp_socket

Let’s zoom-in into our first Awaitable. It’s a class type with operator co_await:

operator co_await() is a new C++20 special construct. We need to return an “Awaitable” type instance. What is Awaitable? It’s a type with a specific interface that we need to implement. Note the return value of operator co_await: it’s the Awaiter struct instance initialized with udp_. What interface do we have in Awaitable?

  • await_ready – we return false. We are not ready yet! and work needs to be done. We need the Task/frame to be suspended!
  • await_suspend – An customization point before we suspend the “outer Task/frame”. We keep the coroutine_handle by assigning it to some structure as we will need it soon! we need the handle to tell the Task/frame “continue/resume”. The handle is our way to control the flow of the Task!

So the idea is simple. The outer Task calls co_await on the Awaitable. Operator co_await kicks in. We keep the coroutine_handle before we suspend the Task and executing the work on a dedicated thread. Remember, now, the outer Task is suspended! The main loop will continue with the next UDP connection instantiation.

When we resume the Awaitable, await_resume() is invoked on this Awaitable instance, and the result is returned as the value. If you set a breakpoint at Awaiter::await_resume() you will see how invoking resume() on the coroutine_handle will call some compiler generated symbol which will invoke Awaiter::await_resume(). It’s all can be viewed as part of the gdb stacktrace. Here is a typical example:

You probably noticed the function readSync(). This function does a simple blocking UDP read + CRC16 check. When it’s done, it takes the coroutine_handle that was passed as an argument and call resume().

Writing to disk using io_uring

This is the second Awaitable. Unlike the UDP one, this does not run on std::thread context, but using Kernel threads instead. Here is a helper struct named write_ctx. We are going to use it as an opaque data/cookie to the Kernel and receive it back later(think cookie).

The struct has similar idea as the UDP’s one. It includes std::coroutine_handle<void> and some result (status_code).

And here is the full write_file_awaitable Awaitable class type with its internal operator co_await().

The constructor of this Awaitable is obtaining io_uring_sqe which is a token corresponding to the requested job to be done by the Kernel on our behalf. We request to write a chunk of memory to file using this token. This is the first part where the instance of the Awaitable is being created.

Now the co_await operator kicks in. Same idea as UDP. We need to implement few interface functions.

  • await_ready() – no, we are not ready, please suspend the Task.
  • await_suspend() – customization point before the Task is suspended. We cache the handle and we tell the Kernel – please associate the following piece of data with the token. Remember, without this coroutine_handle we cannot resume when we are done with our file write! When the Kernel is done performing the requested job, writing to file in our case, it would provide us back the opaque data that we provide to it when calling io_uring_sqe_set_data(). Finally, we call io_uring_submit() to get this whole io_uring process going.
  • await_resume() – when the Task is resumed, the status_code is returned back. The status_code in this example correspond to success/failure of writing into file.

io_uring results – processing logic

It’s time to gather results and process it.

Remember that we had a vector of “Tasks”?

These Tasks are actually mapped to our Coroutine functions.

When we invoked the Coroutine function, we got a “Task” back as a return value and “push_back” it to our std::vector<Tasks>.

Task class type has a function named “done“. This function will return the Coroutine handle’s “done” state. If it’s true, we are done with the Coroutine. Either we have all awaitables done or exception propagated. The important part is that the function is done and we can query the handle in order to figure it out.

Function all_done just iterates over the vector and ask if we are done.

When we are all done, we just print something. This is a simple final “processing” and obviously real-life logic would do more here.

But inside the while loop, there is a special call to consumeCQEntriesBlocking(). Let’s take a look and discuss the last part of this flow.

When we submit a request to the Kernel via io_uring framework, at some point of time, we would like to retrieve the result (or error if such returned back).

io_uring_submit_and_wait() is a liburing function to block if queue is empty and if we have at least 1 completed entry waiting for us, we will return from the function and process it.

This is what consumeCQEntries() function is doing. The coroutine magic part is the line that invokes resume() on the handle.

When we submitted our request, we also submitted a “cookie”. An opaque data that we are now retrieving back! We static_cast<> it and now have access to the status_code as well as to the Coroutine handle! This is a key element for us to control the Coroutine.

We can now resume the Coroutine and the function readUdpWriteFileAsync() will continue to run. In our case will complete and exit using the co_return keyword. It will return the Result struct instance.

Handle’s done() is now going to return us “true”.

When we call .resume() and the Coroutine continues to run, it’d run on the “main” thread. You can think about it as the main thread is borrowed to execute the remaining code in the Coroutine function all the way to the co_return statement.

Summary

The above demonstrated single Coroutine function returning a “Task” class type, with 2 Awaitables – “UDP socket receive” and “file write” using Linux io_uring. We showed how to use Coroutine handle to obtain info on the Coroutine frame as well as control the actual flow of the program.

There is a big advantage of having the context of the frame kept intact, valid, in one location while all kinds of jobs are triggered, suspended and resumed without any need for synchronization. In traditional multi-threading/multitasking you’d need synchronization primitives in order to achieve the same.

Thank you for reading!

Kobi