Web++: A C++ Web Framework
I wonder what this __builtin_memcmp is! If it's a good algorithm, sure; but I don't like having to use std::char_type::compare for std::string::operator==, I think there are better ways. We don't need to check the whole strings to know they're not both the…
My twitter thread about this: https://twitter.com/the_moisrex/status/1254142556029452289
Twitter
The Moisrex
Now instead of reading documents, I read implementations. Now I need to implement a whole bunch of stuff just to create a faster case-insensitive equal operator for string types. Of course I don't have to; but I want to!
Oh come on,
Now I have to either create two distinct cookie classes, one for request and one for response, or go through the hassle of creating a templated one which will require some template madness in order to make it more optimized for the request header since cookies in request headers don't have as many features as cookies in responses.
Also responses have two different header names for cookies: one
Now I have to either create two distinct cookie classes, one for request and one for response, or go through the hassle of creating a templated one which will require some template madness in order to make it more optimized for the request header since cookies in request headers don't have as many features as cookies in responses.
Also responses have two different header names for cookies: one
Set-Cookie and one Set-Cookie2 which is deprecated for some reason. Thank GOD!This media is not supported in your browser
VIEW IN TELEGRAM
Changing the whole structure of the cookies class.
1hour and 36mins in 28 seconds.
2020-04-26 06-31-30
1hour and 36mins in 28 seconds.
2020-04-26 06-31-30
This media is not supported in your browser
VIEW IN TELEGRAM
Changing the basic_uri signature to match the traits templates.
But I have so much of the implementation that I have to change too.
2020-04-26
But I have so much of the implementation that I have to change too.
2020-04-26
Media is too big
VIEW IN TELEGRAM
Converting the rest of the
I think I need to make the whole library a header-only library. By introducing
basic_uri, and adding a few useful features like a faster version std::to_string with help of std::to_chars which not clang nor gcc has it fully implemented yet even though it's a C++17 feature.I think I need to make the whole library a header-only library. By introducing
traits, I've been converting every function/class that requires strings of any kind.My implementation of
std::to_string with the help of std::to_cahrs.std::to_string because it's using locale, it's at least 6 times slower than std::to_chars.Media is too big
VIEW IN TELEGRAM
A time-lapse that will require a 10 more time-lapses just undo what I was trying to do!
I'm re-designing the whole idea of valves in the project. The final result will have more power than the current idea of valves in the webpp project.
I'm re-designing the whole idea of valves in the project. The final result will have more power than the current idea of valves in the webpp project.
This media is not supported in your browser
VIEW IN TELEGRAM
Developing broken ideas!
New ideas are coming for the routing system.
New ideas are coming for the routing system.
The new routing system:
Problems this system will solve compared to the valving system:
- The migrations now can access the context
Previously it was possible to implement this through some ways but
the problem was that the whole thing was based on requests and
responses, which meant that we couldn't pass other objects and types
without modifying the request and response types which adding a new
parameter into their template parameter lists only introduced more
complexity for the library users
Other ways we could've solved this issue:
- Using virtual inheritance for requests
Would've added unnecessary indirection
- Using self made vtable
Would've added unnecessary indirection
- Using void* type or similar ones and cast them later
Would've added unnecessary indirection
- Passing a context object to the migrations/valves to solve this
Which would've introduced complexity because at that point the
requests and the responses were not retrievable from the context.
- The valves are not aware of the requests and other details provided
by the context.
Previously this was an issue since the valves were only capable of
checking if the request is a match for the valve or not and they
couldn't modify the response or even stop the request or provide
information for the migration.
- A better constexpr way of passing valves and migrations to the router
Since the valves and the migrations were a separate entities which
they would become one entity after creating the "route" template
class, it was a problem to create a nicer looking route by the user.
- Using valves as validators and validators as valves.
Using valves as validators are now easier since the user doesn't have
to create a constexpr variable and use that variable in both the
.on method on router and inside the migration.
Now the whole thing is inside the context, and it'll be passed to the
valves/migrations by reference.
Of course using validators as valves require a bit of a hack from the
user but there's just no other way and honestly it's easy enough to
do so!
Route types:
- Entry routes
- Sub routes
Definitions:
- Route: Possible ways that are capable of handling user requests
- Entry Route: The main routes that will be checked first
- Sub Route: The routes belong to the each Entry Routes
- Context: An object of arbitrary type that will contain everything
that routes will need including:
- Request
- Response
- Previous entry routes context changes
- Previous sub routes context changes
- Original entry routes level context
- Original sub routes context changes
Features we need:
- [ ] Extendable entry and sub routes
- [ ] Use class operator() as a place to add more sub-routes
- [ ] Having access to the context class in the callables
- [ ] Having access to the request and the response
- [ ] Termination of continuation of checking the sub-routes by parents
- [ ] Termination of continuation of checking the entry-routes by any
previous routes, or sub-routes.
- [ ] Context modification
- [ ] Sub-Route local context modification by any previous sub-routes
- [ ] Inter-Entry-Route context modification by any previous
(sub/entry) routes
- [ ] Entry-Route prioritization
- [ ] Auto prioritization
- [ ] Manual prioritization
- [ ] Hinted prioritization
- [ ] On-The-Fly Re-Prioritization
- [ ] Dynamic route generation / Dynamic route switching
Usage examples:
-
Problems this system will solve compared to the valving system:
- The migrations now can access the context
Previously it was possible to implement this through some ways but
the problem was that the whole thing was based on requests and
responses, which meant that we couldn't pass other objects and types
without modifying the request and response types which adding a new
parameter into their template parameter lists only introduced more
complexity for the library users
Other ways we could've solved this issue:
- Using virtual inheritance for requests
Would've added unnecessary indirection
- Using self made vtable
Would've added unnecessary indirection
- Using void* type or similar ones and cast them later
Would've added unnecessary indirection
- Passing a context object to the migrations/valves to solve this
Which would've introduced complexity because at that point the
requests and the responses were not retrievable from the context.
- The valves are not aware of the requests and other details provided
by the context.
Previously this was an issue since the valves were only capable of
checking if the request is a match for the valve or not and they
couldn't modify the response or even stop the request or provide
information for the migration.
- A better constexpr way of passing valves and migrations to the router
Since the valves and the migrations were a separate entities which
they would become one entity after creating the "route" template
class, it was a problem to create a nicer looking route by the user.
- Using valves as validators and validators as valves.
Using valves as validators are now easier since the user doesn't have
to create a constexpr variable and use that variable in both the
.on method on router and inside the migration.
Now the whole thing is inside the context, and it'll be passed to the
valves/migrations by reference.
Of course using validators as valves require a bit of a hack from the
user but there's just no other way and honestly it's easy enough to
do so!
Route types:
- Entry routes
- Sub routes
Definitions:
- Route: Possible ways that are capable of handling user requests
- Entry Route: The main routes that will be checked first
- Sub Route: The routes belong to the each Entry Routes
- Context: An object of arbitrary type that will contain everything
that routes will need including:
- Request
- Response
- Previous entry routes context changes
- Previous sub routes context changes
- Original entry routes level context
- Original sub routes context changes
Features we need:
- [ ] Extendable entry and sub routes
- [ ] Use class operator() as a place to add more sub-routes
- [ ] Having access to the context class in the callables
- [ ] Having access to the request and the response
- [ ] Termination of continuation of checking the sub-routes by parents
- [ ] Termination of continuation of checking the entry-routes by any
previous routes, or sub-routes.
- [ ] Context modification
- [ ] Sub-Route local context modification by any previous sub-routes
- [ ] Inter-Entry-Route context modification by any previous
(sub/entry) routes
- [ ] Entry-Route prioritization
- [ ] Auto prioritization
- [ ] Manual prioritization
- [ ] Hinted prioritization
- [ ] On-The-Fly Re-Prioritization
- [ ] Dynamic route generation / Dynamic route switching
Usage examples:
-
.on(get and "/about"_path >> about_page)
- ( get and "/home"_path ) or ( post && "/home/{page}"_tpath ) >> ...
- opath() /"home" / integer("page") /
- empty / action_list("action", {"open", "delete"}) >> []{...}
- (...) >> &non_templated_class_with_templated_callable_operator
- get and "/profile/"_tpath and set_by_class_constructorSome how I'm gonna be implementing the strategy pattern in my routing system too.
https://twitter.com/joelnet/status/1256229458295619585
https://twitter.com/joelnet/status/1256229458295619585
Web++: A C++ Web Framework
Some how I'm gonna be implementing the strategy pattern in my routing system too. https://twitter.com/joelnet/status/1256229458295619585
I'm gonna call this a different name though. Strategy pattern doesn't suits it.
Any of these represents the intent more efficiently:
- Parsed value generation pattern
- Data passing pattern
- Data controlling flow
- Context passing
I like the Context Passing since it matches with the above routing system I'm about to design.
Let me know in the @webpp_discuss group if you have a better name for it.
Any of these represents the intent more efficiently:
- Parsed value generation pattern
- Data passing pattern
- Data controlling flow
- Context passing
I like the Context Passing since it matches with the above routing system I'm about to design.
Let me know in the @webpp_discuss group if you have a better name for it.
You can find another one hour and half video of me working on the project here:
https://www.aparat.com/v/gay0q
https://www.aparat.com/v/gay0q
آپارات - سرویس اشتراک ویدیو
سی++: تبدیل کوکیها
در این قسمت سعی دارم تا کوکیها رو با ایده traits مچ کنم.
This media is not supported in your browser
VIEW IN TELEGRAM
First stages of implementing the new routing system idea.
This media is not supported in your browser
VIEW IN TELEGRAM
I just found out that I've been mistakenly recording the live coding video with this image on top of everything. 😂
@webpp
@webpp
I find happiness in finding bugs in IDEs. 🤣
https://twitter.com/the_moisrex/status/1257796596726726658?s=20
https://twitter.com/the_moisrex/status/1257796596726726658?s=20
Twitter
The Moisrex
I'm so proud of C++20 for letting me to be creative like this: