Just so I'm clear, what this appears to be doing is the moral equivalent of a function that asks if some constant equals what we know to be its value (true at compile time)? And then at program-init time (via __attribute__((constructor(101)))) changing the value of the constant in the text section so the test is now false?

If so, that's both quite clever and something I don't think I want in my codebase :P. The good news is I'm pretty sure Daveed's proposal that you mention (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p059...) got support last time it came around EWG so I'm hoping we can just go that way.

Yes that's exactly what's happening under the hood. I'm definitely looking forward to the constexpr operator being accepted!

I discuss the approach more in depth here:

http://saadahmad.ca/detecting-evaluation-context-inside-cons...

So would a valid tl;dr be, "modify the compiled program to catch any invocations not evaluated at compile time and make them return the correct value?"

That is basically it :)

Stuff like this shows that we need to introduce even more things into C++. I am not kidding. There are still many things to improve in C++.

Luckily, WG21 seems to agree!

In README: "[...] we can choose to implement a runtime specific algorithm while having a different algorithm for doing something at runtime." Typo?

Thanks for catching that!

As with most things in C++ that looks horribly convoluted for some very simple functionality. In D all we have to do is:

* `if ( __ctfe) { ... }` for compile time

* `if (!__ctfe) { ... }` for runtime

I don't think it's any secret D does CTFE better than any other language.

Yeah it never ceases to amaze me the lengths that C++ users goto to try to do things at compile time.

Better than Common Lisp?

Does better AND doesn't require the language to be AST :)

The joke's on you, working with an AST is a treat :)

Thanks, strangely enough this comment made me read more about D and I'm genuinely excited about getting into this language now

In my libbug library, computation at Compile-Time uses the exact same language as the run-time

  {at-both-times
   {define fact
     [|n| (if (= n 0)
              [1]
              [(* n (fact (- n 1)))])]}}

  (pp {at-compile-time-expand   (fact 3)})
  (pp (fact 3))

https://github.com/billsix/bug

Why to mlock() the page? And since the code is already specific to linux/gcc/clang, why not to assign the flag to a read-write section (__attribute__((section(name))) -- should allow to get rid of mprotect()?

Typo detected :)

"An approach for runtime dection inside a constexpr function"

https://github.com/SaadAhmad/in_constexpr

Thanks!

Another reason why we should not be using c++...