วีดีโอ

A flat map is only fast to build if you use emplace_hint() with an ende-iterator and the new elements are always right.

Is there any book, documentation, anything that explains this code for newbies other than the source code itself? How many people understand this code, so foa real?

C is "trust the developer" model, while Rust is "trust the compiler". Only the former results in auditable code. The latter means the code's validity depends on the compiler's version, which is all but a safe practice!

this is nice. Does anybody know what this font is

The most clear explanation of co-routines yet!

Very interesting

This is brilliant. The topic is as low level as it gets in C++ and yet it is so beautifully explained.

Wow -----

Great talk as always

I think it's worth being clear about a couple things. 1) This bug will definitely be fixed eventually. It's slightly embarrassing that it's been open for so long, but part of the reason for that is that 2) it's almost impossible to accidentally trigger this bug. The copy-pasted code is quite hard to follow, and I wouldn't be able to reproduce it from memory even if you paid me to try :) In contrast of course, the same mistake in C++ is one we all make the first week we learn about pointers.

Why hasn't clang a warning for this simple dangling cases? It would be on par with rust "safety" and help sometimes.

sublime presentation, one of the best i've seen for a long time

That is a pretty long-winded way of saying: uninitialized memory contains garbage and freed memory might still expose your old data.

Just have the OS or some security service clear data after an app closes.

When talking about topics which are not that trivial, try to avoid using 'uh' and 'ah' every 5th word, this could easily lead to undefined behavior.

Thank you so much for sharing this great stuff.

3:12 Walter Brown’s talk: th-cam.com/video/Am2is2QCvxY/w-d-xo.html

awesome content, thank you so much

Quick note about @8:24. Since the zero and one case return an int, this function will always return int, which probably isn't the intent.

peace to all my coding brothers

Brilliant talk, thank you very much for sharing. Great production quality, learned loads of interesting stuff, and I'm inspired to to learn more. Very nice gilet as well!

The other talk I mentioned: th-cam.com/video/dFIqNZ8VbRY/w-d-xo.html The font is Berkeley Mono. The animations are all done in Keynote.

Extremely helpful, thank you.

The best talk ever. Detailed explanation where it should be detailed and short when it needs to be short. 10/10. In a couple of years this talk will be a sensation. Bravo.

I like this very unique and interesting presentation format. Very nice, much appreciated.

Even though i knew the topic well, this was a great video and i shared it with my son for his enrichment.

Don't want to be that person - but what specifically from this talk was about optimizing a high performance library? also please stop using high_resolution_clock

Nice

43:54 [slide 61] as long as we’re specifying some of the defaulted templates arguments - I’d comment that I’m very fond of using std::less<void> instead of std::less<T>.

41:17 [slide 57] another concern when choosing between std::map and flat_map is iterator-invalidation. Unlike flat_map - iterators to std::map (and std::unordered_map) stay valid if new elements are added or if other elements are erased. Great talk, Pavel!

It should be noted that these benchmarks are only useful for those that don't want to shop around for a better implementation nor are they willing to write their own. The real benchmark test is for a completely custom implementation which attempts to balance allocation strategies and take hints from the user on an estimate for the number of elements. The best general purpose allocation strategy that I've found for in-memory allocation is to double the capacity each time the memory grows. This means that the larger the container is the less often it will allocate and move the contents. However, there are times when you want to use more of a deque approach and again, it depends on the data being stored and how it's being accessed. I do find it funny that certain container types have taken this long to make it into the standard library because I've been using similar structures in my own code for decades now, but written in C. I've done a lot of experimentation with hash tables and as far as I've seen, the performance when implemented the correct way is better than the theorized performance whenever people show the big O notation. Also, I'm pretty sure the chart for insertion/removal into/from a vector is wrong. It should be O(M) as it depends on where the element is being inserted or removed. Only those elements that have a higher index will need to be moved if no allocations take place, and in cases where an allocation occurs all of them will need to be moved.

Great talk but the zoomy-in-out camera effect tends to cause motion sickness

Great talk. In 49:45 note that if await_suspend() returns void (or true) the control is returned back to the “regular stack” (resumes the non-coroutine function on the top of this threads’ stack). The distinction is relevant for ‘symmetric transfer’ which Jonathan deliberately skipped, in which one coroutine can resume another, and if the latter suspends via void-returning in await_suspend we’ll not get to the caller-coroutine)

