Rendered at 09:55:04 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pjmlp 2 hours ago [-]
While cool for those stuck in C++17, which are plenty given the C++ version of "can I use", C++26 should make many of these approaches more easily available.
However it is still a few years away to be widely deployed, and a few niceties have been postponed into C++29.
jjmarr 3 hours ago [-]
if this is a C++17 library why couldn't you use `constexpr` evaluation and not murder your compilation time?
mistivia 2 hours ago [-]
Template metaprogramming isn't really suited for this task, the prime sieve here serves only as a proof of concept, meant to show the capabilities of this style. But there are cases where `constexpr` is not applicable, especially when involving type manipulations.
On the other hand, C++ template metaprogramming, as an esolang, is fun to tame and experiment with.
jjmarr 2 hours ago [-]
Is there a clearer example where constexpr wouldn't work?
> On the other hand, C++ template metaprogramming, as an esolang, is fun to tame and experiment with.
Is it an esolang at this point? I feel old.
pjmlp 2 hours ago [-]
I imagine because some of the cool constexpr improvements are only available in C++20 and C++23.
ahartmetz 5 hours ago [-]
That could be pretty cool, I wonder what it does for compile time though.
4 hours ago [-]
alex_dev42 4 hours ago [-]
Good point about compile time. Template metaprogramming can definitely impact build performance, especially with recursive template instantiation.
From what I've seen in the repo, this approach might actually help with compile times in the long run. The Lisp-style syntax could enable better template caching and memoization strategies compared to the nested template<template<...>> patterns we usually see. Plus, cleaner metaprogramming code means developers are less likely to write deeply nested recursive templates that blow up compile times.
Would be interesting to see some benchmarks comparing compile times for equivalent functionality written in traditional C++ template style vs this approach.
However it is still a few years away to be widely deployed, and a few niceties have been postponed into C++29.
On the other hand, C++ template metaprogramming, as an esolang, is fun to tame and experiment with.
> On the other hand, C++ template metaprogramming, as an esolang, is fun to tame and experiment with.
Is it an esolang at this point? I feel old.
From what I've seen in the repo, this approach might actually help with compile times in the long run. The Lisp-style syntax could enable better template caching and memoization strategies compared to the nested template<template<...>> patterns we usually see. Plus, cleaner metaprogramming code means developers are less likely to write deeply nested recursive templates that blow up compile times.
Would be interesting to see some benchmarks comparing compile times for equivalent functionality written in traditional C++ template style vs this approach.