Show HN: C++ runtime/compile-time detection in constexpr functions (github.com)

I discuss the approach more in depth here:

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

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

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.

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

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

Typo detected :)

"An approach for runtime dection inside a constexpr function"

https://github.com/SaadAhmad/in_constexpr

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

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

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()?