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!
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.
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.
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 >(); ```
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.
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
*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!
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.
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. ✅🧻
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.
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.
