I see a lot of spam coming from sendgrid, so I wonder how long they can continue operating that way until they get blocked completely by one of the larger mailbox providers.
see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r2.html#enabling-hardening
Much like a freestanding implementation, the way to request a hardened implementation is left for the implementation to define. For example, similarly to -ffreestanding, we expect that most toolchains would provide a compiler flag like -fhardened, but other alternatives like a -D_LIBCPP_HARDENING_MODE= macro would also be conforming.
I wonder if it would be possible to build such a tool on top of tree-sitter (although not sure tree-sitter's C++ grammar can handle modules yet)
at least you could keep their reviews so users could at least know if the app can be trusted.
You mean, don't trust a flatpak uploaded by a random person, but if there are enough fake reviews, it can be trusted?
No mention of Reflection which was passed to the Core Working Group for wording review, or senders/receivers (on the library side) which was actually voted into the working paper.
Huh? There is no such alternation between new features and feature freeze releases. In fact, C++26 will very likely get reflection as a major new feature. In comparison, the biggest core language feature in C++23 was probably "deducting this (explicit object member functions)".
The only thing that keeps Contracts out of C++26 is that they might not be finished in time (they'll need to be handed over from Evolution to Core by the February 2025 meeting, and then make it through Core review during the summer 2025 meeting).
Can anyone explain why there is such a huge difference in some of the benchmarks: Poll, Forking, CPU Cache, Semaphores, Socket Activity, Context Switching (all Stress-NG). Can we really trust these tests?
Depends on what semantic you want. Sure, if you use a unique_ptr member, you will get a deleted copy constructor/operator - I wouldn't consider that blowing up in my face.
And even the presented fix hurts my eyes. Should have used a unique_ptr or optional.
Yes, it's not Open Source, but I am not sure that's really relevant here. I see it more as a prototype implementation for something that could be standardised for C++.
Is anyone still using them?