Densely Packed information

45:49 Nico Josuttis on the danger of range views: th-cam.com/video/qv29fo9sUjY/w-d-xo.html

41:19 Herb Sutter’s taxonomy: th-cam.com/video/ARYP83yNAWk/w-d-xo.htmlm41s

13:01 Peter’s talk from ACCU 2022: th-cam.com/video/LDiLF33j8UA/w-d-xo.html

Cool videos

The vulnerability is caused by the users visiting certain pages directly in the browser and also the page not redirecting those visitors back to the pages they came from

Can udb help you find backdoors in running code?

Thanks a lot for such a great tool

Yes, I want to become a C++ Master too! From this day forward, I will devote myself to becoming a C++ Master as the primary directive of my life, to study C++ as if my life depends on it, because it really does, this is my career after all! I have a desire to deeply understand and learn C++ and related topics in programming. For that I am living an ascetic lifestyle, removing all distractions completely. Focusing only on my programming, no any extra things.

11:07 I believe the “special trick” mentioned is to specialize std::coroutine_traits<wrapper> for the coroutine-wrapper type

6:38 Roth Michaels’ CppCon talk: th-cam.com/video/oxnCdIfC4Z4/w-d-xo.html

I liked this presentation very much, you should always strive to express yourself in code. Only that you blame iterators not supporting a semantic you added, i believe is questionable. But this were the means getting the audience attention. :) Thank you very much.

You are a legend.

tl;dr: Views and ranges which remove and/or change the order of elements create ill defined borders if a classic iterator is used to point to the left or right of it (e.g. upper_bound()). Iterators should be separated into two distinct concepts: borders and elements. Elements can be nullable instead of .end(), borders are well defined and symmetric (begin() and end() reference-able) ... it sounds like a nice idea. There are some details to work out regarding how borders would be invalidated if the collection was mutated, but it sounds like a useful paradigm.

I identify so much with this topic as I've intentionally only ever bought low power hardware. I've never owned a discrete graphics card, for that matter. You're 100% correct when you say that not everyone has an ideal situation because even living in the best state in the US, I still get power outages here 5 or more times per year. It's the reason I have a UPS or two in every room in the house with electronic devices and why I recommend others do the same. As far as comparing against other languages, I personally prefer C to C++ and use it far more, and for nearly every personal project I've done I have chosen it. That said, I still also regularly use C++ and try to keep up to date with my knowledge of it. Part of why I would recommend that website you mention is because it tells you useful information such as when a given construct has been available as standard in the language, such as telling you "since C++11", but also it has an entire section for C as well. Towards C++, I would definitely agree that it, just like C and other system level compiled languages, allow you to optimize better than interpreted languages and for lower power hardware such languages are a must. I applaud the standard committee's efforts towards concepts like constexpr and consteval because they will definitely help in that regard and I applaud the work of compiler developers in implementing them. I would also argue that if you write idiomatic C++ that it is just as memory safe as other languages pretend to be and it is incumbent upon the developer to learn all of the tools and how to use them, such as open source software like `valgrind` which do a far better job than a program like `rustc` at analyzing memory usage and finding bugs. I used to hate C++ as a language, but the more new languages that kept popping up really made me appreciate so much more about it as a language. However, I will never stop adding a `using namespace std;` at the top of my C++ source files and eschew the ridiculous overuse of `std::` that so many developers do these days. Don't want name conflicts, don't use standard names in your own code.

Having made an attempt at implementing just the basic container types some 25-ish years back, I can tell you that you definitely don't want to start from scratch, especially in the current day. Also, I still say that std::map::operator[] shouldn't insert new keys. Implementing all of the C standard library was significantly easier back then, and even today is still significantly easier than the C++ standard library. If anyone is taking advice, unless you're willing to spend years on it, don't try to design and implement your own programming language, especially if you expect it to be a useful systems programming language. It is beyond annoying, although, from my own experience, consider using some sort of compiler construction tools or generating an IL such as what LLVM uses instead of writing the entire thing from scratch like an insane person.

36:39 By the way, in C++23 we also got std::basic_const_iterator which can potentially assist library developers implement their own containers and range adaptors. Great talk!