Thank you for this fantastic presentation. I have been working with C++ for 28 years yet this talk has clarified a few things. We never stop learning. I've been developing as a hobby, a simple language that will become part of a graphics application. It's somewhat like Pascal in It's feature set and runtime conceot, but it uses C syntax. I've been working on optimisations in the compiler and handling divide by zero and casting, etc. Very timely. You have a new subscriber :)

Funny how they focus on memory safety for security I am old enough to remember Java being labeled and promoted as memory safe and it ended up being filled with more serious security issues

php, but also flash!

There are no large scale projects in rust for a reason It's hard make design changes later in the code Rust is good for rewriting small projects and solved existing code

Excellent, eye opening, love it

I am deciding to learn c++ in my free time, right now things look fun, i liked the demonstration of the C++ core rule in this talk although i don't understand a lot of things right now. I know it's going to be a tough road but hey, I think it's worth the run

Very nice talk. But the guy who is clearing his throat and smacking his lips into the microphone very annoying. I couldn't finish because I was really annoyed

I have a small problem with ranges for which the end value is not inclusive. Same as Python, IIRC. IMO, that's horribly wrong and confusing. Of course, that's just my opinion. I guess some will feel smarter.

Doesn't Intel TBB support a powerful flowgraph computational model? It even supports data parallelism and not only task parallelism. So how does TaskFlow excel compared to oneapi::tbb? If it is only for the "ease of use", I believe the steeper learning curve for TBB comes from its generality and feature richness.

In my book, this guy is a legend!

I am fedor’s biggest fan

First thing that I wonder if is ordering important? If not do something like Boost.PolyCollection. Second idea is that you actually want a free list inside your storage, so you may be able to make the [] work through a proxy with O(1), since you would append at the end if the no gaps are available. Third idea is to have variant that dispatches from stack to heap storage based on sizeof(T), e.g. string, int, double will be stored inline, but big_object will be wrapped in unique_ptr.

Thanks for this talk. The main topic on how decisions around the properties of moved-from objects lead to performance deterioration and weakening of invariants, potentially leading to logic errors, is very interesting, and I enjoyed the presentation a lot. I do have problems with the arguments around safety put forward here around 22:40 though, and I worry that this kind of thinking will just contribute to force companies like ours into security-related compliance issues and eventually off C++. Yes, highest performance needs to ditch garbage collection, bounds checking, unnecessary initializations, and safety-related runtime checks. The way the design philosophy of C++ is put forward in this talk is a perfect rebuttal of Java, but to me it misses the mark as an answer to the very real current issues around security vulnerability rates, and as an answer to (sorry to mention it) Rust. Disclaimer: I'd much rather continue using C++ than Rust, for many reasons, ecosystem being the biggest one. So I need a good answer to Rust from the C++ committee. First, playing down memory safety is not a good answer. Recent literature says that lack of memory safety is behind about 1/3 of CVEs, and a good portion of severe ones. Second, pointing to "culture, training", and the existence of things like ".at()" for bounds-checked access is not a good answer. If it were, why do we still have all of these vulnerabilities, and why does Bjarne Stroustrup decry the fact that many C++ programmers write thinly veiled C and don't make use of safety features available in contemporary C++? Third, insinuating that a language like Rust is immature ("trendy new") is not a good answer when it is 14 years old, with a mounting track record that it really does eradice memory-safety related vulnerabilities. It's also difficult to argue via performance, since Rust is cut from the same fabric as C++ and gives you no bounds checks, no zero-initialization, even Null or void pointers for good measure, and consequently all the same optimization potential as C++. It just "hides the sharp knives in the drawer", as Herb Sutter likes to say. And turns out you can do quite a bit without these knives: Sean Parent himself stated that a safe Rust implementation of the executor in Adobe Software Technology Lab's concurrency library came within ~15% of the C++ implementation a year ago, and he deemed pushing this down to a few percent very possible back then. The whole "this is C++" argument seems to ignore these realities. I fear that this mindset contributes to the rejection of proposals "Safe C++" in favour of profiles, which I expect to be ignored for old codebases just as "Safe C++" would be ignored, since profiles will also very likely require code changes, and will do too little for newer codebases to dodge compliance issues a few years down the line. The irony is that arguably there is another "this is C++" argument in favor of uncompromised backwards compatibility, leaving us with the not so uncompromised performance of std::regex and std::unordered_map forever while rejecting proposals such as epochs which could give us a path forward. Nevertheless, very interesting talk!

