Відео

Type Eraser video with different title. Same video uploaded..

Fedor! Good to see him still do presentations.

Nice!

Always love talks by Fedor Pikus.

It's PIMPL!

C++26 is most certainly not the first to use compile time value reflection. E.g. Zig.

How is std::meta::info handled across ABI boundaries ?

Runtime reflection is just always a security and architectural problem in the end. It is only "nice" to get thing working quickly.

Nice talk, but I got a feeling this was partially inspired by ASIO, would be nice if presenter or somebody from audience addressed that point.

Nice talk

👏🏼

Every product deals with user information because that is a second form of rarevenue that make it a companies want to sell. A robotic vacuum cleaner now transmits its images to a server that is not the consumer. The washing machine now send your data to the manufacturer that they sell to third parties and it's all in the user licence agreement. The language is not the problem. Buy defaults, Smart tvs opt you in uploading your user data to the manufacturer. Every smart phone record your text envoice and send it to whoever you have your smartphone with. Your modern car keeps all your text messages, And who knows what else in they cannot be deleted. The boogie man is to blame the programmer, Select let's see how safe we can keep getting the languages.

This was an incredible talk. I didn't even watch it on UA-cam because I was there live. Lucky you who is reading this - you're in for a treat.

Verifying all the 128 bit floats are correctly converted into base 10 is possible. It would "only" take 6min * std::numeric_limits<uint64_t>::max(). So just about 2.10439e+14 years. Or 0.210439 quintillion years. Easy with a bit of patience.

How is it that every time I tell my colleagues (working as an embedded C++ dev) "Hey guys, we have this repeatedly occurring design problem in our applications. You know what? I will write this super cool, heavily templated library that will get the job done in a unified way with a nice declarative syntax" there is this talk later *the same year* given by someone from Intel's embedded team where the prelegent says "You know what? We had this repe... So we've written the library. Here it is. Pick it" :| That was the case with cib, message library and now with groov. I absolutely love seeing such an approach in my beloved domain that is still swimming in the sea of 90's C-style souls! <3 P.S. Aren't you looking for a dev? :p

Thanks for this excellent presentation. I don't know if enough people in embedded systems appreciate this paradigm's value, independent of language or implementation, so any visualization of its application in the field is a service to the community. Any firmware developer will be exposed to the design/architecture forces between schedule efficiency, modularity of components to be scheduled (down to the lowest level drivers), and reasoning of concurrent behavior. Every project I worked on was affected by exactly the issues Michael mentioned in the presentation, even if we considered them early on. If an RTOS is off the table (for whatever reason), it looks like this approach solves a huge part of the design space for systems that manage a lot of async behavior without dropping a lot of control. I hope the quality of code generation and compile times will scale with the problems thrown at it. Another question is how well one can reason about the global schedule timing across all execution contexts, given that with "senders", they are composed of locally specified use cases.

Got lost in the first 5 minutes and never recovered😢 huge respect to those who understand what this is about!!! Just use Questdb as your timeseries db and shove that CME data stream into it and call it a day.

Wow, I watched for an hour and just realized it was released on UA-cam only an hour ago.

How is someone supposed to debug code written in terms of SnR? the standard version of the logging example is way more readable and comprehendible that the SnR version.

One of the best talks on topic I've seen, highly reccomend!

Great talk! Thanks Michael!

Is this library open source or planned to be?

Excellent presentation 👍🏽 Note that personally I would have said that "sender factories" are the event generators, not only schedulers (which are also sender factories)

Wait I had totally expected senders and receivers to be, exactly what senders and receivers are in every other language (channels). Why has C++ decided to take a concept and name it the exact same as some other, well established in other languages feature? That sounds like crazy land to me. Also, why are senders and receivers looking like futures and promises in combination with coroutines in this talk - and more importantly - why are we needing *another* one of those systems? These senders and receivers also look _identical_ to kotlins coroutines (or Rust's coroutines/async). Why has C++ decided to muddy the waters this bad when we have multiple large userbase languages with these features but they aren't called senders and receivers. From what I can tell, *many* languages has senders and receivers yet *none* of them look like coroutines like this. Am I wrong about this?

Great talk.

Look at Zephyr Zbus.

I remember watching a seminal talk by Michael Caisse about Boost.ASIO when I was getting started with C++ and programming in general. This talk has the same charm. Thank you.

Thr pervasive use of C++ at Goolge is why so many postmortems have been written by SRE over the years. Throw it in the tashcan where it belongs and use modern safe languages like Go and Rust for your backend micrroservices.

Senders/Receivers is apparently preferring structured concurrency.

<13% -> >50% ? ? ?

I like the idea of splitting Co and Future.

Interesting ideas but not a fan of the closed api. This is all to support his cancelation and the cost is it not working with thirdparty awaitables. Well maybe he has an await_transform in there? Idk, but I think coroutines coolest part is the open api.

Great talk with some deep knowledge sharing, and makes me more hopeful for broader use of co-routines! (Jacobs sure seems to be :) ) Making `Co` non-moveable and having a separate Future that takes values seems to be a great way to solve the parameter lifetime issue. The event wait/notify appraoch (delaying the work-stealing to the next suspend) and the cancellation approach (like an exception was thrown when co_await-ing) keeps things neat. Also, he constant theme of stack frame elision is brilliant Overall, a bunch of ideas that it seems every coro library should take note of! Also, several examples of weird concurrency that comes up when having lots of users...

Coroutines and job systems complement each other beautifully.

OK, but what about Rust?

Please be in C++26

Asking people to admit to having written code that has led to a 0-day exploit is always going to have a response rate of zero, just like pilots would never openly admit to doing dumb things when flying an aircraft.

ua-cam.com/video/_T1XjxXNSCs/v-deo.html

Having listened to tens of hours on reflection I feel this brilliant talk has finally brought me closer to beginning to be on a path to starting to understand the road to reflection in c++ ! Thank you! ❤🙏

Fun lambda talk, thanks for sharing. :D

The "is this a complete class" problem already exists in C++20 with concepts. It can lead to ambiguous situations where one compiler claims a concept is true and the next one tells you it's not.