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.
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 :-) ).
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
@@herbsutter4340 looking forward! Actually is there a cpp2 book in the making? It would also be helpful. Although the updated documentation is also great.
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): ruclips.net/video/I3ov8HcdVKw/видео.html
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 😃
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 ...
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.)
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[]`.
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.
@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.
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
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 ); ?
"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.
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".
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
"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.
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: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);"
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.
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
NO, if you watch the talk till end, he gives more details about proposal for initialisation with pattern. TL;DR in a code with no uninitialised reads (such reads are generally a bug), this safety proposal will have no impact on performance. the compiler will only fill the memory with pattern before any uninitialised read happens, this can be used to detect at runtime by sanitizers and debuggers. And realistically the compiler will warn you before that and you'll have 3 choices: 1. uninitialised read is likely a bug, fix your code (preferred) 2. ignore warning and let the compiler do pattern initialisation 3. if the uninitialised read is intentional (rare case), mark the variable declaration with [[indeterminate]] attribute.
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++.
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.
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: ruclips.net/video/bb9hPtuVaTU/видео.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.
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.
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++.
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)
Great talk! I'm really excited to try out C++26 and will definitely play with the new reflection and code generation constructs
I don't really use C++ but I love me a good talk from Herb.
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.
Awesome talk as always! Herb's and Andrei combo was incredible too! Loved it
Amazing talk, lot of programming pearls! Instrumented types is mindblowing...
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 ._.
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'd like to hear more about thing removed rather than added
Herb, your work is amazing. Thank you very much!
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?
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): ruclips.net/video/I3ov8HcdVKw/видео.html
I see Alexandrescu I hit like
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.
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 ...
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.
40:53 Herb’s talk from Cppcon 2017: ruclips.net/video/4AfRAVcThyA/видео.html
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.)
1:26:22 Herb’s talk from 2022: ruclips.net/video/ELeZAKCN4tY/видео.html
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
This man knows how to excite
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.
"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😅
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
Hip hip hurray 🎉🎉🎉🎉🎉
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: ruclips.net/video/8dKWdJzPwHw/видео.html
"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?
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.
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".
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
"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.
22:20 Louis Dionne on STL safety in LLVM libc++: ruclips.net/video/pQfjn7E4Qfc/видео.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: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);"
Investments are the roots of financial security; the deeper they grow, the stronger your future will be."
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.
1:08:17 “it could also be C++” - this sounds like syn::parse in rust procedural macros!!!
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
Is C++26 exchanging performance for type and memory safety?
NO, if you watch the talk till end, he gives more details about proposal for initialisation with pattern.
TL;DR in a code with no uninitialised reads (such reads are generally a bug), this safety proposal will have no impact on performance.
the compiler will only fill the memory with pattern before any uninitialised read happens, this can be used to detect at runtime by sanitizers and debuggers. And realistically the compiler will warn you before that and you'll have 3 choices:
1. uninitialised read is likely a bug, fix your code (preferred)
2. ignore warning and let the compiler do pattern initialisation
3. if the uninitialised read is intentional (rare case), mark the variable declaration with [[indeterminate]] attribute.
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...
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.
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...
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: ruclips.net/video/bb9hPtuVaTU/видео.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.
*Hightime for C++ to have some AI/ML related and Quantum Computing features..*
- by, common human