C++23: An Overview of Almost All New and Updated Features - Marc Gregoire - CppCon 2023

---

C++23: An Overview of Almost All New and Updated Features - Marc Gregoire - CppCon 2023

As I have done for previous C++ Standard versions, I will explore almost all new and updated C++ features that come with the C++23 standard. C++23 is not as big of an update as C++20 was, but it does contain numerous new and updated features to both the core language and the Standard Library. The goal of this session is not to discuss all new and changed features in detail, as that is not possible in a one-hour session. Instead, at the end of the session, you should have a high-level overview of everything that's new or changed in C++23, and it might even change how you are using existing features.

The session will touch on the following core language and Standard Library topics.

C++23 core language changes include explicit object parameters (deducing this), if consteval, multidimensional subscript operators, built-in decay copy support, ability to mark unreachable code, support for specifying platform-independent assumptions, named universal character escapes, and more.

Throughout the session, the slides will contain references to other CppCon sessions with more details on specific topics.
---

Marc Gregoire

His main expertise is C/C++, specifically Microsoft VC++ and the MFC framework. He has experience in developing C++ programs running 24/7 on Windows and Linux platforms: for example, KNX/EIB home automation software. In addition to C/C++, Marc also likes C#.
---

---

#cppcon #cppprogramming #cpp

[seebee]

Best "what's new" I saw for a new C++ version quick and easy to grasp

[solmu]

Wow after 40 years C++ adds std::print() 👍

[axelbagi]

I really like this "series", instead of looking at a list and manually look at what everything does, I get a summed up good paced, explained lecture, where I can memorize the (for me) more relevant things.

[Radioguy]

Excellent presentation, well structured with simple example.

[pitschquitsch]

the std::unreachable thing is very good!

[Roibarkan]

47:24 [slide 83] note that I believe that the type of the variable ’c’ in this slide is char, so std::print will be called 13 times.

[cyrilemeka]

I am really digging the unicode explicit name entry and the format specifications for standard library types, especially std::map, it's giving python vibes.

[fdwr]

32:13 I look forward to fast std::string resizing, since I'm generally just going to overwrite that string with new data anyway or use only a part of it. The best lambda to pass is the nop lambda `result.resize_and_overwrite(newSize, [](char* buffer, size_t count) {});`, and then we essentially get what we all actually asked for in the first place for this feature, which is basically this If initializing the string data is like painting a picture, then initializing the string data while *inside* the lambda callback is like trying to paint a picture while standing on your head - not good. :b

[ABaumstumpf]

9:07 - consteval does not guarantee that it is executed at compiletime - The language still has no notion of compiletime. What is guaranteed is that it is not executed at runtime. And runtime starts with the codepath entering main. Which means it would be entirely fine for a compiler to evaluate the code dynamically when you start the program, but before entering main.
(which is kinda funny - seeing the committee trying multiple times but none of the changes guarantee what the developers actually need).

[Roibarkan]

30:27 Actually I think extra “characters” will have indeterminate value, not default initialized. If the value-type of the basic_string is char (or wchar_t) then default initialization is indeterminate, so typically the slide is correct

[Roibarkan]

47:03 [slides 80-82] I believe the elements in the result of slide/chunk/chunk_by are each std::subrange, and not tuples

[zyxyuv]

Instead of writing 5 different lambda's, I recently wrote a single lambda with a few template parameters and a few if-constexpr's. I was sad to see that I could not pass it to any std algorithms or ranges. I simply wanted to do stuff like std::sort(b, e, sorterFn<X, Y>); The template lambda ended up being unusable and I had to use a regular template function instead. I realize I could use a lambda wrapper to call the other lambdas using .template operator(), but that messed up the code simplicity and readability I was trying to achieve.

[chel]

When will they add the override for regex_replace with function type fmt like in other programming languages and in boost library? Several versions of C++ have already been released from 2011, but the problem is not fixed.

[GrigoryRechistov]

"Programmers are always surrounded by complexity; we cannot avoid it.... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution. " — C. A. R. Hoare (1980 Turing Award Lecture)

[fareloz]

Deducing this forces me to use templates and place the code in a header. I hate that modern cpp forces me more and more cover put in a header

[Max]

After seeing "multidimensional indices", "import", and "generators", I was fully expecting to see "we did away with those pesky curly braces... just use tab-indents"

[fareloz]

I don't get why we need std::from_range in range ctors

[tiegerzahn]

[slide 80] sad, that std::expected didn't get the same monadic functions as std:: optional

[anon_y_mousse]

It looks like no compiler supports println() and a few other things, unless CE just hasn't been updated. I guess I'll have to build an up to date copy of `gcc` and `clang` to test which is the case. I still can't fathom how anyone could think that the syntax around pretty much all of these string operations were a good idea. Do people just not like operator overloading? Surely that can't be it because multiple operators have been overloaded for all the functional stuff. Consider if you will: string string_to_split { "a string with spaces" }; for ( auto word : string_to_split / ' ' ) println( "{}", word ); // and thus operator/ would split the string around spaces. Would that be such a bad thing.

[AxWarhawk]

35:50 I have to say, I really dislike slide 62, especially for demonstration purposes.
Instead of the .and_then call, this should really be just a .transform as the result can only be an int. The to_string transformation still looks obnoxious, but it has to be written this way since C++ can't do overload resolution here. Ideally that'd be just .transform(std::to_string). The usage of .or_else here almost defeats the purpose of using an optional in the first place. That line shouldn't be there, instead the following line (the one that consumes result) would be something like result.value_or("No Integer").

Again, I get that this is meant to show off .and_then, .transform, .or_else, but this really does a bad job in my opinion.