31:24 std::basic_string::subview is actually so huge. I've wanted this for such a long time. You could achieve this before with the std::basic_string_view constructor and std::basic_string iterators, sure, but it was such an eyesore.
At 47:11 "P2885 optional" is mentioned (slaid 54, 72/118 in PDF pages). However, P2885 is "Requirements for a Contracts syntax" and doesn't seem to have anything to do with references in optional. And I failed to find any other source on that (assuming that maybe there is just a typo in the P number).
Is there a proposal for small size vector which can allocate memory when the initial fixed size capacity is reached (unlike inplace vector)? This is the default behavior of eastl::fixed_vector and is extremely useful when performance matters and when knowing the average size of vector but want to keep std::vector behavior. (same question for small size unordered_things).
For me, the reason I hesitate to use std::ranges algorithms is the harder to decipher compiler error messages relative to the corresponding iterator versions of the algos. Many times I found myself switching to the iterator version in order to debug what my container elements were missing from the list of requirements of the algorithm.
I rarely use std::ranges, because I measured once that they're significantly slower to compile, and when the difference is just begin/end vs range argument, I don't mind the slight extra complexity. Same problem, but even more extreme with std::print and std::format
Same here. Build times are literally killing productivity when working with large codebases, yet newly introduced features keep shifting build times even further to the right when used. We've got projects of comparable complexity written in C++ for performance and in C# for development cost and agility. Build speed difference is about 20x not in favor of C++. This costs a great amount of wasted developer time and mental energy.
print and format are just suffering from quality of implementation, it should in theory improve over time and reach printf level in 2-3 years with some compiler magic.
A little sad that the three most important features I see for the general user, those being pattern matching, contracts and networking, won't be on the 2026 train.
09:44 - static_assert using std::format -- does this mean that std::format will be constexpr in cpp26? I recently realised when using it in cpp20 that it doesn't appear to be usable at compile time according to cppref
Thanks for the great talk! Is there something like Java’s Stream API planned? For example, to modify all elements of a vector in place, or to create a new container after a sequence of operations?
Do you perhaps mean the ranges library that’s in the language since C++20 and keeps evolving? std::ranges::transform and std::views::transform can be used for eager/lazy element wise mutation, and std::ranges::to in C++23 can be used to create a new container. If anyone wants a good overview: ruclips.net/video/uYFRnsMD9ks/видео.html
Still waiting for basic features: Standard networking Standard package manager Standard build system Standard formatter Standard linter Standard testing
Lol most of these won't appear since they already told everyone that the committee doesn't care about those responsibilities. I mean C++ still doesn't have an official compiler since 1998 😂😂😂
On the side of the talk (not the content): When answering audience questions it would be nice to have the question repeated (like done once at the end) or as some annotation or whatnot on the video. And for the camera: The view should not be locked that strongly on the person. He does not need to be perfectly in centre all the time, but the constant small movements are distracting. It is telling that fmt, rangesv3 or many boost features get tested and used for years but then the standard implementation differes in key aspects like making std::filter_view such a trap that even projects that have never used any ranges avoid std and go for rangesv3. Why use '_' for unnamable variables instead of something a bit more descriptive? underscore is a valid identifier right now, but this not only is a breaking change it also is a rather counterintuitive one. We are not in the 70s, we are not limited to 72 character displays, and we have no need to repeat the mistakes of other languages. Are there any good reason why it was not done with a "std::unnamed" or "[[unnamed]]" or something along those lines? it is not all that bad when compared to what C++20 and beyond have already done wrong, but it is strange nonetheless.
'_' for unnamed variables basically acts like variable name shadowing on steroids. As far as I know, the presenter here actually got this detail wrong. You can still access a variable named '_' as long as it is unambiguous what you intend to access, so legacy code won't break from this change. All that has changed is it's now possible to create multiple variables named '_' in ways what were never possible before, and at that point they may become unusable. "std::unnamed" would not have worked for the std::lock_guard example shown in this video, and "[[unnamed]]" is, in my opinion, needlessly verbose. I don't believe other languages using '_' as a placeholder name is a mistake either, so in my opinion it's good that C++ is handling placeholder variable names in a familiar way.
@@Minty_Meeo "You can still access a variable named '_' as long as it is unambiguous what you intend to access" Just looked at the proposal in its latest form and it is ... BAD: So long as you only have a single '_' it acts like before. But here comes to fun part: "it can redefine an existing declaration, [basic.scope.declarative] in the same scope. After redeclaration, if the variable is used, the program is ill-formed." So if you use this name-independent declaration (what the standard calls it) and then try to use the variable then it suddenly stops working. "and "[[unnamed]]" is, in my opinion, needlessly verbose." I think better verbose than cryptic. And it would really only be a short name that you shouldn't need that often and is rather simple to comprehend. Why do you think "_" is a placeholder is good? I see it all over some codebases i am working on and yes - you get used to it but it is always taking you out of the flow as it is just that absurd. When i see it in C# switch-expressions for example it is just a very bad placeholder: in the normal switch-statement you have "default" telling you exactly what it is. But in the expression you don't have default but '_' instead. Inconsistent and non descriptive.
@@ABaumstumpf I don't see what the issue is with the proposal in its latest form. If you actually want to use a variable, it probably has a better name than "_". If it doesn't and you try to use it anyway when there's *multiple* variables named "_" in the *same scope,* then yes you will get a compilation error (ill-formed). However, the chances of this happening seem incredibly slim, and if it does happen then the solution is obvious: give your variables better names. I think you would agree to this point, considering your stance on cryptic names? "_" for placeholder names is just a common practice that I'm used to, nothing more. I agree that "_" for default switch cases is poor design; I never said otherwise.
@Minty_Meeo lol no, nobody uses these in the industry These are for college kids, or unemployed people In a large project you care about readability and reliability I was actually stupid enough to waste a month and relink a large codebase when 11 came out After we recompile it, the shortcomings of the "innovations" became obvious We reverted back to 98 and never looked back
felt pretty exciting to me, having old broken stuff fixed is more important than piling up new and new features. C++ is already huge, i think we need to decelerate from adding tons of new stuff and focus on other stuff like a standard package manager + build system, and getting modules to actually work. Compilers are lacking behind, standard going too fast. also this talk was about small stuff only, there are other talks for bigger features like REFLECTION
That was a good talk. Quite a number of things to look forward to in C++26.
Congrats for the great presentation and the work work of the committee!
Was wondering who the annoying guy coming out with a smart-aleck correction at the end was, then I realized it was me 😬
Great presentation! A very nice done overview of the C++26 features.😊
31:24 std::basic_string::subview is actually so huge. I've wanted this for such a long time. You could achieve this before with the std::basic_string_view constructor and std::basic_string iterators, sure, but it was such an eyesore.
At 47:11 "P2885 optional" is mentioned (slaid 54, 72/118 in PDF pages). However, P2885 is "Requirements for a Contracts syntax" and doesn't seem to have anything to do with references in optional. And I failed to find any other source on that (assuming that maybe there is just a typo in the P number).
P2988 probably
Unfortunately the font size of the code examples is too small. This way I can not read it on my phone while moving by train.
C++26 is going to be amazing!
Is it? Still haven't looked at C++14 yet.
Is there a proposal for small size vector which can allocate memory when the initial fixed size capacity is reached (unlike inplace vector)?
This is the default behavior of eastl::fixed_vector and is extremely useful when performance matters and when knowing the average size of vector but want to keep std::vector behavior.
(same question for small size unordered_things).
20:13 is the most C++ thing ever hahaha
For me, the reason I hesitate to use std::ranges algorithms is the harder to decipher compiler error messages relative to the corresponding iterator versions of the algos. Many times I found myself switching to the iterator version in order to debug what my container elements were missing from the list of requirements of the algorithm.
I rarely use std::ranges, because I measured once that they're significantly slower to compile, and when the difference is just begin/end vs range argument, I don't mind the slight extra complexity.
Same problem, but even more extreme with std::print and std::format
Same here. Build times are literally killing productivity when working with large codebases, yet newly introduced features keep shifting build times even further to the right when used. We've got projects of comparable complexity written in C++ for performance and in C# for development cost and agility. Build speed difference is about 20x not in favor of C++. This costs a great amount of wasted developer time and mental energy.
print and format are just suffering from quality of implementation, it should in theory improve over time and reach printf level in 2-3 years with some compiler magic.
if speaker's gonna be believed, format is faster at runtime - have you measured it being slower to compile, too?
I use STL algorithms just like I used to but being able to write things like for (auto& i : std::views::reverse(vector)) is amazing
@@erdizzI've found that some of the constexpr stuff slows build time massively.
Code font too small to read.
A little sad that the three most important features I see for the general user, those being pattern matching, contracts and networking, won't be on the 2026 train.
This was a very good overview. Thank you for doing the lord's work
09:44 - static_assert using std::format -- does this mean that std::format will be constexpr in cpp26? I recently realised when using it in cpp20 that it doesn't appear to be usable at compile time according to cppref
@@Ash-qp2yw There is a paper: P3391 R0 constexpr std::format
5:00 REFLECTION! YAY!
You really will not want them the way the proposal has been mangled to death. It is one hell of an unreadable mess right now.
I'm 8 minutes in. Does this talk ever start, or is it a metatalk?
Thanks for the great talk!
Is there something like Java’s Stream API planned?
For example, to modify all elements of a vector in place, or to create a new container after a sequence of operations?
Do you perhaps mean the ranges library that’s in the language since C++20 and keeps evolving?
std::ranges::transform and std::views::transform can be used for eager/lazy element wise mutation, and std::ranges::to in C++23 can be used to create a new container. If anyone wants a good overview: ruclips.net/video/uYFRnsMD9ks/видео.html
rangesv3 can do a lot of the things, std::ranges not so much (and have way too bad performance and too many pitfalls)
Still waiting for basic features:
Standard networking
Standard package manager
Standard build system
Standard formatter
Standard linter
Standard testing
Instead of that you get more verbose syntax, isn't that great? 😂
Lol most of these won't appear since they already told everyone that the committee doesn't care about those responsibilities. I mean C++ still doesn't have an official compiler since 1998 😂😂😂
You may be waiting a very long time! 🤣
@ohwow2074 I don't see why a language should include a compiler. The language is a spec.
Why would the build system be a part of the language? I think it should be part of an IDE.
I wonder how much easier it'll be for malware to evade debuggers when using these debugging utilities.
C++26
On the side of the talk (not the content): When answering audience questions it would be nice to have the question repeated (like done once at the end) or as some annotation or whatnot on the video.
And for the camera: The view should not be locked that strongly on the person. He does not need to be perfectly in centre all the time, but the constant small movements are distracting.
It is telling that fmt, rangesv3 or many boost features get tested and used for years but then the standard implementation differes in key aspects like making std::filter_view such a trap that even projects that have never used any ranges avoid std and go for rangesv3.
Why use '_' for unnamable variables instead of something a bit more descriptive? underscore is a valid identifier right now, but this not only is a breaking change it also is a rather counterintuitive one. We are not in the 70s, we are not limited to 72 character displays, and we have no need to repeat the mistakes of other languages.
Are there any good reason why it was not done with a "std::unnamed" or "[[unnamed]]" or something along those lines? it is not all that bad when compared to what C++20 and beyond have already done wrong, but it is strange nonetheless.
'_' for unnamed variables basically acts like variable name shadowing on steroids. As far as I know, the presenter here actually got this detail wrong. You can still access a variable named '_' as long as it is unambiguous what you intend to access, so legacy code won't break from this change. All that has changed is it's now possible to create multiple variables named '_' in ways what were never possible before, and at that point they may become unusable. "std::unnamed" would not have worked for the std::lock_guard example shown in this video, and "[[unnamed]]" is, in my opinion, needlessly verbose. I don't believe other languages using '_' as a placeholder name is a mistake either, so in my opinion it's good that C++ is handling placeholder variable names in a familiar way.
@@Minty_Meeo "You can still access a variable named '_' as long as it is unambiguous what you intend to access"
Just looked at the proposal in its latest form and it is ... BAD:
So long as you only have a single '_' it acts like before. But here comes to fun part:
"it can redefine an existing declaration, [basic.scope.declarative] in the same scope. After redeclaration, if the variable is used, the program is ill-formed."
So if you use this name-independent declaration (what the standard calls it) and then try to use the variable then it suddenly stops working.
"and "[[unnamed]]" is, in my opinion, needlessly verbose."
I think better verbose than cryptic. And it would really only be a short name that you shouldn't need that often and is rather simple to comprehend.
Why do you think "_" is a placeholder is good? I see it all over some codebases i am working on and yes - you get used to it but it is always taking you out of the flow as it is just that absurd.
When i see it in C# switch-expressions for example it is just a very bad placeholder: in the normal switch-statement you have "default" telling you exactly what it is. But in the expression you don't have default but '_' instead. Inconsistent and non descriptive.
I don't think underscore is valid de jure - I think it's a "reserved identifier" like ones beginning with a single underscore, no?
@@Minty_Meeo Years ago, I recall them saying that they can't use _ but were planning __. What changed that using a single underscore is now OK?
@@ABaumstumpf I don't see what the issue is with the proposal in its latest form. If you actually want to use a variable, it probably has a better name than "_". If it doesn't and you try to use it anyway when there's *multiple* variables named "_" in the *same scope,* then yes you will get a compilation error (ill-formed). However, the chances of this happening seem incredibly slim, and if it does happen then the solution is obvious: give your variables better names. I think you would agree to this point, considering your stance on cryptic names?
"_" for placeholder names is just a common practice that I'm used to, nothing more. I agree that "_" for default switch cases is poor design; I never said otherwise.
"And we'll skip discussing reflection..."
Half the audience leaves 🤣
please lose the intros
The presenter should try to stop saying aahm, uuhm 3-5 times per sentence
Ok c++98 is fine, thanks I will not be buying your new book
If you're going to be a Luddite about it, at least use C++11.
@Minty_Meeo lol no, nobody uses these in the industry
These are for college kids, or unemployed people
In a large project you care about readability and reliability
I was actually stupid enough to waste a month and relink a large codebase when 11 came out
After we recompile it, the shortcomings of the "innovations" became obvious
We reverted back to 98 and never looked back
Just one word: uglier
This wasnt exciting at all, underwhelming?
felt pretty exciting to me, having old broken stuff fixed is more important than piling up new and new features. C++ is already huge, i think we need to decelerate from adding tons of new stuff and focus on other stuff like a standard package manager + build system, and getting modules to actually work. Compilers are lacking behind, standard going too fast.
also this talk was about small stuff only, there are other talks for bigger features like REFLECTION