At the same time clang-format!!!

Till now GCC 10.1 was the best choice for this framework, now after adding this code, we'll be back to clang (even though currently clang does not support non-type template parameters which I'm planning to use).

Guess the keyword that have been troubling me for days now. Just one keyword; Its existence is troublesome, its lack of existence would require me to completely remove the mother extensions and only use the child extensions.

Renamed the .h files to .hpp files with a little bit of bash script.

And the extension system is in a better situation currently.

Allocator auto injection with C++20: the tweet!

In the framework there's a need for a logging system; I've decided to use already written logging libraries out there and put each of them in an extension so you could choose the logging library you like the most at compile-time.

But of course that may seem a little useless to have a choice in the logging library, but it will bring you even more choice because you'd be able to configure that library the way it's supposed to be configured and use it as you've always been using, PLUS, the logs of the framework itself will be done in that logging library as well. This means if you use glog or Boost.Log, the logs of the framework itself will be done with glog or Boost.Log, ...;

Of course this requires me to go and implement an extension for each of those libraries with a clear abstraction layer on top and let the framework use that abstraction layer instead of using those libraries directly.

This means you as the user of this framework will also be able to use those abstraction layer to log stuff, and that would be the correct and recommended way of logging in this framework.

But I will not abstract away the configuration part of the libraries; so if you for example want to write your logs into the system logs instead of a file, you can configure that with like you'd always configured in that library.

GCC's bug or Clang is an outlaw?

https://godbolt.org/z/aqMaEj

Okay, after successfully making GCC 10.1.0 cry over my framework, it's now time for the Clang 10.0.1.

With this little bit of code, the framework is able to find out if your route is noexcept or not and use "try/catch" to catch the exceptions if you haven't marked your route as "noexcept"; this means if you do mark your route as noexcept (witch you should always do unless that route is either in development or something like an admin page that the normal users don't have access to), then we don't waste your resources on initializing a "try/catch" (witch very very slow if you didn't already know).

You wouldn't like it if I wrote this without "if constexpr"!

What do you think? Is this a good place to use [[maybe_unused]] even though I haven't seen any warnings saying those might be unused (and should I see a warning in that situation?).

I'm pretty sure even Bjarne Stroustrup agrees with me!

Example 2 now compiles, the dev branch is merged with master branch again.

Seriously, how do I write tests for a logging system in googletest? Anyone?

Wait, Boost.Log 1.72.0 can't be compiled with C++20? (it's been fixed in 1.73.0)
https://godbolt.org/z/c49894

Come on ArchLinux, I need GCC 10.2.0 and Boost 1.73.0! Don't make me compile them myself!

If anyone asks, this is why I'm gonna implement spdlog's wrapper first before implementing boost.log's wrapper in the framework.