I love the positivity in this talk. We’ve spent the past few years worrying about (security and safely) and it’s eaten up a lot of conference time and head-space. This talk whilst being deeply pragmatic and entertaining looks on to new and exciting frontiers in the decade(s) to come.
Thanks, I'm glad you like it! It's work by a lot of great people. Just a caution though, I did try to emphasize that the _first parts_ of this look on track for C++26 and said "fingers crossed" a few times 😃
I'm pretty keen for some form of JIT to come through at some stage. Compiling a GPU kernel for all the various data types results in massive binaries. Being able to have some template function, and then JIT for the datatype that is actually used in the user program would save a lot of binary bloat.
@@bryce.ferenczi Interesting. In Cppcon 2020,Ben Deane and Kris Jusiak presented some experimental JIT functionality that was once attempted to be standardized (by Hal Finkel, I believe): ua-cam.com/video/I3ov8HcdVKw/v-deo.html
@@herbsutter4340 looking forward! Actually is there a cpp2 book in the making? It would also be helpful. Although the updated documentation is also great.
1:28:09 I wonder why Herb chose to constrain this to contiguous containers and not to all sized-ranges (e.g. std::dequeue or a zip_view of vectors)? In 1:29:29 he mentions all that’s needed is the std::size customization, which implies it will work for non contiguous sized ranges.
Ah, good point -- in fact it does work just fine for contiguous views and ranges today. I shouldn't say "containers" only here. Will fix next time I give the talk, thanks.
@@herbsutter4340 You might say "sized ranges with subscripting", which the Standard Library doesn't really have a concept for. Despite that the library implements it for all random access ranges it provides - it's built right into `view_interface - none of the range concepts require `operator[]`.
I appreciate the forward progress but am I the only one who sees that the reflection code looks so unintuitive? The whole language has become so complicated. Efforts like Cppfront help but we need a new C++ inspired programming languages to rise from C++'s ashes. And, no, it isn't Rust.
@@PaulTopping1 hopefully the reflection features will be composable enough that it would be possible to create reflection-using libraries which hide/encapsulate the gorry details and give us power. Again, I'm thinking/imagining things like the syn::parse library in rust
@@Roibarkan +1 to this. It is a bit complicated at first but it'll get easier the more you look at it. Reflection is already a complicated topic, just like how new grads struggle with the concept of metaprogramming or even simpler, recursion. So this complicated syntax is really a tool for advance users. The usage of it like with the class(thing) interface should make it easier and more ergonomic in code.
C++ needs its own build system. Build file written in a language similar to c/c++. Common tasks should be simple like 1. Adding library Like if I want glfw, it should be possible to add glfw folder with new build file, add a line in main build file like libs += glfw path. How to build, what libs to add, what headers to made available will be communicated by build file inside glfw folder.
Should remove implicit conversations. One argument constructor should be by default explicit. If some one needs it to be implicit, he has to mention, not the other way around. *AComplexClassObj = 5* it shouldn't be valid. That looks like JavaScript to me.
@@axthd I personally agree with you, but want to share a talk from SwedenC++ about the other side of the coin, on the potential benefits of embracing implicit conversions: ua-cam.com/video/bb9hPtuVaTU/v-deo.html. Potentially cool…
I love the positivity in this talk. We’ve spent the past few years worrying about (security and safely) and it’s eaten up a lot of conference time and head-space. This talk whilst being deeply pragmatic and entertaining looks on to new and exciting frontiers in the decade(s) to come.
Thanks. There really IS a lot to be positive about!
This is insane, so many possibilities with reflection/generation! Can't wait for the complete standardization and compiler implementation!
Great presentation. If all this will be in C++26, then c++ will start to believe again in the future of C++.
Thanks, I'm glad you like it! It's work by a lot of great people. Just a caution though, I did try to emphasize that the _first parts_ of this look on track for C++26 and said "fingers crossed" a few times 😃
Great talk! I'm really excited to try out C++26 and will definitely play with the new reflection and code generation constructs
I'm pretty keen for some form of JIT to come through at some stage. Compiling a GPU kernel for all the various data types results in massive binaries. Being able to have some template function, and then JIT for the datatype that is actually used in the user program would save a lot of binary bloat.
@@bryce.ferenczi Interesting. In Cppcon 2020,Ben Deane and Kris Jusiak presented some experimental JIT functionality that was once attempted to be standardized (by Hal Finkel, I believe): ua-cam.com/video/I3ov8HcdVKw/v-deo.html
Now it's time to open source cpp2 0.8 and onwards with a permissive licence.
Thanks!
Re open source: Cppfront is already open source! Just not for commercial use.
Re also allowing commercial use: Coming soon😉
@@herbsutter4340 looking forward! Actually is there a cpp2 book in the making? It would also be helpful. Although the updated documentation is also great.
Why cpp2 is important?
Amazing talk, lot of programming pearls! Instrumented types is mindblowing...
Its all fun and games until theres a compile error
1:28:09 I wonder why Herb chose to constrain this to contiguous containers and not to all sized-ranges (e.g. std::dequeue or a zip_view of vectors)?
In 1:29:29 he mentions all that’s needed is the std::size customization, which implies it will work for non contiguous sized ranges.
Ah, good point -- in fact it does work just fine for contiguous views and ranges today. I shouldn't say "containers" only here. Will fix next time I give the talk, thanks.
@@herbsutter4340 You might say "sized ranges with subscripting", which the Standard Library doesn't really have a concept for. Despite that the library implements it for all random access ranges it provides - it's built right into `view_interface - none of the range concepts require `operator[]`.
Uffff the property thing, uffff love it :D
40:53 Herb’s talk from Cppcon 2017: ua-cam.com/video/4AfRAVcThyA/v-deo.html
1:26:22 Herb’s talk from 2022: ua-cam.com/video/ELeZAKCN4tY/v-deo.html
51:48 Hana on CTRE from CppCon 2019: ua-cam.com/video/8dKWdJzPwHw/v-deo.html
"I care less about the syntax being beautiful, I want the functionality now" lol
I love beauty, but I'm also a pragmatist! 😁
22:20 Louis Dionne on STL safety in LLVM libc++: ua-cam.com/video/pQfjn7E4Qfc/v-deo.html
1:08:17 “it could also be C++” - this sounds like syn::parse in rust procedural macros!!!
I appreciate the forward progress but am I the only one who sees that the reflection code looks so unintuitive? The whole language has become so complicated. Efforts like Cppfront help but we need a new C++ inspired programming languages to rise from C++'s ashes. And, no, it isn't Rust.
@@PaulTopping1 hopefully the reflection features will be composable enough that it would be possible to create reflection-using libraries which hide/encapsulate the gorry details and give us power. Again, I'm thinking/imagining things like the syn::parse library in rust
@@Roibarkan +1 to this. It is a bit complicated at first but it'll get easier the more you look at it. Reflection is already a complicated topic, just like how new grads struggle with the concept of metaprogramming or even simpler, recursion. So this complicated syntax is really a tool for advance users. The usage of it like with the class(thing) interface should make it easier and more ergonomic in code.
C++ needs its own build system.
Build file written in a language similar to c/c++.
Common tasks should be simple like
1. Adding library
Like if I want glfw, it should be possible to add glfw folder with new build file, add a line in main build file like libs += glfw path.
How to build, what libs to add, what headers to made available will be communicated by build file inside glfw folder.
This already exists, today. This should not be part of the language.
There are various ways that do this in C++, conan, vcpkg, bazel, CPM.cmake, build2 etc etc.
Should remove implicit conversations.
One argument constructor should be by default explicit.
If some one needs it to be implicit, he has to mention, not the other way around.
*AComplexClassObj = 5* it shouldn't be valid.
That looks like JavaScript to me.
@@axthd I personally agree with you, but want to share a talk from SwedenC++ about the other side of the coin, on the potential benefits of embracing implicit conversions: ua-cam.com/video/bb9hPtuVaTU/v-deo.html. Potentially cool…