👍cool 👍

12:55 its either not correct or unclear. TEST will update some flags. specifically ZF (zero) and SF(sign). and CMOVG will only be executed with both are not set. basically it will be only executed if size is greater than zero otherwise zero will be returned.

I am very grateful for the wisdom you share with us.👍

This didn't age well - google just demonstrated you can REMOVE some UB and add bounds checking to container accesses and incur hardly any penalty.

I hate it when moments like 7:20 happen, is it really necessary to stop the host to make a comment just to show off you knowledge? C'mon this is high school behaviour..

Nice.

I liked seeing the Law of Demeter at 30:03. I just kind of realized that myself a couple months ago writing Haskell code: I had written a function that performed pretty deep pattern matching, and worked fine - but when I added some features, I had to refactor it into functions that each pattern matched only one level at a time. It was better code! In particular, if you have a Haskell list, it's probably a good idea NOT to write functions that pattern match [Foo] for some particular Foo: write a function that takes a Foo only, and use some kind of map or fold to apply it to your [Foo] list. Now I have a name for that idea. I hadn't really given it a name: I had expressed it to myself only as "A function should not generally take, or branch on, the value contained inside of a particular instantiation of a parametric type: it's better to compose a parametric function over the parametric type with a function that deals with the particular type it's been instantiated with". Law of Demeter is a decent name for that.

Usual crowd of know-it-alls with unwelcome contributions -- clearly unsettling Fedor. I do wish they wouldn't. It may be collegial but its bad for posterity on the videos! Perhaps the comments should be edited out? I do like Fedor's talks though. Excellent exposition.

Yes

That's why I chosen C++

nice

Clojure mentioned.

when I see fedor pikus I know it’s gonna be good

Wait a minute. Louis said "dereferencing a null pointer is UB but it's not a safety issue because it crashes." But that is not true. Optimisations can remove null checks because they expect you never write UB. We are constantly told that UB can do anything. Ergo dereferencing a null pointer can be a security issue.

Thanks for the talks but I don't agree some parts. 1. compilers are optimized out ub not because they can but because the standards allows. So that means that compiler does know what is ub or not. So either compiler can generate error for that or the as-if rule should be updated so that the compilers cannot optimize out the ub. In ideal world, ub doesn't happen but it is not an ideal world. There will be ub code. to optimize out these parts can create hidden bugs which is causes a lot of issue. 2. UB is not a some hidden power, it is actually weaknesses of the C++. Especially not so senior developers. For the ideal language, they may be unspecified behaviour which can be changed from environment to environment but there shouldn't be any undefined behaviour. There are couple of reasons for that. First, if all programmers will do the same thing to prevent the ub, then this ub should have some defined variables. Think about uninitialized variable cases. if a variable is not initialize -> it can be optimized out -> so there should not be any uninitialized variable -> so all programmers must initialize these variables. If all programmers somewhat initialize any variables, then it is logical to add zero initialization. Second, UB sometimes create hidden bugs. I understand that there should be some unit test, etc but again, we are not an ideal world. And as you mentioned in memory safe language, "the believe that the use of memory safe language create buggy application and kills the people". This argument is also valid for UB. so why we have UB then? One possible answer is that the program should have unit test/static analyzer to prevent ub. then the same argument is also applied in memory safe language. then why cpp doesn't have the memory safe feature? Did you get it?

interesting, but seriously: the syntax sucks and it's just another imperative language, with no real concept of memory safety. I don't like Rust either, but at least it has a certain right to exist with affine types and borrowing...

He's basically listing many problems, that Rust solves. I.e., accessing a moved object, is not possible in Rust at compile time. Overflow, underflow and division by zero, is checked in Debug mode, but not in Release mode.

are the haswell systems you tested that show no slowdown when running across numa nodes patched for memory leak vulnerabilities?

Man, this man is officially saying what everybody thinks. It's really not easy anymore to find (good) C++ developers. It's an incredible complex language with many foot guns!

