Aggregates: C++17 vs. C++20 -- Andreas Fertig
Sometimes the small changes between two C++ standards really bite you. Today's post is about when I got bitten by a change to aggregates in C++20.
Aggregates: C++17 vs. C++20
by Andreas Fertig
From the article:
Attendees of my training classes usually assume that I know everything. I can say sorry, but that's not the case. One day in the past, I showed the following example during a class:
struct Point { int x; int y; }; Point pt{2, 3};The class did cover C++17 and C++20. The code of
Pointis a reduced version for this post. We were talking about C++17's structured bindings. I usePointto show the decomposition using C++ Insights.I showed the behavior and certain variations while answering questions from the attendees. One question was about move and copy. The question leads me changing the initial code to the following one:
struct Point { int x; int y; Point(Point&&) = delete; A }; Point pt{2, 3};
2 3 4 5 6 7 8 |
|
As you can see, in A, I deleted the move constructor. As far as I remember, this topic was more or less the last one for this day. Everything went well and as expected.
The next morning one of the attendees approached me with the question of why the code didn't compile on his machine. My usual answer here is that if C++ were be easy, I wouldn't have the job I have. Somehow this never shuts down such questions. I like curious attendees.
He shared his code via Compiler Explorer. Guess what? His code looked exactly like mine but didn't compile. Here is the error message from the compiler:
Explaining machine code from the ground up! 
A new episode of the series about SObjectizer and message passing:
A new episode of the series about SObjectizer and message passing:
In this post, we'll dive into implementing this technique in C++17 and then explore how it evolves with the application of C++20 concepts to the code. The goal is to simplify the code by eliminating the need for cumbersome constructs like enable_if and introduce further improvements in C++23.