Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp-style C++ template meta programming

github.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Lisp-style C++ template meta programming

#11

Post by ahartmetz »

jjmarr wrote: post #9
mistivia wrote: post #8

Earlier quoted context omitted.

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.

Always has been (I'm over 40). It used to be a nightmare of a programming language, now with all the improvements over time it's merely quite bad. Its power to weight ratio is below any reasonable standard, but sometimes you need the power. Some lunatics like to play with it.

Re: Lisp-style C++ template meta programming

#12

Post by uecker »

This is very cool. I had a lot of fun doing C++ template meta programming two decades ago and the language got a lot more interesting. Just realize that you can waste a huge amount of time without anything doing remotely useful.

(And please don't use any of it in any professional context.)

Re: Lisp-style C++ template meta programming

#13

Post by ahartmetz »

srean wrote: post #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 qui…

It is pretty well known that C++ templates really are dynamically typed, it's compile time duck typing.

What you did sounds like Eigen, which probably takes expression templates much further than you did due to the long time it's been around. It is weirdly absent from its documentation, but Eigen does have explicit SIMD support for several architectures and SIMD instruction sets. https://libeigen.gitlab.io/

Re: Lisp-style C++ template meta programming

#14

Post by srean »

ahartmetz wrote: post #13
srean wrote: post #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 qui…

It is pretty well known that C++ templates really are dynamically typed, it's compile time duck typing. What you did sounds like Eigen, which probably takes expression templates much further than you did due to the long time it's been around. It is weirdly absent from its documentation, but Eigen does have explicit SIMD support for several architectures and SIMD instruction sets. https://libeigen.gitlab.io/

Yes am familiar with Eigen. And yes I am/was that lunatic you mention in your other comment.

This thing I wrote, predated Eigen (by a few years, I think) had a better support for pipelines and dataflow oriented programming (at least in the context of what I needed) than Eigen. It was more like itertools, functools of Python. Likely older than Eigen but positively after Blitz++ because I remember studying Blitz++ code.

Unlike Eigen, mine had no explicit support for intrinsics, for that I relied on a smart enough compiler, GCC was surprisingly good.

Too bad MSVC was quite bad at optimising and inlining away to the expression trees that Eigen (and mine) generated.

Re: Lisp-style C++ template meta programming

#15

Post by djmips »

This shows you how fun, useful and fascinating C++ template meta programming can be but also the dark side as a perfect example of inscrutable code that can be a real pain when you run across this sort of thing in production code with no documentation.

Re: Lisp-style C++ template meta programming

#16

Post by mistivia »

jjmarr wrote: post #9
mistivia wrote: post #8

Earlier quoted context omitted.

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.

I've add exmaples of a toy EDSL and compile-time reflex in C++17 in GitHub readme, which wouldn't work with constexpr only.

Re: Lisp-style C++ template meta programming

#17

Post by tug2024 »

srean wrote: post #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 qui…

[dead]

Re: Lisp-style C++ template meta programming

#18

Post by gpderetta »

> This is not something you would use in production

Ages ago in C++98/03 era, cons based lists were the only way to do type lists or tuples, so solutions like these did see some production use (and yes, it did kill compile time).

Of course these days variadics have made these solutions obsolete.

Post reply on HN