The amount of logical falacies used was ... beyond measurement. Java has been with us for 29 years and C# - 22 years. But, obviously, for C++ to have a chance, we must all forget about these completely unknown languages and ecosystems. Also, I winder, does the speaker uses safety belts in his car? They are proven to not work above some speeds, while preventing almost all injuries bellow t0 km/h. By his logic, they are completely useless because ... That's the C++ way. Also, the tooling outside of the C++ ecosystem is way way way way way better. Also, we know that we cannot know what "a+b" actually works. With the preprocessor, operator overloads, and sufficiently advanced template magic, "a+b" can launch a LLM, which generates a command in ancient Egyptian to a REST api of fhe USA military force fo launch a nuclear strike. Or, you know, add a and b. And of course, let's not forget that C++ is completely undeadable, and significant parts of a c++ program is not busy expressing business logic but placating the compiler or working around language deficiencies. std::move, anyone? In what sane language this is needed? And this unreadability hides bugs. And prevents creating actually working tools, such as the ones the memory safe languages have been enjoying for decades. And last but not least, the C++ compiler has been doing math and all sorts of magic calculations since forever, the idea that "it only cares about types" is blatantly false. But, again, unless we outright lie, we cannot weasel ourself out of the increadible badness of that cursed language.

This is absurd, seeing UB as the language’s super power is crazy when it is the thing that will ultimately destroy the language and cede the ground to Rust and other memory safe languages. The problem with C++ isn’t performance above safety, the problem is that there are no safe options easily available. For example, in many cases numerical overflow may not be a concern, but when it is, a huge burden is put on the developer to deal with it. Putting code in something like of ‘safe’ and ‘unsafe’ blocks allows the programmer to clearly indicate what they want and when they are willing to take the performance hit, this still sits with the zero overhead philosophy. Adopting easily opted-in/opted-out safety is as important as performance to the future of the language.

8:08 “the index operator is unsafe because of performance […] in a loop you don’t need bounds checks”. But shouldn‘t one use iterators instead? then you’d have `vec[i]` being checked and slow, `vec.get_unchecked(i)` being verbose, fast, and unsafe, and iterators being fast, elegant, and safe.

im really excited about carbon tbh.

Thanks Dmitry. This is a tough topic to talk about. Very informative.

I am not sure if it was accurate because when no Named Return Value Optimization (NRVO) applied, it means in return statement a copy of 'a' will be created in a return statement and then that copy will be considered as the return value and if copy elision applies since C++17 , then that template return value will be created where 'x' and before C++17, it might elide or might not! Not sure if Jon was correctly demonstrated! In fact, he made me more confused! I think he kind of confused copy elision with NRVO!!!

I am not sure if it was accurate because when no Named Return Value Optimization (NRVO) applied, it means in return statement a copy of 'a' will be created in a return statement and then that copy will be considered as the return value and if copy elision applies since C++17 , then that template return value will be created where 'x' and before C++17, it might elide or might not! Not sure if Jon was correctly demonstrated! In fact, he made me more confused!

As someone who makes a living teaching C++ - there goes the conflict of interest. You can have performance-heavy options while making safe the default. But you can't acknowledge that because it's literally a challenge to your bottom line which depends on C++ being more complicated than it needs to be.

Nondestructive move semantics chosen by C++ are not a performance improvement - they're a performance degradation that introduces unnecessary branching in the destructor code and redundant execution of destructor code because it has to execute for moved from objects even when there's nothing to destruct. It clearly violates the "performance above else" principle, rust's move semantics are more performant. It's very funny that C++ programmers became so deranged as to find themselves doing reassuring chants. "This is C++!". C++ doesn't have to care about safety. Programmers don't have to care about C++. You're free to stay in your bubble, just don't expect everybody else to also be a luddite. Just don't cry when your language can't be used anymore for safety-critical industries and applications. No more mars rovers in C++.

A documentary about Sherry’s great book: kzbin.info/www/bejne/nHuTiWuIhLKGi9k

cool

Good talk, I liked it

30 minutes still bla-bla...

Cool story, wish the camera didn't have seizures though

There is a Bug in slide 37. If void operator(void* ptr) {d_(static_cast<T*>(p))} is done then with smartptr_te<void> widgetPtr = smartptr_re(new widget(), [](auto p){ delete p; }) above "widgetPtr" will be called for d_(static_cast<void*>(p)) which is not correct. Real type erasure is deleter function with whatever param as such will be templated and stored internally at COMPILE time. No lazy cast while invoking the deleter. IMO. GCC have a test static_assert(__is_invocable<_Deleter&, _Yp*&>::value, "deleter expression d(p) is well-formed"); _Yp is of type widget and not Void.

Avoiding tax is a virtue, not a sin.

yey for POD messaging! especially in embedded. There is a reason why embedded people love C. They know what they are doing.

Seems nice, but where is the link?