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.

GCC 10.2.0's reaction to my code :)

Am I making this channel like TikTok, wait Microsoft? 😅


Hmm, wait I made it with Instagram which is owned by facebook.

I don't know what I made 😅😂

You and me both GCC 10.2.0!

Seems like GCC 10.2.0 doesn't support "consteval" yet; it confuses it :)

I hat to convert all of the constevals into constexprs to make it work in GCC.

With enable_traits, I'm able to use allocators and loggers easier in the:
- context
- requests
- interfaces including CGI, FastCGI, and Self-Hosted
- other places that need access to allocators or loggers

I don't know why I didn't do this sooner.

I just spent practically 2 days trying to re-implement std::tolower and std::toupper. Benchmarked so many versions.
Tried multiple versions that were written with SIMD and yet the simplest version came out on top after GCC and Clang optimizing them.

And here are the benchmarks.

And here are some twitter fellows helping me failing at topping the easiest for loop ever written :)
https://twitter.com/the_moisrex/status/1307670297911402497?s=20

Now we know how horrible some of the utilities in the STL are. Well, of course std::tolower and std::toupper do have locales but that's what I don't need in this project; at least not now.