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?

I cannot agree that the requirement for moved-from object to be in a valid state is a mistake. Otherwise the standard must define a new state of object. Also, moving operation can be conditional, so there must be a uniform way to detect that state. All this would bring more complexity to the core language, not just the standard library.

This was very entertaining! Kudos!

Investments are the roots of financial security; the deeper they grow, the stronger your future will be."

From a didactical viewpoint, this is a disaster.

I've been doing this informally in my head for years! It's really useful to see it formally laid out though, especially because it makes it easier to collaborate with other devs on problems.

Congratulations!! Very interesting exposition about the burden introduced with move semantics on RAII and lifetime of objects, years ago when studying this I realized the same problems, and I concur it is a pity this had been implemented this way. Let's see if for cpp2 Herb fixes this problem, since function constructors are a great oportunity to consider moving to destruct the object and fix once and for always this problem.

I did a 500.000 LoC C++ project 20 years ago, very complex, real time 3D stuff with a DOM and Javascript interpreter, and it also required a lot of raw memory access to feed the graphics API, and I don't recall having these kind of problems. Used the standard library extensively, made a lot of own containers and iterators in std-library style, and don't remember having any issues with out of bound operations. Used smart pointers for everything long before it was in the standard. The downside was that I went totally overboard with c++ language features, including generating bindings for javascript, having multiple inheritance with heavy templating, data dependency management on the DOM with lazy evaluation, ultra-fast serializing and de-serializing, distributed operations, and processing audio, video inside a 3D-scene graph. When I read the code today, I am still amazed what I managed to put together, with a team of a dozen people, but it is just over-the-top in use of design patterns and language features. I think nobody but me fully understood it, and this is not a good thing. I worked, was deployed over a decade long in public-facing projects worth tens of millions, and ran reliably for months without resource leakage or crashes. But it was just too complex, I think. I even rewrote the garbage collector of the javascript interpreter. Implemented my own XML parser and DOM, type checked by XML-Schema, with all data having text and binary representation, kept lazily in sync. There was also lazy evaluation of bounding box calculation, and you could operate on the DOM and change everything, and dependencies were automatically installed or torn down with it. Pure horror in terms of memory and lifetime-management, and pure horror in complexity. I think code should not be that complex. Often simpler is better, but template metaprogramming combined with multiple inheritance is just too powerful to not make use of it, and then there are no limits in what you do. You can just cram in so much functionality that it makes your eyes bleed. Regarding writing safe and secure software, you can do that in C++ for decades already, but you have to know how and have the time and money and will to do it, and often it lacks one or more of these ingredients. Lowering the threshold and providing reasonable defaults to make C++ safer and more secure is a good thing to do, but the whole thing seems to be more a mental or political problem, and nudging people towards isn't bad, but may not be enough. However, requiring Rust for everything or turning C++ into Rust also does not seem to be a solution. Turns out, while Rust comes with impressive guarantees, it seems not well suited for game programming, and exploratory programming in general. The main problem is that you need to plan and think ahead more in Rust, and you can't easily try out "forbidden" things just to see if they work, and often you need to make a lot of changes to try small things. While it seems something that might be overcome with experience, at least one group of developers gave up after years of trying. I have not done anything in Rust yet, but I programmed in dozens of languages, and find C++ still the most versatile, and using Python to glue C++ stuff together is just great. Another aspect seems to missing: How will AI fare with C++? The good thing is that C++ provides robust capabilities to check code at compile time, and AIs seem to fare good with C++, but I did not try to use it for advanced C++ stuff. Changing the language too much might cause problem with AI software generation, but C++ is also pretty good at providing a safety net for AI coding - just something to think about. We will need the choice, but having the choice is also dangerous. This is a Catch 22. There is no good solution, but your direction seem so far ok to me. It won't solve the problem though, but it is usually preferable to have working, buggy software than no software at all, and we are fighting against this strong incentive, and I don't think we can win, we can only make an effort. Software development, even as an engineering discipline, is about mental models that are shared with a machine, and it is an art form, too, and art has no bounds. :-)

great talk! I was skeptical before I see possibility to have a separate transition table

Reference semantics for that kind of context like sort is expressive enough. Like, if my T-shirt is dirty, I want to clean my t-shirt, not copy my t-shirt, clean the copied dirty t-shirt, and when it's clean then replace it by my original dirty one. I want to clean THIS T-SHIRT, and every single little piece of code must be as closer as possible as the way we human think. Besides, if I go to a coworker, where 99% of workers focus on practical things and consider all of this kind of very technical stuff to be in the realm of nerdy obsessions, how would you convince them to change a very expressive way of writing things to a less expressive way of writing things without any actual, practical gain? It's much cheaper keeping things as simple as possible and debug the errors when they happen, than letting complexity get out of control and adding more and more features trying to patch the consequences of complexity going out of control. Making a modification inside a comparison function is complexity going out of control and THERE is where people have to attack: by teaching people that they should not do that. In my opinion some uses of references are fine, specially functions where its only mutable reference is the first argument, because we are very used to it thanks to assignments a = b.

Maybe at some point a language like "SimpleC++" might be needed, that contains only a subset of libraries and properly handles "old" code.

