@mhoemmen mdspan feature request 😉:
Allow mdspan::operator[] with one argument less than rank.
Mandates/Constraints: The resulting range is contiguous in memory.
Returns: A span (of static extent, if possible).
Then I can use std::simd CTAD from range:
simd::basic_vec(B[k], simd::flag_aligned);
instead of:
simd::unchecked_load<simd::vec<T, N>>(&B[k, 0], &B[k, N-1], simd::flag_aligned);
The former is not only simpler but also safer.
The first part of std::simd just landed in #GCC 16: https://forge.sourceware.org/gcc/gcc-mirror/commit/8be0893fd98c9a89bbcd81e0ff8ebae60841d062
Expect it on Compiler Explorer in — I guess — 12 hours.
This implementation differs significantly from the std::experimental::simd implementation. One goal was a reduction in template instantiations wrt. what std::experimental::simd did. Design notes: - bits/vec_ops.h contains concepts, traits, and functions for working with GNU vector builtins t...
What's the constexpr-if equivalent to `condition ? x : y`? As far as I know we only have `[&] { if constexpr (condition) return x; else return y; }()`. I hate it.
Can we fix the following inconsistency in #CPlusPlus: https://compiler-explorer.com/z/qsYeTncE4? A conversion operator is sufficient to call wrapped function pointers. But it does not work for wrapped callable objects. And that's even though `wrapper` in the above example has the callable type in its associated namespaces (ADL). ADL was introduced to make operators work. I patched my #GCC to make it work and I like it.
template <typename T> struct wrapper { T value; constexpr operator const T&() const { return value; } #if 0 constexpr decltype(auto) operator()(auto&&... args) { return value(args...); } #endif }; int f1(int); auto f2 = [](int x) { return f1(x); }; int test1() { return wrapper{f1}(1); } int test2() { return wrapper{f2}(1); }
I wrote a #WG21 Kona 2025 trip report:
https://mattkretz.github.io/2025/11/13/WG21-Kona-2025-trip-report.html
After the CD (committee draft) is out, WG21 is in bug fixing mode. Consider NB comments as the tickets that force us to consider a resolution and provide an answer. Such issues can either be design issues or wording issues (where wording does not match stated design intent). Besides NB comments, many library issues had been filed and prioritized independently, which led to several categorized as must/should fix before the standard is finalized.
Last week meant survival mode. Attending the #WG21 meeting in Kona, Hawaii *virtually* meant Zoom sessions from 19:00–04:00. With family in the house, some of them sick, my priority was 1. not getting sick 2. getting the work done. So no 🏊🚴🏃 last week.
1/1
C++は常に進化している！ C++26・C++23の新機能と今後のトレンド
https://qiita.com/Sakai_path/items/24537a84c2437e9e527f?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
I read https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2025/p3802r0.pdf "Poor Functions" last night. I jumped for joy! 😆 Finally, I had words for what I was thinking all this time. This __local_ctx idea puts into words what I wanted to say with regard to #FunctionMultiVersioning (https://gcc.gnu.org/wiki/FunctionMultiVersioning). I need to be able to reflect on those attributes in order to make SIMD types and functions behave correctly in the context of FMV. __local_ctx producing a std::meta::info sounds like the solution!
Matthias Kretz | Vir
Qiita - 人気の記事