Yup! I think that's partially the reason why this guy's been awarded MVP. Renown professionals usually have either great communication skills all across the board, or they are darn good at one specific field of work they've been specializing in. Those who tend to be the prior, usually end up in tasks/roles requiring some form of leadership skills, or dealing with clients one way or the other.
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.
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.
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
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.
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 `result.resize_and_overwrite(newSize);`. 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
Why even bother with that complexity? I prefer the KISS approach. I've 'survived' as a developer for 30 years without using a lambda. A lot of the extras are just change for change's sake. We'll reach a point where C++ will kill itself due to its increasingly insane complexity.
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); 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.
The values in the result are indeed ranges, not tuples. This is in contrast with for example ranges::adjacent_view where the value type is a tuple, but for ranges::slide_view, the value type is a (sub)range.
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).
isn't all the housekeeping (like running constructors of globals) before main also considered "runtime" after all, not every C++ program starts with main
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.
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"
"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)
@@ADHD101ThriveThe level of complexity we're seeing in the language now is unnecessary. Any language that is Turing Complete is sufficient by definition.
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.
wish C89 had UZ but back then "int" was assumed to be the native int size, so I guess the problem started when LP64 became the norm. not a fan of trimming space after line-continuation -- the language should punish sloppiness.
C++ is like a natural language say English and you can't simply wave a magic wand and change billions of lines of code and retrain millions of programmers. C++ is massive for a reason.
Herb Sutter did a great talk some years ago (I forget the title unfortunately) on how actively increasing the size of the language is actually simplifying it. The reasoning is solid: making the language smaller is simply impossible without breaking backwards compatibility, which is a core tenet of the language, so that's out of the question. However, by adding new features that reduce the cognitive load on the programmer, you effectively simplify the language, requiring the user to remember less. The size of the language doesn't matter - if there's stuff you never use in the standard then it doesn't affect you. I'll probably never use the proposed networking features, so I'll probably never learn them, and I'll never pay any overhead for them. They'll have literally zero negative impact on what I do, but have a huge positive impact for many others. I cannot see any reason for thinking that's in any way a bad thing.
C++ is not a runtime. The language and Stdlib size does not affect you. Whatever you do not use will not be linked in to your program and therefore does not cause bloat. You are not required to learn the new parts.
Okay, multi indexed operator if freaking epic fail. It freaking introduces so many ambiguities, idk if i want it at all. It was enough for me when they got rid of trigraphs
I can't think of a situation where the multi-dimensional index operator would introduce ambiguity. Could you suggest an example so I can better understand your perspective?
Assembly "language" might be simple but you can't use it for building performance scalable abstractions. If anything C++ has gotten simpler with subsequent standards. Yes, you read that right simpler. Large part of complexity in C++ is/was due to the fact that it wasn't flexible enough for people to solve complex problems in a straightforward manner. But it was possible, resulting in ugly and complicated code.
Best "what's new" I saw for a new C++ version quick and easy to grasp
Yup! I think that's partially the reason why this guy's been awarded MVP. Renown professionals usually have either great communication skills all across the board, or they are darn good at one specific field of work they've been specializing in.
Those who tend to be the prior, usually end up in tasks/roles requiring some form of leadership skills, or dealing with clients one way or the other.
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.
Excellent presentation, well structured with simple example.
The best way presenting C++ features 👍
Wow after 40 years C++ adds std::print() 👍
Faster than printf :O
Really good and concise talk!
the std::unreachable thing is very good!
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.
Yes, correct, the type of variable 'c' is indeed char. The for-loop loops over all characters of the joined strings.
Great presentation!
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.
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
You are correct, the extra characters will indeed have indeterminate values.
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.
flat_map, amazing!
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 `result.resize_and_overwrite(newSize);`. 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
Why even bother with that complexity? I prefer the KISS approach. I've 'survived' as a developer for 30 years without using a lambda. A lot of the extras are just change for change's sake. We'll reach a point where C++ will kill itself due to its increasingly insane complexity.
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); 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.
47:03 [slides 80-82] I believe the elements in the result of slide/chunk/chunk_by are each std::subrange, and not tuples
The values in the result are indeed ranges, not tuples. This is in contrast with for example ranges::adjacent_view where the value type is a tuple, but for ranges::slide_view, the value type is a (sub)range.
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).
That makes me sad
Why not make a ‘comptime’ keyword?
What's your source for this because I have read everywhere that consteval means guaranteed to be evaluated at compile time?
isn't all the housekeeping (like running constructors of globals) before main also considered "runtime"
after all, not every C++ program starts with main
C++ needs to be called C++++++++ nowadays
It's simply C##
The language is losing its original elegance.
[slide 80] sad, that std::expected didn't get the same monadic functions as std:: optional
std::expected actually does provide the same monadic functions as std::optional and one more (transform_error).
Println poggers 🎉
I don't get why we need std::from_range in range ctors
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
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.
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"
Module 'std' not found
cuz its not done yet ... if compiler doesn't support c++23 and modules are not done yet module std cannot be imported
The Microsoft compiler already supports this. However, the feature needs to be enabled in the compiler options.
"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)
I agree , c++ is not a tool now, is a problem , maybe is time to rust
thats absurd you need complexity for complex software design specifications
@gazapo Rust is horrid from the get-go. I'll just keep using a minimal subset of C++ and ignore the 'junk'
@@ADHD101ThriveThe level of complexity we're seeing in the language now is unnecessary. Any language that is Turing Complete is sufficient by definition.
3:32 all this fuzz just to not write class.doublevar = 2
And people are convinced this is somehow better
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.
3:20 ah yes, python like OOP style
29:36
thank f'ing god.
Omg i dont have to use find() anymore! At last
it just shows how little I know about c++ lolol
Vs code not supporting c++23 now why it's using c++20 something
those ads at the beginning convinced me never to come to a cppcon event
wish C89 had UZ but back then "int" was assumed to be the native int size, so I guess the problem started when LP64 became the norm. not a fan of trimming space after line-continuation -- the language should punish sloppiness.
I think that someone wants to deliberately slowly but surely people leave C++. C++ is getting more and more complicated
Import std; also not working
it's not done yet and compilers didn't implement those modules for this time
The language is too big. The standards committee should focus on a smaller, better thought out, set of features.
There is no comeback anymore, the end will be death.
C++ is like a natural language say English and you can't simply wave a magic wand and change billions of lines of code and retrain millions of programmers. C++ is massive for a reason.
Herb Sutter did a great talk some years ago (I forget the title unfortunately) on how actively increasing the size of the language is actually simplifying it.
The reasoning is solid: making the language smaller is simply impossible without breaking backwards compatibility, which is a core tenet of the language, so that's out of the question. However, by adding new features that reduce the cognitive load on the programmer, you effectively simplify the language, requiring the user to remember less.
The size of the language doesn't matter - if there's stuff you never use in the standard then it doesn't affect you. I'll probably never use the proposed networking features, so I'll probably never learn them, and I'll never pay any overhead for them. They'll have literally zero negative impact on what I do, but have a huge positive impact for many others. I cannot see any reason for thinking that's in any way a bad thing.
C++ is not a runtime. The language and Stdlib size does not affect you. Whatever you do not use will not be linked in to your program and therefore does not cause bloat.
You are not required to learn the new parts.
Stuff in the language that I don't use still affects me because other people use it and I have to read their code.
Okay, multi indexed operator if freaking epic fail. It freaking introduces so many ambiguities, idk if i want it at all. It was enough for me when they got rid of trigraphs
You liked trigraphs??
Can you give examples?
I can't think of a situation where the multi-dimensional index operator would introduce ambiguity. Could you suggest an example so I can better understand your perspective?
so now cpp has been pythonized every day
ya if we wanted python I'd go to python
Assembly easy than this fu...sh... Don't keep pinching anymore.
Assembly "language" might be simple but you can't use it for building performance scalable abstractions. If anything C++ has gotten simpler with subsequent standards. Yes, you read that right simpler. Large part of complexity in C++ is/was due to the fact that it wasn't flexible enough for people to solve complex problems in a straightforward manner. But it was possible, resulting in ugly and complicated code.
The code is ugly complicated
More garbage getting dumped every year