[DSMan195276]

As someone who doesn't do much C++, could `constexpr` actually do this all on its own? My (limited) understanding of `constexpr` would lead me to think that using it alone you couldn't generate the contents of the array like this. IE. You could define a `constexpr` function to calculate a single entry in the array, but you'd still need to call that function for every entry. In this case, it looks to me like the bulk of the macros here are just to condense declaring the large array by using nested macros to repeat the computations and expand to a large number of array entries.

That said I absolutely don't disagree with you at all. It's really a bit silly C doesn't have it at this point. `gcc` will happily do all of this math for you at compile time even if you do as much of the math as you can in `static` functions. But to make it compile you have to declare `pixels` in `main` because you can't call the functions in the initializer for file-scoped variables - even though the compiler can already optimize them out.

[jcelerier]

> As someone who doesn't do much C++, could `constexpr` actually do this all on its own?

yes, some people have written entire constexpr raytracers for instance : https://github.com/tcbrindle/raytracer.hpp

[nickodell]

Everything above and including #define C1 returns a single value, and therefore could be done with constexpr.

More to the point, constexpr would be a heck of a lot more efficient - changing M4 to M5 increases the preprocesed size from 80 MB to 240 MB. This is an exponential increase, despite that a Mandlebrot pixel can be computed in linear time. (Linear to the maximum number of steps.)

I suspect that this is because if you write a macro and use your macro argument twice, this doubles the length of whatever your macro argument was.