Wrote machine learning code using GPU+CPU on an iPhone. Optimized it so much that it started to slow down after 15 sec and a minute before the phone got overheated. That was a bit frustrating because I needed the power.

I relate to 57:00 a lot. When I use C++ it looks like someone writing python with different syntax. When I see people who complain about C++ being complicated write C++, it looks like completely unreadable code that I could not understand in a million years because it is 90% abstractions and unintuitive ways of doing things.

Why not use something like std::vector<std::variant<small_type, std::unique_ptr<big_type>, ...>>?

This is the type of talks I very much like. Not just telling you what to do or show you end result/product. But actually explaining the iterative process and design evolution clearly. Wonderful talk. Thanks.

mycolouredcircle = colour{other} << 180_degrees; In value oriented programming I see conversion operators used as getters for the intrinsic properties, along with assignment operators again for intrinsic properties. I’m assigning a position to a positionable circle: mycircle = position{0,21}; I’m expecting colour::colour(colour const& other) to call operator colour const&() on any passed in object, but currently have to use alternative constructor with concept requires obj.operator colour const&() In the past I explored writing intrinsic properties as super classes, struct vector: capacity, size, data {}; Like why write a size_t capacity(vector const&) function when I can have a capacity value, and copy construct from an intrinsic property directly. I’m thinking C++ isn’t for value oriented programming. When I get around to it I may just C++ (see more) into a new language.

Just don't put big types in std::variant, it has the 500x padding all on its own. You can put those types behind unique_ptr (similar to the small object optimization suggestion) or separate the logic for them with overloads/templates/polymorphism. Interesting points on heterogeneous containers generally though. It's not too different from the double-indirection version, with `offset` storing pointers into `array` a bump allocator

An interesting talk. But also a cautionary tale about how C++ programmers over-engineer everything. I would just have slapped the 5000 byte struct inside a unique_ptr and called it a day.

Just wrap the largest variant T in unique_ptr?

Great talk. Learned a lot. Though, so many “umm”s..

For the type/offset storage, I think it could be combined together, since you're already using bitfields for your type indices, i.e. store the type information in the LSB of an unsigned integer and store the offset in the MSB.

stop teaching me more C++ I'm already fully insane

the operator [] could return const variant, thus making assigning a compiler error. however, this could lead to unintended copies where people spell out the actual type instead of auto.

C++ people trying deparately to avoid writing C.

Personally my first choice would be a struct of vectors instead of vector of variants. No problems with alignment, minimal storage, and minimal complexity(unless there are additional constraints like keeping the "variants" ordered, but that can be solved with just an additional indirection)

Well, the "target" model presented has been around for fifteen years in many C++ build systems. You can assume people already know about this and just take time to discuss a standardized format.

great talk! quick question though: how exactly does vv::vector::visit figure out the type of the thing it's looking at? You're storing the type metadata in an array on the heap, so you can't use those runtime values to index into a type list or call the std::in_place_index_t constructor of std::variant. How do you map the runtime index to an actual type?

To avoid alignment issues, I think that we can store different types inside different vectors. I am not sure which operation will be more complex in comparison to proposed approach, but maybe something to look into..

Why not store each of the possible types in the variant in separate vectors of each type? So a vector<variant<int,double,string> ends up being a proxy object that contains three vectors: vector<int>, vector<double> and vector<string>. All the alignment issues disappear. You would still have the capacity and size issues. Iterating and indexing are a bit tricky. Still, I'm surprised that this was not one of the designs considered.

Wonder if the idea was considered to have one vector for each type. The type array would then give which array to look at. And the index instead of bytes would store the index in that specific array. That would make the internal implementation quite a bit simpler, while adding a bit more stack space. Heap storage and performance characteristics should be similar.

i prefer the syntax showed at operator= a lot more than what we have today lmao

JFYI GitHub meanwhile offers unlimited private repos

I see investors and company owners will ‘Law of Attraction’ attract big obvious reflections of their actions. If their products are full of exploits it tells me they’re exploiting people. It would therefore be a mistake to continue working for them as you’ll subconsciously express in code, reflections of their actions. Potentially being blamed, and going on a journey of invalidating yourself, a further mistake that can be optimised away. This potentially reaches deeper, customers may ‘Law of Attraction’ attract business owners who will exploit employees, subconsciously attracting and buying products with exploits and backdoors that one day help them see their unloving/untrue actions (sins), even if ignorant to them.

For online viewers, Hey Chat GPT formulate question according to answer given by Marshall Clow.

Great talk!

The functionality of sanitizers has been around for much longer than the last decade. Purify has been around since 1991 (over 3 decades ago) and Valgrind since 2002 (over 2 decades ago).

Oh man he didn't know about the "Safe C++" proposal

1:31:16 That typo in the title could have been much much worse 😂.

Why do we need to create problems, than with even greater enthusiasm try to solve this problems? Simplest possible way is NOT to use fancy macros and all IDE would be able normally navigate this code. And that code with fancy macros should not pass code review.

1:28:52 Odins other talk: kzbin.info/www/bejne/jYO3m3-Gf7mWnaM

9:16 swingdoor turnstile

8:42 Finite state machine implementation