Live data from Hacker News

Lisp-style C++ template meta programming

github.com

1–10 of 18 posts

Re: Lisp-style C++ template meta programming

#7
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.

Re: Lisp-style C++ template meta programming

#8
post #5

if this is a C++17 library why couldn't you use `constexpr` evaluation and not murder your compilation time?

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.

Re: Lisp-style C++ template meta programming

#9
post #8
post #5

if this is a C++17 library why couldn't you use `constexpr` evaluation and not murder your compilation time?

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.

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.

Re: Lisp-style C++ template meta programming

#10
In my grad school days, a couple of decades ago, I had written a library for my own use to facilitate chaining of different kinds of numeric operations on data vectors and sequences. Essentially, for a very simple form of deforestation [0,1], equipped with intermediate buffers to facilitate SIMD.

GCC, surprisingly, was quite good at generating SIMD code from it and eliminating temporary data vectors. GCC was even quite good at explaining why it didn't emit SIMD that I wanted it to emit. Much to my surprise GCC was better in this regard than Clang. From what I had read about Clang at that time, it should have been the otherway round. The error messages were better too (wonders of competition).

I quite liked it. It was a loads of fun. I would however be wary of using it in anger.

The problem is, this sublanguage feels more like a dynamically typed language where errors would be thrown deep in the instantiation chain when it ultimately failed to instantiate.

There was no type-system to guide you ahead-of-time that what you are trying to do would eventually fail to instantiate.

The code got lost when Bitbucket stopped it's support for Mercurial. I still likely have it somewhere in my old files.

Later I wanted to rewrite this in D but never started (thrown out of my university because I graduated).

[0] https://en.wikipedia.org/wiki/Deforestation_(computer_scienc...

[1] https://en.wikipedia.org/wiki/Expression_templates

Post reply on HN