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.
The convoluted syntax and that it might take 6 years before this is all available in C++29 is off-putting. You can do all this in Zig today, using a single keyword and easy-to-read code. I don't really see the simplification to C++.
1:29:35 the presence of a size function doesn't mean that the valid indices go from 0 to size - 1; even if the container is contiguous and random access. A container could start at 1 if it is designed to do so. For example, Boost.MultiArray can be declared (at runtime) to start at any index (typically 0, or 1, but other values are possible, for example -n/2)
I really liked the knife metaphor and what may distinguish c++ from Rust in practice. Rust seems to make it a bit of a pain when you want knifes, whereas c++ lets you opt in for knifes easily when you need them. A great talk, I'm excited for the future of c++ again.
@37:37 `f` being constexpr does not make it safe at runtime though. It does not have defined behavior for all inputs (Sean Baxter's definition). It does not check for overflow. What does this mean for safety?
Absolutely amazing talk! Thank you as always to Herb, Andrei, and all the great cpp folk involved pushing this topic forward :) I'm wondering if there's been any discussion around ingesting+outputting comments with the reflection utilities? Use case for ingesting -> Same as Unreal engine, the comments become tooltips in the UI for properties in the editor. Use case for outputting -> Allow generated classes/functions/members to have first-class tooltips as well in the IDE while discovering the generated code, choosing the right overloaded function, etc. As mentioned, if it's in the source, someone will ask for it :P
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
Reflection with code generation could enable that. The library just provide the metafunction and you only pay for the user types on which you applied the metafunction.
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[]`.
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 😃
It is very hard to take seriously a discussion on simplification from the people that brought us to the current state. At this point, I don't think any of these guys are capable of putting themselves in the shoes of a beginning programmer, to whom this Frankenstein of a language has become incoherent. I am experienced and still despair any time I have to look into the standard library code. And that is without these new features. Please, stop helping! That is the reason that Scott Meyers has given up writing his books, and I can see why nobody else even tries. There are half a dozen accepted ways to do a loop over an array. There is no other language with this degree of schizophrenia.
Checking cppreference: _the [[indeterminate]] attribute restores the undefined behavior that was implicitly introduced until C++26. It may make compilers consider a code path reading an indeterminate value unreachable._
Did they fix that std::bind placeholders so they are no longer needed? Can I write now something like: using namespace std; function< void (int) > handler = bind( object, &Object::Method ); ?
Zig looks really interesting, the only problem I see is that it's not even 1.0, and even if 1.0 is reached we have to wait another long long time to see useful libraries. Even Rust is not mature enough after 10 years since release ...
The assumption of the C++ committee seems to be "Developers are smart, just give them the tools to write safe code and they will write safe code." But my experience is rather this: "Developers are stupid and lazy. Allow them to write unsafe code and they will write code that is broken in ways you couldn't even imagine is possible."
They dont have a choice. The two super powers of C++ are speed and backwards compatibility. If you make unsafe impossible, you break speed. If you make safe default, it often means you break old programs.
@@timokreuzer381 And yes, your second statement is the reality. That's the reason for the Rust hype. With my C background I would love to stay in the C family with C++, but it's so hard to justify C++ if we have languages with better tooling and better default safety features. But man, I would love a C++ where we have all the modern features and throw all the old crap out. Syntax wise, C++ is one of my favourite languages, probably cause I like C so much haha
@@rutabega306 The "old code" argument is bogus. Old programs are written in old C++. If new C++ breaks your old code, either fix it or keep using old C++. Also nothing prevents the standard from having opt-in / opt-out features. They already exist anyway. Give me a command line option to make C-style arrays bounds checked by default and I will happily enabled it everywhere I can.
@@herbsutter4340 looking forward! Actually is there a cpp2 book in the making? It would also be helpful. Although the updated documentation is also great.
@@gregandark8571 It simplifies the C++ syntax to remove 40 years of cruft. Its also built to be "safe by default" Basically the slide with the rabbit, rewatch that part.
C++20 was/is really amazing. Writing code with piping syntax and all that lambda stuff makes it as productive (short) as Python code (but much faster :-) ).
@@ITSecNEO It would be great if we could get a Babel style transpiler for C++. I want to be able to use deducing this in my personal libraries, but I can't because then I need to keep a separate version when I attempt to use those libraries on architectures that don't have c++ 23 support. Some of these modern features are syntactic sugar, but some features are completely new language features and required compiler support to achieve. I am not sure how a transpiler would deal with the latter case.
@@StanleyPinchak you're probably looking for Circle or cppfront to some extent. It could be possible, but at that point reimplement the data structures you use (since you would also need to transpile the STL itself and that's a pain)
The constexpr factorial example is really bad. It only works, when you pass a compile time constant. But even when you forget to mark the result as constexpr, the warning goes away and it compiles just fine. The result is bogus. How is this supposed to help fix actual bugs? The common solution to all safety related issues seems to be one of "use this new stl container" or "just write correct code, then it will be safe".
The point is that it is possible to guarantee safety (no UB) if a function is evaluated at compile time. It is therefore theoretically possible to guarantee safety when a function is run at runtime. The principle issues are runtime performance and backwards compatibility.
@nullid1492 No, just because something works when evaluated at compile time doesn't mean it works, when evaluated at runtime, because compilers cannot evaluate every single possible input.
This is going to be great for things like static polymorphism where current patterns like type erasure require you to write the same thing three times and to generalize the fiddly bits like copying, allocation, SOO, etc.
I see direct applications for the reflection in config parsing! This would bring an end to hardcoding extracting e.g. JSON into a struct and I love it! Only downside is that it will only be usable in probably 5-10 years (for microcontrollers, GPUs etc.)
34:00 So am I reading this right that all existing code that intentionally doesn't initialize some variables will get slower by just recompiling? And to get the performance back we'll have to comb through all code and decorate it with [[indeterminate]]? That... doesn't sound good at all.
NO, if you watch the video till the end (1:22:01) you'll realise it's not true. The "filling uninitialised memory with pattern" only takes place "just before" you do an uninitialised read (which is generally a bug, and was already UB). Normal use case of uninitialised variables where you declare first and initialize at later point in time will continue to work without any performance impact as long as you initialize it before reading from it. for whatever reason if you want to do uninitialised reads (just why?), only then you need to use [[indeterminate]]
@@destiny_02 NO to you too :) At 1:22:01 Herb is talking about some feature he implemented in cpp2. That's not even proposed for C++ yet and that's not the same thing as [[indeterminate]]. To be honest even the explanation there looks like a straw man argument, because he talks about how compiler can't see past an opaque function call (which is the crux of the problem with this whole uninitialized thing) and then he shows an example with a known function that proves... what exactly? Nothing. Same problem remains - if I call a "fill(x)" function that is extern and linked in later compiler simply has no way to know if x is truly initialized or not. What 34:00 is talking about is forceful initialization with a pattern, suppressed by [[indeterminate]], which will degrade performance of code like "Some x; Fill(x);" by just recompiling. To get the performance back you'll have to change your code to "Some x [[indeterminate]]; Fill(x);"
Reflection on documentation comments. I could use field documentation to also generate a form with useful labels and tooltips. If it is also possible to generate additional files during compilation, doxygen becomes redundant.
That's some crazy stuff. It's the type of stuff I wished was possible but accepted to be impossible. Also I'm a fan of building on the lang instead of making something new. It's the way it should be.
@A beautiful language is much easier to understand than a messy one with lots of strange corner cases. In that sense beauty and pragmatism go together.
"We want to ... use undefined behavior, wehen we want it" - Yeah, great idea. Until you update your compiler and it decides to break your code by "optimizing" away your "intended" use of undefined behavior.
Wow, I usually rely on Python when such reflection is required , e.g. setattr and getattr. I am still hesitating to teach cpp20 as nowadays students really cannot understand this fuss about headers and sources.But these features look amazing.
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.
@@KeyT3ch Although a standard tool would be a real gamechanger. Every other modern language does it and I strongly believe that it is a weakness of the C++ ecosystem that we don't. Java has Maven (or Gradle which is built on Maven), JS/TS have npm,yarn or a tool that is compatible to them package wise, Rust has cargo, Python pip. To have a standard tool makes development so much easier as new developers can quickly add dependencies with just a command line execution without the need of learning a new language (cmake, conan...).
@@fernwaerts gradle isn't build on maven, it can grab libs from maven repos. that's it. and since maven didn' manage to do metadata right, gradle has its own format now, which can also reside in a maven repo. it would be nightmare if maven was part of the jdk
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++ has turned into crap because over the years they are just adding things while keeping backwards compatibility. Companies are the worst by expecting people to know C++.
All of it is very cool. It's just that the syntax is overwhelming. There are so many keywords and "tricks" involved [i.e. class(interface), while simple is another example of more syntax added]. It is tiring to keep up with. Remaining C++ developers must have an extreme level of perseverance, to learn so many constructs.
They have no choice. Languages that break everything, like Perl, died immediately when they abruptly changed it. Everyone hates Python's version hell. See nvm. See npm. Nobody would put up with native code that is that much of a mess of duplication.
@@douggale5962 um... Are you trying to imply Raku ("Perl 6") is when Perl broke things? Because Perl is Perl, Raku is an entirely different beast. I'm not sure what you're talking about, maybe some mythical Perl 8...
1:12:58 _"I don't know if it's a year or a decade away before it can write the`create_instrumented_type` function"_ LLMs can already write this level of code, I've used them for similar Rust macros
Most C++ users will not accept any attempt to limit the C++ language's ability to address (read & write) the lower metal state of processors. If someone wants to fix a memory leak or illegal memory access, a new language based on the current C++ or Java will be developed and evolve afterward.
Why not add "unsafe" code markers and enforce security by default ? There can also be some "-fallow-shoddy-code" flag. Operator [] should always do range check (there can be unsafe_at() version), uninitialized variables should never be allowed (unless you use unsafe code block) and implicit number promotions/conversions should be disabled by default (unless you want legacy behaviour in unsafe block or opt out with compiler flag).
@@pikachulovesketchup666because c++ philosophy is performance by default, safety when required. bounds checking every [] access can dramatically slow down some code by factors of 2-3x. you shouldn't pay for what you didn't ask for. if you wanna ask for, .at() exists.
"Why not zero-init?" IMHO the correct question: "Why a compiler doesn't make it error?" It's hilarious how c++ reluctantly continues to allow obviously incorrect programs.
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…
Accept implicit conversions to and from strings. With reflection, it is possible to generate a json (de)-serializer for structs, so you could assign any struct to a string, and vice versa.
Aren't pretty much all defaults wrong in C++? const, explicit, breaks in switch cases... All of those should really have been the default rather than opt-in.
Having watched the other talk from Andrei, I can only imagine nvidia was like "take these 100gazillion dollars and say AI is great!" haha. I dunno. Great talk though! Hopefully we get these sooner than later!
Reflection? Native code generation? Compile-time UB protection? Wow! C++ steps one small bit closer to being Rust. In 20 more years C++ might be able to do everything Rust can do today!
This guy is sponsored by Under Armour LOL does he comes from the gym? Enjoy C++? Difficulty high, whilst managers are getting paid 10x more and work 100x less.
You're topping the charts for the most unhinged hater on this video, like holy shit, touch some grass my guy. What do managers have to do with C++, as it is the literal same thing on Java, C#, Python, JS etc.? You're pulling anything out of your ass to discredit the language as if you can't just choose to not use it and be a Rust shill like everyone else. Or use C, which is worse.
On GPUs? Yeah right. Dream on. Most people don't have a clue what SIMD means, even though they think they can define it. "this" pointers are UTTERLY ASININE on GPUs. You should use AoSoA, or even full blown SpA. Mentioning GPUs in a C++ talk reveals a total lack of GPU understanding. Please STFU about GPUs until you have one iota of SoA support.
I'm suuuuuure there are no C++ GPU compilers and I'm suuuuuure people haven't done C++ for a long time interfacing with and even running on GPUs. You're being a fucking clown for no reason, because you are talking out of your ass and don't know GPGPU processing has been a thing since time immemorial. Or I guess you like to stay in shader land, in which case why are you even paying attention to what C++ does? 🤡
Why would those things be integrated into C++ and not as separate libraries? The language was never meant for those, but you can use it to write applications that run those workloads quickly and efficiently.
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!
@@herbsutter4340 Every time I watch a Herb talk, I feel better about C++. I guess that's what herbs are for.
Just say rust 😂(safety and security)
Yeah, Herb rules! It’s great to have a strong visible advocate for C++ when everyone is a critic.
Reminds me a bit of "This is fine" meme.
This is insane, so many possibilities with reflection/generation! Can't wait for the complete standardization and compiler implementation!
The convoluted syntax and that it might take 6 years before this is all available in C++29 is off-putting. You can do all this in Zig today, using a single keyword and easy-to-read code. I don't really see the simplification to C++.
Great talk! I'm really excited to try out C++26 and will definitely play with the new reflection and code generation constructs
1:29:35 the presence of a size function doesn't mean that the valid indices go from 0 to size - 1; even if the container is contiguous and random access. A container could start at 1 if it is designed to do so. For example, Boost.MultiArray can be declared (at runtime) to start at any index (typically 0, or 1, but other values are possible, for example -n/2)
C++ programmers are close to having the same realization that Fortran and Pascal had, how cute
I really liked the knife metaphor and what may distinguish c++ from Rust in practice. Rust seems to make it a bit of a pain when you want knifes, whereas c++ lets you opt in for knifes easily when you need them. A great talk, I'm excited for the future of c++ again.
I don't really use C++ but I love me a good talk from Herb.
Thank you so much for this fantastic 🎉 talk. Listened to it at least 3 times, still maintenance from it so much later
@37:37 `f` being constexpr does not make it safe at runtime though. It does not have defined behavior for all inputs (Sean Baxter's definition). It does not check for overflow. What does this mean for safety?
means "lipstick on a pig"; "nobody needs perfection", he said.
Awesome talk as always! Herb's and Andrei combo was incredible too! Loved it
Herb, your work is amazing. Thank you very much!
Absolutely amazing talk! Thank you as always to Herb, Andrei, and all the great cpp folk involved pushing this topic forward :)
I'm wondering if there's been any discussion around ingesting+outputting comments with the reflection utilities?
Use case for ingesting -> Same as Unreal engine, the comments become tooltips in the UI for properties in the editor.
Use case for outputting -> Allow generated classes/functions/members to have first-class tooltips as well in the IDE while discovering the generated code, choosing the right overloaded function, etc.
As mentioned, if it's in the source, someone will ask for it :P
Amazing talk, lot of programming pearls! Instrumented types is mindblowing...
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
Reflection with code generation could enable that. The library just provide the metafunction and you only pay for the user types on which you applied the metafunction.
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'd like to hear more about thing removed rather than added
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 😃
C++98 and C++03 are excellent languages.
@@CN_SFY_General C++11 is even better :)
40:53 Herb’s talk from Cppcon 2017: ua-cam.com/video/4AfRAVcThyA/v-deo.html
It is very hard to take seriously a discussion on simplification from the people that brought us to the current state. At this point, I don't think any of these guys are capable of putting themselves in the shoes of a beginning programmer, to whom this Frankenstein of a language has become incoherent.
I am experienced and still despair any time I have to look into the standard library code. And that is without these new features. Please, stop helping!
That is the reason that Scott Meyers has given up writing his books, and I can see why nobody else even tries. There are half a dozen accepted ways to do a loop over an array. There is no other language with this degree of schizophrenia.
34:20 Short question: If you opt in out of this, is reading from it still UB?
Sure, you would still get the "secret" leak, but besides that.
Checking cppreference: _the [[indeterminate]] attribute restores the undefined behavior that was implicitly introduced until C++26. It may make compilers consider a code path reading an indeterminate value unreachable._
Did they fix that std::bind placeholders so they are no longer needed? Can I write now something like:
using namespace std;
function< void (int) > handler = bind( object, &Object::Method );
?
51:48 Hana on CTRE from CppCon 2019: ua-cam.com/video/8dKWdJzPwHw/v-deo.html
If you want to play with a language similar to C++ but where all meta programming has been moved from templates to comptime reflection, there is Zig.
Zig looks really interesting, the only problem I see is that it's not even 1.0, and even if 1.0 is reached we have to wait another long long time to see useful libraries. Even Rust is not mature enough after 10 years since release ...
The assumption of the C++ committee seems to be "Developers are smart, just give them the tools to write safe code and they will write safe code." But my experience is rather this: "Developers are stupid and lazy. Allow them to write unsafe code and they will write code that is broken in ways you couldn't even imagine is possible."
They dont have a choice. The two super powers of C++ are speed and backwards compatibility.
If you make unsafe impossible, you break speed. If you make safe default, it often means you break old programs.
@@timokreuzer381 And yes, your second statement is the reality. That's the reason for the Rust hype. With my C background I would love to stay in the C family with C++, but it's so hard to justify C++ if we have languages with better tooling and better default safety features. But man, I would love a C++ where we have all the modern features and throw all the old crap out. Syntax wise, C++ is one of my favourite languages, probably cause I like C so much haha
@@rutabega306 The "old code" argument is bogus. Old programs are written in old C++. If new C++ breaks your old code, either fix it or keep using old C++. Also nothing prevents the standard from having opt-in / opt-out features. They already exist anyway. Give me a command line option to make C-style arrays bounds checked by default and I will happily enabled it everywhere I can.
1:26:22 Herb’s talk from 2022: ua-cam.com/video/ELeZAKCN4tY/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?
@@gregandark8571 It simplifies the C++ syntax to remove 40 years of cruft.
Its also built to be "safe by default"
Basically the slide with the rabbit, rewatch that part.
C++20 was/is really amazing. Writing code with piping syntax and all that lambda stuff makes it as productive (short) as Python code (but much faster :-) ).
Sadly the Compiler adoption is way too slow ._.
@@ITSecNEO It would be great if we could get a Babel style transpiler for C++. I want to be able to use deducing this in my personal libraries, but I can't because then I need to keep a separate version when I attempt to use those libraries on architectures that don't have c++ 23 support. Some of these modern features are syntactic sugar, but some features are completely new language features and required compiler support to achieve. I am not sure how a transpiler would deal with the latter case.
@@StanleyPinchak you're probably looking for Circle or cppfront to some extent. It could be possible, but at that point reimplement the data structures you use (since you would also need to transpile the STL itself and that's a pain)
The constexpr factorial example is really bad. It only works, when you pass a compile time constant. But even when you forget to mark the result as constexpr, the warning goes away and it compiles just fine. The result is bogus. How is this supposed to help fix actual bugs? The common solution to all safety related issues seems to be one of "use this new stl container" or "just write correct code, then it will be safe".
The point is that it is possible to guarantee safety (no UB) if a function is evaluated at compile time. It is therefore theoretically possible to guarantee safety when a function is run at runtime. The principle issues are runtime performance and backwards compatibility.
@nullid1492 No, just because something works when evaluated at compile time doesn't mean it works, when evaluated at runtime, because compilers cannot evaluate every single possible input.
This is going to be great for things like static polymorphism where current patterns like type erasure require you to write the same thing three times and to generalize the fiddly bits like copying, allocation, SOO, etc.
Hip hip hurray 🎉🎉🎉🎉🎉
22:20 Louis Dionne on STL safety in LLVM libc++: ua-cam.com/video/pQfjn7E4Qfc/v-deo.html
I see Alexandrescu I hit like
I see direct applications for the reflection in config parsing! This would bring an end to hardcoding extracting e.g. JSON into a struct and I love it! Only downside is that it will only be usable in probably 5-10 years (for microcontrollers, GPUs etc.)
34:00 So am I reading this right that all existing code that intentionally doesn't initialize some variables will get slower by just recompiling? And to get the performance back we'll have to comb through all code and decorate it with [[indeterminate]]? That... doesn't sound good at all.
yeah and what happened to "not paying for what you don't use" mantra
honestly this update sounds weird
yeah I was hopping someone would ask him about that... sad no-one did...
NO, if you watch the video till the end (1:22:01) you'll realise it's not true. The "filling uninitialised memory with pattern" only takes place "just before" you do an uninitialised read (which is generally a bug, and was already UB).
Normal use case of uninitialised variables where you declare first and initialize at later point in time will continue to work without any performance impact as long as you initialize it before reading from it.
for whatever reason if you want to do uninitialised reads (just why?), only then you need to use [[indeterminate]]
@@destiny_02 NO to you too :) At 1:22:01 Herb is talking about some feature he implemented in cpp2. That's not even proposed for C++ yet and that's not the same thing as [[indeterminate]]. To be honest even the explanation there looks like a straw man argument, because he talks about how compiler can't see past an opaque function call (which is the crux of the problem with this whole uninitialized thing) and then he shows an example with a known function that proves... what exactly? Nothing. Same problem remains - if I call a "fill(x)" function that is extern and linked in later compiler simply has no way to know if x is truly initialized or not. What 34:00 is talking about is forceful initialization with a pattern, suppressed by [[indeterminate]], which will degrade performance of code like "Some x; Fill(x);" by just recompiling. To get the performance back you'll have to change your code to "Some x [[indeterminate]]; Fill(x);"
@@ChrisAverageYT wouldn't x be a pointer-to-pointer with fill(x)
Reflection on documentation comments. I could use field documentation to also generate a form with useful labels and tooltips. If it is also possible to generate additional files during compilation, doxygen becomes redundant.
This man knows how to excite
That's some crazy stuff. It's the type of stuff I wished was possible but accepted to be impossible. Also I'm a fan of building on the lang instead of making something new. It's the way it should be.
"I care less about the syntax being beautiful, I want the functionality now" lol
I love beauty, but I'm also a pragmatist! 😁
@A beautiful language is much easier to understand than a messy one with lots of strange corner cases. In that sense beauty and pragmatism go together.
And that's how we get horrific syntax locked into the standard for all eternity ;)
so, standart can take decades to be in any production code😅
"We want to ... use undefined behavior, wehen we want it" - Yeah, great idea. Until you update your compiler and it decides to break your code by "optimizing" away your "intended" use of undefined behavior.
Its all fun and games until theres a compile error
And the error caused by a template issue. Next level of hell.
It's all fun and games until the compiler itself segfaults
So, since 1994, we have a virtual C++ machine within a C++ compiler?
No, that would probably be 2011, as you have to run constexpr C++ *somehow*
Uffff the property thing, uffff love it :D
Wow, I usually rely on Python when such reflection is required , e.g. setattr and getattr. I am still hesitating to teach cpp20 as nowadays students really cannot understand this fuss about headers and sources.But these features look amazing.
Fucking awesome. Cant wait for macros in c++.
Herb Sutter kinda looks like the John cena of C++
1:08:17 “it could also be C++” - this sounds like syn::parse in rust procedural macros!!!
3 years is a long cycle, ideally 6 month iterative feature additions 🤔
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.
Try the Meson build system
@@KeyT3ch Although a standard tool would be a real gamechanger. Every other modern language does it and I strongly believe that it is a weakness of the C++ ecosystem that we don't. Java has Maven (or Gradle which is built on Maven), JS/TS have npm,yarn or a tool that is compatible to them package wise, Rust has cargo, Python pip. To have a standard tool makes development so much easier as new developers can quickly add dependencies with just a command line execution without the need of learning a new language (cmake, conan...).
@@fernwaerts gradle isn't build on maven, it can grab libs from maven repos. that's it. and since maven didn' manage to do metadata right, gradle has its own format now, which can also reside in a maven repo. it would be nightmare if maven was part of the jdk
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.
You’re not alone!
C++ has turned into crap because over the years they are just adding things while keeping backwards compatibility. Companies are the worst by expecting people to know C++.
Circle was the way to go...
All of it is very cool. It's just that the syntax is overwhelming. There are so many keywords and "tricks" involved [i.e. class(interface), while simple is another example of more syntax added]. It is tiring to keep up with. Remaining C++ developers must have an extreme level of perseverance, to learn so many constructs.
They have no choice. Languages that break everything, like Perl, died immediately when they abruptly changed it. Everyone hates Python's version hell. See nvm. See npm. Nobody would put up with native code that is that much of a mess of duplication.
@@douggale5962 um... Are you trying to imply Raku ("Perl 6") is when Perl broke things? Because Perl is Perl, Raku is an entirely different beast. I'm not sure what you're talking about, maybe some mythical Perl 8...
1:12:58 _"I don't know if it's a year or a decade away before it can write the`create_instrumented_type` function"_ LLMs can already write this level of code, I've used them for similar Rust macros
yeah, it's more going to be "how long until LLMs have seen such C++ code until they can do it themselves"
45:44. LOL, the way he said "even I can't write this code correctly," implying that he considers himself almost infallible when it comes to coding...
32:35 this is the stupiest improvement I'v seen. How about I need that, testing this? This is bullshit. I need more abstraction to test abstraction
Most C++ users will not accept any attempt to limit the C++ language's ability to address (read & write) the lower metal state of processors. If someone wants to fix a memory leak or illegal memory access, a new language based on the current C++ or Java will be developed and evolve afterward.
Why not add "unsafe" code markers and enforce security by default ? There can also be some "-fallow-shoddy-code" flag. Operator [] should always do range check (there can be unsafe_at() version), uninitialized variables should never be allowed (unless you use unsafe code block) and implicit number promotions/conversions should be disabled by default (unless you want legacy behaviour in unsafe block or opt out with compiler flag).
@@pikachulovesketchup666because c++ philosophy is performance by default, safety when required.
bounds checking every [] access can dramatically slow down some code by factors of 2-3x. you shouldn't pay for what you didn't ask for. if you wanna ask for, .at() exists.
"Why not zero-init?" IMHO the correct question: "Why a compiler doesn't make it error?" It's hilarious how c++ reluctantly continues to allow obviously incorrect programs.
i think some language semantics make it so that obvious isn't so obvious to compilers
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…
Accept implicit conversions to and from strings. With reflection, it is possible to generate a json (de)-serializer for structs, so you could assign any struct to a string, and vice versa.
I hate implicit conversations.
Aren't pretty much all defaults wrong in C++? const, explicit, breaks in switch cases... All of those should really have been the default rather than opt-in.
Having watched the other talk from Andrei, I can only imagine nvidia was like "take these 100gazillion dollars and say AI is great!" haha. I dunno.
Great talk though! Hopefully we get these sooner than later!
Investments are the roots of financial security; the deeper they grow, the stronger your future will be."
C++ - great features and terrible design!
Reflection? Native code generation? Compile-time UB protection? Wow! C++ steps one small bit closer to being Rust. In 20 more years C++ might be able to do everything Rust can do today!
This guy is sponsored by Under Armour LOL does he comes from the gym? Enjoy C++? Difficulty high, whilst managers are getting paid 10x more and work 100x less.
You're topping the charts for the most unhinged hater on this video, like holy shit, touch some grass my guy. What do managers have to do with C++, as it is the literal same thing on Java, C#, Python, JS etc.? You're pulling anything out of your ass to discredit the language as if you can't just choose to not use it and be a Rust shill like everyone else. Or use C, which is worse.
On GPUs? Yeah right. Dream on. Most people don't have a clue what SIMD means, even though they think they can define it. "this" pointers are UTTERLY ASININE on GPUs. You should use AoSoA, or even full blown SpA. Mentioning GPUs in a C++ talk reveals a total lack of GPU understanding. Please STFU about GPUs until you have one iota of SoA support.
I'm suuuuuure there are no C++ GPU compilers and I'm suuuuuure people haven't done C++ for a long time interfacing with and even running on GPUs. You're being a fucking clown for no reason, because you are talking out of your ass and don't know GPGPU processing has been a thing since time immemorial. Or I guess you like to stay in shader land, in which case why are you even paying attention to what C++ does? 🤡
this is such a goofy comment
Hightime for C++ to have some AI/ML related and Quantum Computing features..
- by, common human
Why would those things be integrated into C++ and not as separate libraries? The language was never meant for those, but you can use it to write applications that run those workloads quickly and efficiently.
It seems they want to make C++ looks similar to Rust 🤣🤣🤣