New Features in C++26(lwn.net)
lwn.net
New Features in C++26
https://lwn.net/Articles/979870/
11 comments
I love how the comments section quickly goes into "better fast benchmark winning code with surprising unexpected side effects" than "working code that is fast enough".
Why? If you're the kind of guy who thinks his code is "fast enough" (pro tip, it actually isn't) you're already coding in Javascript, not C++.
Pro tip, learn to use a profiler.
I did, it said the Javascript interpreter is slow. Check and mate.
And this is just the "small stuff". C++26 might land reflections, std::execution and contracts in one go - which would make this mighty
to me at least, hazard pointers and rcu seems to be the major changes, for library authors anyways.
i would actually wager that rcu in and of itself is almost at par with atomics and the memory-model :o)
for folks wondering about 'hazard-pointers' this paper https://web.archive.org/web/20171104135736/http://www.resear... is quite useful as an excellent starting point.
i would actually wager that rcu in and of itself is almost at par with atomics and the memory-model :o)
for folks wondering about 'hazard-pointers' this paper https://web.archive.org/web/20171104135736/http://www.resear... is quite useful as an excellent starting point.
The Template pack index is going to make
meta-template variadics much easier.
Usually this is prone to cludges like converting
parameters to structs or filtering them with functions holding the pack.
Reading the example:
I wonder why it's T...[0] and not just T[0]? In parameter lists you need the distinction between "T", a single parameter of pack type, and "T...", multiple parameters supplied from the pack. But I don't see a similar need in an expression.
template <typename... T>
constexpr auto first_plus_last(T... values) -> T...[0] {
return T...[0](values...[0] + values...[sizeof...(values)-1]);
}
1. typename...
2. sizeof...
3. values...
4. T... representing multiple parameters in the formal parameter list.
5. T... for the type of the pack (supporting T...[0], the new feature).
I wonder why it's T...[0] and not just T[0]? In parameter lists you need the distinction between "T", a single parameter of pack type, and "T...", multiple parameters supplied from the pack. But I don't see a similar need in an expression.
I think for types you could do without the dots in T...[0], but it mirrors the usage for values (values...[0] is different from (values[0]...). So consistency I guess.
[deleted]