Visit cppcon.org for details on next year's conference. CppCon sponsors have made it possible to record and freely distribute over 1000 sessions from the first CppCon in 2014 to the present. We hope you enjoy them!
Interesting how a lot of cppcon talks are about how horrible the C++ language is.
@JawwadHafeez2 күн бұрын
Very useful info. Got perspective of another developer on the subject. Thanks
@cppforeveryone3 күн бұрын
So, you don't aim at having code that can be compiled, and you don't aim at providing a good definition of the main topic you want to explain. There is some value in the talk... but it's not wortth the time.
@jimcameron68033 күн бұрын
"How many lines of code can you type in and have it work first time?" Me: On average ... about 1/2?
@kuhluhOG3 күн бұрын
5:26 Here really dodged a bullet there by saying TAB_SIZE amount instead of a specific number.
@Ircy20124 күн бұрын
I want to learn C++ but the more I learn either from books or elsewhere the more it seems like C++ is a language that wrote itself into a corner of bad decisions and now can't fix them because it has to keep backwards compatibility and people can't switch because nothing else with the same use cases is as developed (or widely used) as it. Like all this would be so much easier and less error prone if the compiler didn't create or remove different things depending on a myriad of factors but just expected you to define what you need and to manually tell it to provide defaults (or mark as intentionally not implemented) for what you didn't.
@destiny_025 күн бұрын
Amen
@trungngo91695 күн бұрын
look like rust
@Reneg9735 күн бұрын
Regarding is_trivially_constructible: what is it good for? Any members should have default values, so I currently don't see a use case
@314Labs6 күн бұрын
They're all "fun ones"
@davidhcefx6 күн бұрын
gcc 11+ turned on with -O2 by default, nightmare
@xtra-medium6 күн бұрын
3:26 Note that it IS possible to explicitly specify a template argument for a generic lambda, you just have to spell out the call operator: ``` auto lambda = []< typename T >(){ return T{}; }; auto result = lambda.operator()< float >(); ```
@314Labs4 күн бұрын
Would it be possible to specify the template argument in a IIFE?
@user-gr8fg4ub4v4 күн бұрын
oh! auto v = []<typename T>(T){ return 2 + 2; }.operator()<int>(1);
@carneirouece6 күн бұрын
is there something more annoying than vocal fry?
@SomebodyHere-cm8dj6 күн бұрын
I wrote a particularly evil function function the other day, that takes a uint16_t the other day and calls a function that takes the entered number as its template parameter, generating all the if statements with templates and recursive calls.
@MrAbrazildo6 күн бұрын
1:25, and the memory wasn't initialized.
@learpcss95695 күн бұрын
does it matter for in the context of a question?
@shelper6 күн бұрын
is there a plan to integrate this into taskflow? or it will be its own library?
@agentstona8 күн бұрын
THIS IS ALL A WASTE OF TIME JUST SWITCH TO RUST OR PYTHON where memory is automanaged for you .... WHY YOU wasting your time attempting to manage stuff that can be automated ....
@prudhvirajsatyavarapu58018 күн бұрын
@9:16 The threads executed parallely to increment the value of X from 0. Both of the threads will get X as 0 and set to 1 and writes back to memory. Even though the memory is their it got to be rewrite by other thread to 1 only So how come x got to be 2
@xealit9 күн бұрын
Damn. I was looking for Scott Meyers or this guy to talk about CRTP and he just skipped the pattern...
@DerHerrLatz9 күн бұрын
Reading the comments is even better than watching the video. This topic seems to be hotter than tabs vs. spaces.
@wolpumba40999 күн бұрын
*Summary* This talk focuses on optimizing C++ programs for performance. *Goals of Efficient Programs:* (1:03) * *Don't do unnecessary work:* Avoid redundant computations, like unnecessary copying and memory allocations. * *Use all available computing power:* Leverage multi-core CPUs and SIMD intrinsics. * *Avoid unnecessary waits and stalls:* Minimize time spent waiting for dependencies, use lock-free data structures, asynchronous APIs, job systems. * *Use hardware efficiently:* Write cache-friendly and well-predictable code for better speculative execution and cache utilization. * *Be efficient at the OS level:* Use OS-specific APIs to allocate resources efficiently. *Optimization Approaches:* (4:44) 1. *Effective use of language:* Utilize features like `noexcept`, `const`, `constexpr`, and attributes. 2. *Build pipeline optimization:* Use different compilers, flags, and link-time optimization. 3. *Manual optimization:* Make changes to design and implementation for performance. *Specific Optimization Opportunities:* * *Build Pipeline:* (5:44) * Enable compiler optimizations: `-O2`, `-O3`, target architecture. (5:47) * Use Fast Math flag (where applicable). (6:25) * Consider disabling exceptions and RTTI (carefully). * Enable link-time optimization (LTO). (7:10) * Consider Unity builds. (8:01) * Link statically with dependencies. (8:43) * Use profile-guided optimizations (PGO). * Experiment with different compilers and standard libraries. * Use faster memory allocators. * Employ binary post-processing tools (e.g., LLVM Bolt). * *C++ Code:* (12:16) * *Annotations:* (12:22) * Use `constexp` and `const` to encourage compile-time evaluation. (12:35) * Mark functions `const` if they don't modify state. * Use `noexcept` for functions that don't throw exceptions. (17:31) * Utilize `static` for internal linkage to enable inlining. (18:40) * Employ attributes: `noreturn`, `likely`/`unlikely`, `assume`, `restrict`, `pure`. (20:49) * *Function Boundaries:* (27:17) * Carefully choose parameter passing strategies (by value, reference, const reference) based on ownership, mutability, and size. (27:30) * Utilize `std::optional`, smart pointers, `std::span`, ranges, iterators appropriately. * Prefer `std::string_view` over `char*` or `std::string` references for read-only strings. * Employ `std::move_only_function` or function pointers for passing invocables (31:14). * *Object Construction and Copying:* (32:18) * Avoid constructing heap-allocated objects inside loops. (32:24) * Use `reserve` for containers to pre-allocate memory. * Catch exceptions by reference to prevent copies. (33:23) * *Value Semantics:* (34:10) * Implement rvalue-qualified member functions to enable move semantics. * Utilize C++23's explicit object parameter declaration for concise rvalue overload handling. * *Hardware Optimization:* (35:56) * *Memory:* (36:03) * Access memory sequentially for better caching and prefetching. (42:21) * Utilize contiguous data structures (arrays, vectors). * Strategically order class members for cache locality. * Consider thread affinities for reduced cache contention. * Avoid false sharing by padding data structures. * Use non-temporal stores for specific scenarios. * *Branch Prediction:* (46:18) * Minimize indirect calls (virtual functions, function pointers) in critical code. (47:06) * Write predictable branches. (47:31) * Explore branchless optimization techniques. (48:52) * *SIMD:* (50:28) * Use SIMD intrinsics for data-parallel operations. (51:31) * Consider using tools for automatic vectorization. *Tools and Practices:* * Use real-time code analysis tools (e.g., clangd). * Implement performance tests in CI/CD pipelines. (54:58) *Important Considerations:* * Always profile and benchmark to measure actual performance gains. * Be aware of potential pitfalls and undefined behavior when using advanced optimization techniques. * Balance performance optimization with code readability and maintainability. i used gemini 1.5 pro to summarize the video transcript
@sonicewave9 күн бұрын
I'm happy after 10 years of programming in C++ I don't miss this language. It never seems to be getting simpler or cleaner to understand. So many, you will never need this new feature. It's this that killed this programming language with some mind virus where C++ programmers get a boner writting shitty complex code.
@gast12810 күн бұрын
Boost's static_vector; small_vector; circular_buffer and flat_map are all useful additions to std containers. Only flat_map is scheduled to be standardized.
@MrAbrazildo10 күн бұрын
2:00, I know this is just a silly example. But it's nice to point some things. I use to separate the midia (big data) of a circle, from "its logic", which is likely to fit on caches. So it becomes an "OO inspired by DOD" approach. As for for range loop, despite being a C++11 thing, I only passed to use it from C++14. It was required to specify the type. So on those years I used a macro of my own, which deduced the type, at the cost of using pointer syntax. I think "auto all the things" is gold. 3:31, good, because there are old things with bad reputation, that actually are pretty useful - macro, old enum, someone could say unions. So, don't make mistakes Carbon folks are already doing!
@DanielHanson-en3ck10 күн бұрын
Really straightforward and informative talk -- well done.
@SystemSigma_12 күн бұрын
Great talk. Still, incredibile how far the madness of the c++ committee has gone just to copy a pointer.
@user-kh8nz7rg7j12 күн бұрын
Just awesome! Thanks CppCon for sharing. I love C++ and its great fantastic community!
@poggarzz12 күн бұрын
12:29 the area function taking in two Point killed me just a little bit from the inside
@EgorChebotarev12 күн бұрын
good explanation
@philrosenberg880512 күн бұрын
Loved when he asked who knows when to use type name and template. I fight with this every time - the answer is when I get a compile error and I can't work out why and adding type name or template makes it go away! This sounds great and I hope it gets accepted
@sonicewave12 күн бұрын
C++ keep getting uglier and more complex, so glad after 10 years of it, I gave up being a C++ developer. People are still stuck with C++11, no way they are even using any of the modern stuff, and if they are, they are not using is correctly. I don't miss C++, switched to web and TypeScript and currently getting more and more into Java + Spring Boot and it's so much better and productive then the mess called C++. What I hated the most about C++ were all the nerds that over-engineed and wrote complicated, hard to understand and maintain code. Template and meta-template coding killed C++ for me.
@blaze349513 күн бұрын
Bjarne looking really good!
@EgorChebotarev13 күн бұрын
nice
@aprasath113 күн бұрын
wonderful talk and gave a very nice overview of all constructs in just 1 hr. Amazing.
@DwayneRobinsonMS13 күн бұрын
Rules 1 and 2: This is so much more visually scannable in a single pass of the eye 👀, and it has code diffing clarity benefits too (which sustained engineering and security reviewers can appreciate, so it doesn't appear that updating one parameter reflows the entire line and all following parameters). I strongly wish I could reflow the entire Chromium/TensorFlow/ONNX Runtime code format, as they are the most eye stabbing I've endured in the past 20 years of C++ coding. 😅 Rule 4: "80 columns is enough for anyone". Hmm, me thinks you haven't seen much of the Chromium codebase where these VGA-era restrictions often lead to awfully split/raggedly broken lines that would otherwise nicely fit with 120 columns to be more linearly scannable. Rule 6: Yes. ✅🧻
@aprasath115 күн бұрын
Wonderful video!!! Very well explained covering lots of issues with usage as well.
@sankalpramesh547815 күн бұрын
How does putting reference count at the start of the class help?
@simonmaracine472116 күн бұрын
This talk was fantastic!
@LetsDark17 күн бұрын
I'm not sure if I would like a Typescript for C++ because I hate the JS/TS Ecosystem. Configuring webpack, vite, tsconfig, eslint and so on. And in this ecosystem there are more people working on tooling (maybe too many) and it isn't great.
@olafschluter70617 күн бұрын
If you want to avoid a discussion about an uncomfortable problem you do not have a solution for that you like, move the debate onto "what does .... mean?". This is happening in this panel discussion a lot. The elephant in the room are the evident security vulnerabilites originating from the ubiquitous usage of C/C++ features that have a high risk of causing those vulnerability issues, but this panel tries to redefine "safety and security" in more general terms, covering even the impossibility to deliver a program that behaves correct under all circumstances, even those that no one had thought of when designing and creating the program. And concluding that programming languages can't support that (which is true, even for Rust). If your algorithm has a logic flaw, no compiler or interpreter is able to tell you so. But that isn't the current topic. The current topic is the huge attack surface created by legacy C/C++ code in living systems that gets exploited with increasing intense. And that new programming languages have come up that address those flaws of C/C++ responsible for the vulnerabilities to exist and suggest a better approach. And this is new: for decades C and C++ were unrivaled in the system programming area. If you are running any kind of software, you can be sure there is C or C++ code in it covering the performance-relevant and close-to-the-OS/machine parts. Now there is more modern competition coming up. And both C and C++ may have their Nokia moment. Most bugs in production software are technical flaws, where the algorithms and concepts applied do work, but implementation details, lack of failure handling and other edge cases cause the program to fail. This isn't a problem of incomplete specifications or circumstances no one ever thought of. The standard use cases of software are well-tested these days. But even just with malformed input, bugs appear - monkeys can kill code. Hackers, acting on purpose, even more so. Each attack on software starts with well-crafted malformed input the attacked program fails to recognise as such. Until it hits a place in the code where the developer assumed well-formed input and applied one of those many shortcuts the dinosaurs C or C++ allow based on that assumption - system compromised. So the least you should do is: distrust input, always check that it is conformant to the spec, even if that hurts performance, fail graciously on any malformed input. That can be done in any programming language. Some enforce to do this more than others.
@gubgubbubbub17 күн бұрын
Excellent speaker and content!
@user-kh8nz7rg7j17 күн бұрын
Great talk! Thanks for sharing!
@gregandark857118 күн бұрын
The talk starts at minute 57:00
@placintaalexandru85518 күн бұрын
At this level I'd just go with Rust since this is CPrustPrust
@wallacesousuke143318 күн бұрын
Programming SUX
@ckjdinnj19 күн бұрын
This is so gross Good god I hope they never build this into the language. Just code in python or JavaScript if you want to erase your types.
@darinvelarde454719 күн бұрын
This is a really good talk. The folks saying he's not fair to OOP have just not seen that the juice is worth the squeeze. We have all been lied to. OOP is not the only tool, and the others happen to be better and simpler. I've been using a procedural and data oriented approach since about 2011 and it has never let me down. It has gained performance, added readability, made the code more composable, and made it easier to test. OOP is an unfortunate detour on the way to enlightenment.
Пікірлер
Interesting how a lot of cppcon talks are about how horrible the C++ language is.
Very useful info. Got perspective of another developer on the subject. Thanks
So, you don't aim at having code that can be compiled, and you don't aim at providing a good definition of the main topic you want to explain. There is some value in the talk... but it's not wortth the time.
"How many lines of code can you type in and have it work first time?" Me: On average ... about 1/2?
5:26 Here really dodged a bullet there by saying TAB_SIZE amount instead of a specific number.
I want to learn C++ but the more I learn either from books or elsewhere the more it seems like C++ is a language that wrote itself into a corner of bad decisions and now can't fix them because it has to keep backwards compatibility and people can't switch because nothing else with the same use cases is as developed (or widely used) as it. Like all this would be so much easier and less error prone if the compiler didn't create or remove different things depending on a myriad of factors but just expected you to define what you need and to manually tell it to provide defaults (or mark as intentionally not implemented) for what you didn't.
Amen
look like rust
Regarding is_trivially_constructible: what is it good for? Any members should have default values, so I currently don't see a use case
They're all "fun ones"
gcc 11+ turned on with -O2 by default, nightmare
3:26 Note that it IS possible to explicitly specify a template argument for a generic lambda, you just have to spell out the call operator: ``` auto lambda = []< typename T >(){ return T{}; }; auto result = lambda.operator()< float >(); ```
Would it be possible to specify the template argument in a IIFE?
oh! auto v = []<typename T>(T){ return 2 + 2; }.operator()<int>(1);
is there something more annoying than vocal fry?
I wrote a particularly evil function function the other day, that takes a uint16_t the other day and calls a function that takes the entered number as its template parameter, generating all the if statements with templates and recursive calls.
1:25, and the memory wasn't initialized.
does it matter for in the context of a question?
is there a plan to integrate this into taskflow? or it will be its own library?
THIS IS ALL A WASTE OF TIME JUST SWITCH TO RUST OR PYTHON where memory is automanaged for you .... WHY YOU wasting your time attempting to manage stuff that can be automated ....
@9:16 The threads executed parallely to increment the value of X from 0. Both of the threads will get X as 0 and set to 1 and writes back to memory. Even though the memory is their it got to be rewrite by other thread to 1 only So how come x got to be 2
Damn. I was looking for Scott Meyers or this guy to talk about CRTP and he just skipped the pattern...
Reading the comments is even better than watching the video. This topic seems to be hotter than tabs vs. spaces.
*Summary* This talk focuses on optimizing C++ programs for performance. *Goals of Efficient Programs:* (1:03) * *Don't do unnecessary work:* Avoid redundant computations, like unnecessary copying and memory allocations. * *Use all available computing power:* Leverage multi-core CPUs and SIMD intrinsics. * *Avoid unnecessary waits and stalls:* Minimize time spent waiting for dependencies, use lock-free data structures, asynchronous APIs, job systems. * *Use hardware efficiently:* Write cache-friendly and well-predictable code for better speculative execution and cache utilization. * *Be efficient at the OS level:* Use OS-specific APIs to allocate resources efficiently. *Optimization Approaches:* (4:44) 1. *Effective use of language:* Utilize features like `noexcept`, `const`, `constexpr`, and attributes. 2. *Build pipeline optimization:* Use different compilers, flags, and link-time optimization. 3. *Manual optimization:* Make changes to design and implementation for performance. *Specific Optimization Opportunities:* * *Build Pipeline:* (5:44) * Enable compiler optimizations: `-O2`, `-O3`, target architecture. (5:47) * Use Fast Math flag (where applicable). (6:25) * Consider disabling exceptions and RTTI (carefully). * Enable link-time optimization (LTO). (7:10) * Consider Unity builds. (8:01) * Link statically with dependencies. (8:43) * Use profile-guided optimizations (PGO). * Experiment with different compilers and standard libraries. * Use faster memory allocators. * Employ binary post-processing tools (e.g., LLVM Bolt). * *C++ Code:* (12:16) * *Annotations:* (12:22) * Use `constexp` and `const` to encourage compile-time evaluation. (12:35) * Mark functions `const` if they don't modify state. * Use `noexcept` for functions that don't throw exceptions. (17:31) * Utilize `static` for internal linkage to enable inlining. (18:40) * Employ attributes: `noreturn`, `likely`/`unlikely`, `assume`, `restrict`, `pure`. (20:49) * *Function Boundaries:* (27:17) * Carefully choose parameter passing strategies (by value, reference, const reference) based on ownership, mutability, and size. (27:30) * Utilize `std::optional`, smart pointers, `std::span`, ranges, iterators appropriately. * Prefer `std::string_view` over `char*` or `std::string` references for read-only strings. * Employ `std::move_only_function` or function pointers for passing invocables (31:14). * *Object Construction and Copying:* (32:18) * Avoid constructing heap-allocated objects inside loops. (32:24) * Use `reserve` for containers to pre-allocate memory. * Catch exceptions by reference to prevent copies. (33:23) * *Value Semantics:* (34:10) * Implement rvalue-qualified member functions to enable move semantics. * Utilize C++23's explicit object parameter declaration for concise rvalue overload handling. * *Hardware Optimization:* (35:56) * *Memory:* (36:03) * Access memory sequentially for better caching and prefetching. (42:21) * Utilize contiguous data structures (arrays, vectors). * Strategically order class members for cache locality. * Consider thread affinities for reduced cache contention. * Avoid false sharing by padding data structures. * Use non-temporal stores for specific scenarios. * *Branch Prediction:* (46:18) * Minimize indirect calls (virtual functions, function pointers) in critical code. (47:06) * Write predictable branches. (47:31) * Explore branchless optimization techniques. (48:52) * *SIMD:* (50:28) * Use SIMD intrinsics for data-parallel operations. (51:31) * Consider using tools for automatic vectorization. *Tools and Practices:* * Use real-time code analysis tools (e.g., clangd). * Implement performance tests in CI/CD pipelines. (54:58) *Important Considerations:* * Always profile and benchmark to measure actual performance gains. * Be aware of potential pitfalls and undefined behavior when using advanced optimization techniques. * Balance performance optimization with code readability and maintainability. i used gemini 1.5 pro to summarize the video transcript
I'm happy after 10 years of programming in C++ I don't miss this language. It never seems to be getting simpler or cleaner to understand. So many, you will never need this new feature. It's this that killed this programming language with some mind virus where C++ programmers get a boner writting shitty complex code.
Boost's static_vector; small_vector; circular_buffer and flat_map are all useful additions to std containers. Only flat_map is scheduled to be standardized.
2:00, I know this is just a silly example. But it's nice to point some things. I use to separate the midia (big data) of a circle, from "its logic", which is likely to fit on caches. So it becomes an "OO inspired by DOD" approach. As for for range loop, despite being a C++11 thing, I only passed to use it from C++14. It was required to specify the type. So on those years I used a macro of my own, which deduced the type, at the cost of using pointer syntax. I think "auto all the things" is gold. 3:31, good, because there are old things with bad reputation, that actually are pretty useful - macro, old enum, someone could say unions. So, don't make mistakes Carbon folks are already doing!
Really straightforward and informative talk -- well done.
Great talk. Still, incredibile how far the madness of the c++ committee has gone just to copy a pointer.
Just awesome! Thanks CppCon for sharing. I love C++ and its great fantastic community!
12:29 the area function taking in two Point killed me just a little bit from the inside
good explanation
Loved when he asked who knows when to use type name and template. I fight with this every time - the answer is when I get a compile error and I can't work out why and adding type name or template makes it go away! This sounds great and I hope it gets accepted
C++ keep getting uglier and more complex, so glad after 10 years of it, I gave up being a C++ developer. People are still stuck with C++11, no way they are even using any of the modern stuff, and if they are, they are not using is correctly. I don't miss C++, switched to web and TypeScript and currently getting more and more into Java + Spring Boot and it's so much better and productive then the mess called C++. What I hated the most about C++ were all the nerds that over-engineed and wrote complicated, hard to understand and maintain code. Template and meta-template coding killed C++ for me.
Bjarne looking really good!
nice
wonderful talk and gave a very nice overview of all constructs in just 1 hr. Amazing.
Rules 1 and 2: This is so much more visually scannable in a single pass of the eye 👀, and it has code diffing clarity benefits too (which sustained engineering and security reviewers can appreciate, so it doesn't appear that updating one parameter reflows the entire line and all following parameters). I strongly wish I could reflow the entire Chromium/TensorFlow/ONNX Runtime code format, as they are the most eye stabbing I've endured in the past 20 years of C++ coding. 😅 Rule 4: "80 columns is enough for anyone". Hmm, me thinks you haven't seen much of the Chromium codebase where these VGA-era restrictions often lead to awfully split/raggedly broken lines that would otherwise nicely fit with 120 columns to be more linearly scannable. Rule 6: Yes. ✅🧻
Wonderful video!!! Very well explained covering lots of issues with usage as well.
How does putting reference count at the start of the class help?
This talk was fantastic!
I'm not sure if I would like a Typescript for C++ because I hate the JS/TS Ecosystem. Configuring webpack, vite, tsconfig, eslint and so on. And in this ecosystem there are more people working on tooling (maybe too many) and it isn't great.
If you want to avoid a discussion about an uncomfortable problem you do not have a solution for that you like, move the debate onto "what does .... mean?". This is happening in this panel discussion a lot. The elephant in the room are the evident security vulnerabilites originating from the ubiquitous usage of C/C++ features that have a high risk of causing those vulnerability issues, but this panel tries to redefine "safety and security" in more general terms, covering even the impossibility to deliver a program that behaves correct under all circumstances, even those that no one had thought of when designing and creating the program. And concluding that programming languages can't support that (which is true, even for Rust). If your algorithm has a logic flaw, no compiler or interpreter is able to tell you so. But that isn't the current topic. The current topic is the huge attack surface created by legacy C/C++ code in living systems that gets exploited with increasing intense. And that new programming languages have come up that address those flaws of C/C++ responsible for the vulnerabilities to exist and suggest a better approach. And this is new: for decades C and C++ were unrivaled in the system programming area. If you are running any kind of software, you can be sure there is C or C++ code in it covering the performance-relevant and close-to-the-OS/machine parts. Now there is more modern competition coming up. And both C and C++ may have their Nokia moment. Most bugs in production software are technical flaws, where the algorithms and concepts applied do work, but implementation details, lack of failure handling and other edge cases cause the program to fail. This isn't a problem of incomplete specifications or circumstances no one ever thought of. The standard use cases of software are well-tested these days. But even just with malformed input, bugs appear - monkeys can kill code. Hackers, acting on purpose, even more so. Each attack on software starts with well-crafted malformed input the attacked program fails to recognise as such. Until it hits a place in the code where the developer assumed well-formed input and applied one of those many shortcuts the dinosaurs C or C++ allow based on that assumption - system compromised. So the least you should do is: distrust input, always check that it is conformant to the spec, even if that hurts performance, fail graciously on any malformed input. That can be done in any programming language. Some enforce to do this more than others.
Excellent speaker and content!
Great talk! Thanks for sharing!
The talk starts at minute 57:00
At this level I'd just go with Rust since this is CPrustPrust
Programming SUX
This is so gross Good god I hope they never build this into the language. Just code in python or JavaScript if you want to erase your types.
This is a really good talk. The folks saying he's not fair to OOP have just not seen that the juice is worth the squeeze. We have all been lied to. OOP is not the only tool, and the others happen to be better and simpler. I've been using a procedural and data oriented approach since about 2011 and it has never let me down. It has gained performance, added readability, made the code more composable, and made it easier to test. OOP is an unfortunate detour on the way to enlightenment.
8:45 9:20 new, delete smart pointer 10:48 13:08 hide unique pointer implementation. 15:30 constructor 26:20 overload.