C++23
C++23 is now feature-complete. The C++23 standard documentation is now undergoing it's approval rounds before being finally approved as the latest ISO C++ standard - probably later this year/early 2023.
So https://en.cppreference.com/w/cpp/compiler_support
gives what is almost certainly a complete list of C++23 features.
So https://en.cppreference.com/w/cpp/compiler_support
gives what is almost certainly a complete list of C++23 features.
I still haven't figured out a lot of C++20*, having to wrap my brain around C++23 is gonna be a pain.
Let's hope decent C++ authors have tutorial books available ASAP.
*For that matter there's "stuff" from C++11, C++14 & C++17 I don't have a "handle on" yet. For instance I have never heard of std::visit before until a day or two ago.
https://en.cppreference.com/w/cpp/utility/variant/visit
Let's hope decent C++ authors have tutorial books available ASAP.
*For that matter there's "stuff" from C++11, C++14 & C++17 I don't have a "handle on" yet. For instance I have never heard of std::visit before until a day or two ago.
https://en.cppreference.com/w/cpp/utility/variant/visit
Last edited on
I wouldn't whinge if Rainer Grimm is first. I would really like a print/eBook bundle no matter who writes it.
Even if it were Nicolai M. Josuttis.
Even if it were Nicolai M. Josuttis.
I notice MSVC is far behind in being C++23 compliant compared to other compilers according to that chart.
Strange how MSVC is the only compiler currently 100% C++20 compliant, so let's hope the MSVC people get crackin' on making it happen for C++23.
Strange how MSVC is the only compiler currently 100% C++20 compliant, so let's hope the MSVC people get crackin' on making it happen for C++23.
VS is ahead on C++23 library features (as header files) but well behind on C++23 core (as in the compiler) features. I suspect they're doing internal changes to their C++ compiler and once that has been completed then the C++23 core features will roll off the production line...
| I still haven't figured out a lot of C++20, having to wrap my brain around C++23 is gonna be a pain. |
That's the 'downside' of using C++. Every 3 years there's new stuff to learn - or continuously if you learn about new features when they're been approved for a new standard (especially as now the major compiler vendors [VS, gcc. clang] tend to continuously introduce new features from the next standard). So C++ programmers have a life-time of continuous learning ahead...
IMO releasing a major new standard every 3 years is too frequent.
I would prefer a 4-year release for major features with minor ones, DR's etc 2 years after a major (eg a tik/tok cycle).
This would allow more time to get to grips with major changes to the language before you're hit with new ones - whilst allowing needed DR's, small changes etc to be introduced more speedily.
Last edited on
at least the pace of destroying older stuff is much slower. Very little is removed, and when it is, it still works on most compilers with a warning. That means the new stuff is sort of optional: we see it here every day, 1990s C++ still works (for better or worse). My company adopts slowly ... will probably be a few years before we consider using 20 at all.
Last edited on
I haven't been actively following the standardization process for several years so a bit of the stuff on the cppreference page was a surprise to me. But, after about 90 minutes clicking through it, I have some comments on certain features:
1. "if consteval" - I guess this is intended to replace std::is_constant_evaluated, because the latter is error prone:
if constexpr (std::is_constant_evaluated()) { this_always_executes(); }
What went wrong with the process that caused us to get is_constant_evaluated first?
2. "Deducing this" - This probably allows
class a { int x; public: int& get() { return x; } int const& get() const { return x; } };
to be written like
class A { int x = 0; public: auto& get(this auto& self) { return self.x; } };
Essentially the member function template allows the compiler to write both overloads for you. In really generic code this could help collapse four overloaded function templates into one.
This feature is maybe the first step away from the idiosyncratic syntax involving member functions, and maybe the first step towards a uniform function call syntax. Syntactic uniformity would improve C++'s (sufficient) generic programming support, but it also would help improve the unavoidably awful meta-programming features that are being added to the language, so this feature is a solid step in the right direction.
3. "out_ptr and inout_ptr" - this is a tool for getting smart pointers to work smoothly with C-style interfaces that take a T** and write the pointed-to T*. This will be useful, but why on Earth did they choose inout_ptr over in_out_ptr!?
4. "move_only_function" - What is it for? I cannot understand the purpose of a new feature from a diff against the old specification, but the linked paper contains neither a design discussion nor even a reference to that discussion.
5. "<expected>" - I didn't see any need for more error-handling schemes to be added to the standard library.
Overall C++23 will be a minor improvement.
1. "if consteval" - I guess this is intended to replace std::is_constant_evaluated, because the latter is error prone:
if constexpr (std::is_constant_evaluated()) { this_always_executes(); }
What went wrong with the process that caused us to get is_constant_evaluated first?
2. "Deducing this" - This probably allows
class a { int x; public: int& get() { return x; } int const& get() const { return x; } };
to be written like
class A { int x = 0; public: auto& get(this auto& self) { return self.x; } };
Essentially the member function template allows the compiler to write both overloads for you. In really generic code this could help collapse four overloaded function templates into one.
This feature is maybe the first step away from the idiosyncratic syntax involving member functions, and maybe the first step towards a uniform function call syntax. Syntactic uniformity would improve C++'s (sufficient) generic programming support, but it also would help improve the unavoidably awful meta-programming features that are being added to the language, so this feature is a solid step in the right direction.
3. "out_ptr and inout_ptr" - this is a tool for getting smart pointers to work smoothly with C-style interfaces that take a T** and write the pointed-to T*. This will be useful, but why on Earth did they choose inout_ptr over in_out_ptr!?
4. "move_only_function" - What is it for? I cannot understand the purpose of a new feature from a diff against the old specification, but the linked paper contains neither a design discussion nor even a reference to that discussion.
5. "<expected>" - I didn't see any need for more error-handling schemes to be added to the standard library.
Overall C++23 will be a minor improvement.
Last edited on
Yeah, C++20 was the equivalent of C++11 in the scope of changes made to the language IMO, C++23 is looking to be like C++14. A bit of fixes, a bit of refinement.
| mbozzi wrote: |
|---|
| 1. "if consteval" - I guess this is intended to replace std::is_constant_evaluated, because the latter is error prone [...] What went wrong with the process that caused us to get is_constant_evaluated first? |
I don't know but I can imagine adding a standard function was less controversial than changing the language syntax.
Note that the consteval proposal (P1073) and the std::is_constant_evaluated() proposal (P0595) were progressing independently at the same time.
The first revision of P0595 is from February 2017 and was called "The constexpr Operator". Basically
constexpr() instead of std::is_constant_evaluated().The first revision of P1073 did not appear until May 2018 and was called "constexpr! functions". The consteval keyword was not proposed until October 2018.
I guess it takes time to get everything into the right shape and people don't want to wait so sometimes mistakes are made. Both P0595 and P1073 was approved in November 2018. The first revision of the if consteval proposal (P1938) is from October 2019 which is very late for something that aimed to be in the C++20 standard.
But being error prone is not the only motivation behind adding if consteval. It seemed like they were initially satisfied enough by the thought that compilers would be able to warn at least in the trivial case
if constexpr (std::is_constant_evaluated()). The other, perhaps more compelling, motivation is so that you can call consteval function based on whether you're in a constexpr context or not.Example taken from the P1938 proposal:
|
|
If f is marked consteval then this code would not compile. if consteval solves this problem.
| mbozzi wrote: |
|---|
| 4. "move_only_function" - What is it for? I cannot understand the purpose of a new feature from a diff against the old specification, but the linked paper contains neither a design discussion nor even a reference to that discussion. |
The name has changed multiple times: unique_function -> any_invocable -> move_only_function
My understanding is that it's basically like std::function but you cannot copy it. Only move it.
Old version has motivation:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0288r1.pdf
Last edited on
The C Standard committee is setting a slower pace for the new revision standards, around 6 years between revisions instead of the 3 for C++. Though the standards before C11 happened every 4 years.
Just an observation that probably means nothing.
Just an observation that probably means nothing.
I'm not sure how much the number of years between standard revisions matters in the long run. It seems like they are not delaying the standard until "everything" is ready like they did with C++11, instead they ship what they have, and features that miss the ship will just have to take the next ship.
Last edited on
Yes, but my point was to have a longer time between major releases so that us poor mortal programmers have longer to get used to the new features before we've landed with the next set. Currently we barely have a chance to catch our breath from one set of major changes before the next set land...
| Yes, but my point was to have a longer time between major releases so that us poor mortal programmers have longer to get used to the new features before we've landed with the next set. Currently we barely have a chance to catch our breath from one set of major changes before the next set land... |
That's true, but a longer wait means even more features to try and get used to when the release finally lands. I think I'd actually prefer to go in the opposite direction - shorter release cycles, but with a smaller amount of new things to absorb.
My take is that with new features, there are lots of people who want them, so even if only one feature is used by someone, that trumps anyone wanting to learn all of them. It is well known that learning C++ is a never ending thing, I guess the rate of learning is a problem.
Oh no. I have not even picked up my C++20 book yet. Should I hold off, would a C++23 book cover ALL the grounds for 20 or would I need to cover both books?
There will be books that just cover the updates to C++23 from C++20. There will also be books that cover intro to C++ programming based upon C++23. There will also be books for existing programmers that don't know C++ that want to learn C++23. When any of these new C++ books will be published I'll consult my crystal ball ....
Often, the fastest book publication is for e-books. For a good selection of e-books on C++ see leanpub https://leanpub.com/bookstore?type=all&search=c%2B%2B
I suspect that once the new C++23 standard is finalised (it's now feature complete but the standard wording needs to be finalised) then we'll see e-books on C++23 by Rainer Grimm and Nicolai Josuttis published fairly soon after. I'd gamble that they're already being written. These, though, just cover the updates from previous standard.
@protoseepp - what version of C++/compiler are you using now?
Often, the fastest book publication is for e-books. For a good selection of e-books on C++ see leanpub https://leanpub.com/bookstore?type=all&search=c%2B%2B
I suspect that once the new C++23 standard is finalised (it's now feature complete but the standard wording needs to be finalised) then we'll see e-books on C++23 by Rainer Grimm and Nicolai Josuttis published fairly soon after. I'd gamble that they're already being written. These, though, just cover the updates from previous standard.
@protoseepp - what version of C++/compiler are you using now?
@protoseepp, there is currently only one compiler setup that is fully 100% C++20 compliant. Visual Studio on Windows. All other compilers lack key features, arguably the biggest being modules. <format> is another MIA feature.
No compiler is 100% compliant with C++23 yet, officially documented.
I can recommend several books/eBooks I've found useful, including a bundle of 3 eBooks that cover in depth key ideas of programming.
A print book for learning C++, C++20 at that though it still covers "older C++", is "Beginning C++20: From Novice to Professional".
https://www.amazon.com/gp/product/1484258835/
The book covers quite a lot of material quickly, building on previous examples.
It is not your typical "let's teach C++ as if it were an enhanced C" approach far too many imperfect/bad C++ books and classroom courses follow.
If you get the book and are able to use Visual Studio I can give some suggestions to help make using modules less of a PITA as they were for me at the start.
That is an ongoing issue with the evolution of C++, new things to learn and deal with. Even the guys who write the books have to learn the new features as they are introduced before they can show others.
Luckily C++23 doesn't appear to be as sweeping a change as C++11 or C++20.
Others here are C++ experts, AFAIK actually C++ working professionals. Me? I'm a self-taught programming hobbyist. Being solo learning since before C++98 was the standard.
I'm a crotchety old fart with some very strong opinions about things C++. :Þ
No compiler is 100% compliant with C++23 yet, officially documented.
I can recommend several books/eBooks I've found useful, including a bundle of 3 eBooks that cover in depth key ideas of programming.
A print book for learning C++, C++20 at that though it still covers "older C++", is "Beginning C++20: From Novice to Professional".
https://www.amazon.com/gp/product/1484258835/
The book covers quite a lot of material quickly, building on previous examples.
It is not your typical "let's teach C++ as if it were an enhanced C" approach far too many imperfect/bad C++ books and classroom courses follow.
If you get the book and are able to use Visual Studio I can give some suggestions to help make using modules less of a PITA as they were for me at the start.
| Oh no. I have not even picked up my C++20 book yet. |
That is an ongoing issue with the evolution of C++, new things to learn and deal with. Even the guys who write the books have to learn the new features as they are introduced before they can show others.
Luckily C++23 doesn't appear to be as sweeping a change as C++11 or C++20.
Others here are C++ experts, AFAIK actually C++ working professionals. Me? I'm a self-taught programming hobbyist. Being solo learning since before C++98 was the standard.
I'm a crotchety old fart with some very strong opinions about things C++. :Þ
I see seeplus mentioned leanpub, a source of IMO excellent eBooks.
One advantage of buying books from leanpub is buying a book still being written. Much cheaper and updates are free. I've purchased a number of books from leanpub and nearly every one has had at least one update since the purchase. Several books have had more than one even though the book was "100% finished."
Something you'd never see with a printed book.
One advantage of buying books from leanpub is buying a book still being written. Much cheaper and updates are free. I've purchased a number of books from leanpub and nearly every one has had at least one update since the purchase. Several books have had more than one even though the book was "100% finished."
Something you'd never see with a printed book.