Web++: A C++ Web Framework
My types are not long enough. I should work on that! 😁
I successfully made the errors longer. 😂
Web++: A C++ Web Framework
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).
Even though GCC 10.1 is not able to compile the dev branch of this project now due to the internal compiler error, the clang 10.0.0 is able to compile it like a normal compiler :)
Forwarded from The Moisrex
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.
And the extension system is in a better situation currently.
Twitter
The Moisrex
Convert all of .h files in your git repo into .hpp files. while IFS= read -r file; do git mv $file ${file/\.h/.hpp}; done < <(git ls-files | grep -E "\.h$")
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.
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.
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).