I added a github page:
https://the-moisrex.github.io/webpp/

Why C++?

Even though C++ practically runs the web and you can see C++’s steps every step of the way that your request goes, from your browser to web servers, people still think that C++ is not a good language for web development. It may have been true for a long time; but in the modern C++, we think C++ is one of the best languages that can help you make the best websites and services.

C++ is good for web development because:

- It’s as fast as a language can get
- It doesn’t let you make stupid mistakes that a static analyzer can catch
- It can be run in unsafe environments since you don’t have to share your source codes
- Has access to every corner of the operating system
- Has access to hardwares like GPUs
- It can put life into the old codes
- You can run un-safe codes if your job depends on it :)
- Your web app doesn’t have be re-run every time a request comes, it can remember everything
- Your website can be used in small IoT devices
- You can share your website’s binaries and let the users run them in their own systems without sharing your sources
- It can run other languages; other languages use web servers that are written in C++ after all

I mean, C++ is already running the internet, it’s a shame not to take over the web services too :)

A few ideas about the recent Herb Sutter's talk about pattern matching.


I have a few ideas about "as operator" mostly:

1. as concept
2. as auto
3. as template
4. as value


1. as concept
I would like to be able to do this:
variant<int, string> obj;
auto i = obj as integral;

because in general coding, there are plenty of places where the variant's types are not trivial to retrieve and check.

2. as auto
for when we've already checked it with "is" operator and we don't need to repeat the type. Of course it would work only when there's one overload for as operator.

3. as templated type; Template parameter deduction
For example in a json parser that the object or array type is a template:
doc["obj"] as object
Instead of:
doc["obj"] as object<allocator_type>

4. as value
I'm not sure if it's already possible or not, but having an enum value or an index would help.



My tweets about this: https://twitter.com/the_moisrex/status/1455440196246425604?t=Tru-XKNsIZqM-gcvVYdRMw&s=19

RapidJSON Wrapper's basic functionality's tests are now passing.

As you can see in the screenshot, we now can do lots of cool stuff already.

You can follow the JSON wrapper state in these two issues:

RapidJSON Wrapper
JSON API

I'll be shifting my focus on other parts of the project now.

Here's is_specialization_of that can support non-type-template-parameters as well.

The source

I've got minimal JSON support now. I wrote a big wrapper around RapidJSON (which I now think I should've started with Boost::json) so I can later add more wrappers for popular json libraries. This way, my users can choose between the underlying json library and don't have to re-learn a new one just because I chose it for them.
Unfortunately the maintainers of RapidJSON are not as responsive as I like them to be. They're very slow; at least in my little experience I had with them.
Which json library you like to use in webpp?

Now we have a working boost::beast implementation as a protocol. Even though there's still a few bugs I have to fix before it's actually usable but it's looking good 👍

Checkout the progress here: https://github.com/the-moisrex/webpp/issues/67#issuecomment-1048779739

Currently implementing a .ini config file parser and writer and generator. I'm using the mINI project as the initial source code. I have to change that project because:

1. It's not using allocators
2. Namespace
3. Coding Style
4. Doesn't match my initial thought on how it should be
5. Doesn't match the C++20 concepts that I need to match the other config file types.

More info: https://github.com/the-moisrex/webpp/issues/85

Okay, I've got the basic LRU Cache working so far. Plenty of work to be done including:

- Making Parent Storage Gate work.
- Implementing File Gate
- Implementing common cache algorithms
- Adding Expired LRU and other Cache Strategies.

Storage Gates:
These are the ways that the cache can be stored. For example, in memory with std::map, or in a JSON File.
These also can have a parent storage, for example our memory cache can have a file cache as a parent which it means if the memory is not enough, it'll use the parent cache instead of removing it.


Cache Strategies:
These are the ways that the cache is strategiezed. for example, LRU is the Least Recently Used and will remove the caches that you haven't used much. But there are other strategies, for example we could have a strategy that will remove the caches based on the time of access.

Let me know if you're interested in implementing these with me. It's gonna be pretty fun.

Cache Directory:

In process of implementing caches in webpp project, I can now introduce "directory cache". It lets you store each key/value pair in a file of its own inside a specified directory.
This cache directory is a "Storage Gate" and thus witch conjuction with a Strategy, you can get more useful stuff out of it.

Example of cache names:
16780311998597636082-16780311998597636082.v1.0.0.cache
4939359993625789802-3.v1.0.0.cache
4939359993625789802-1.v1.0.0.cache
4939359993625789802-4.v1.0.0.cache
4939359993625789802-2.v1.0.0.cache
4939359993625789802-5.v1.0.0.cache

Don't worry, each part of the name is there for a reason.

We've got name of the cache at first (hashed)
Then we've got the hashed key (using std::hash not md5 or other hasing functions)
Then the version of the directory_gate
Then the extension (which is customizable)

Next step I need to work on the "cache" type itself and make sure that it implements all the needs of the final user (you hopefully).

And also I need to implement Parent Storage Gate. Parent gate is a Storage Gate that gets passed to another Storage Gate as a template type. This way, we can for example do this:

We can have a memory_gate<directory_gate> which essentially means I want to store my caches in memory but when the memory is not convinient, I want them to be backed up or stored as files.

I was looking into Sphinx, ReadTheDocs, Pandoc, and even man pages to see which ones are the best for me.

Now I'm thinking, instead of writing the the whole thing in a different formats and weird syntax and even let other websites access my github repos... I just don't want all of these. I want something simple, that everybody can afford.

So maybe I thought why not my own website and I use my own webpp framework to make it, and then I thought, well, I don't want to pay for that just yet (I probably will though).

So now I'm thinking why not add a feature to the webpp that instead of CGI, and Boost, I make something that generates all the website.


Implementation Choice:
There are numerous ways I can make this happen:

1. Making a new Protocol in webpp
2. Adding it to the SDK that goes and runs all the routes and generates the html files.
3. Convert the back-end website into a front-end webassembly website.

A new Protocol
Writing C++ code just to produce html static files seems way too complicated.


In the SDK
The second one seems like it's already implemented by wget and other tools that recursively traverse the website and save and change the links.
Maybe I could do that in a much better way?


As a webassembly website
Since I haven't yet started adding features for front-end, I'm not really sure how hard it is to implement such a thing. But it's an amazing idea actually.

See the disscusion on GitHub.

With this, you can pass concepts as a template parameter easily.

Source code on Github
Example on Godbolt

I changed the license to MIT.

Should I change the license to BSL? What do you think?

A sign that tells me I should write more tests now, but I want more features instead 😅

Here's a couple of days of me working on this project using Termux on Android. I've got 3 months of these now.

I've been recording them using asciinema and what you see above is merely a replay of them.

alloc_deleter in boost smart_ptr is not move assignable,
thus std::unique_ptr<T, alloc_deleter> is not,
thus variant<..., unique_ptr<..., alloc_deleter>> is not,
thus vector<variant>::emplace(iter, ...) can't move stuff around!

Should alloc_deleter be move-assignable?

The tweet