If you're in the business of doing the "constexpr all the things" shenanigans like me, then you'll end up inventing words in commit messages like "deconstexpring", "deconstexprifying" and "constexprification" like me!
Web++: A C++ Web Framework
๐ Life advises from the creator of C++
Media is too big
VIEW IN TELEGRAM
๐ Full Interview with creator of C++
When you use non-standard compiler extensions, I'll get headaches!
All these little things that Linux developers add while thinking "oh it's Linux-specific library, we don't need to support any compiler other than GCC", makes things harder for people like me who are trying to port to other languages/platforms/... .
Please stop using compiler-specific features unless you're handling it correctly.
All these little things that Linux developers add while thinking "oh it's Linux-specific library, we don't need to support any compiler other than GCC", makes things harder for people like me who are trying to port to other languages/platforms/... .
Please stop using compiler-specific features unless you're handling it correctly.
I never thought that someday I would be writing operator&; but that's the cost of wanting a C++ compatible C library!
๐1
Web++: A C++ Web Framework
Here's me doing it again; re-implementing what's already implemented just because I'm writing a header-only library and C++ doesn't have an standard and good package manager.
Somewhere during re-implementing this sh*ty library, I f*cked up; and now I'm trying to triple debug my way out of this self-dug hole!
๐ฅด1
For Web++ I needed to have header-only C++ compliant version of liburing, so I've forked it and did that.
There are still some UBs and Compiler-Specific stuff that I need to sort out, but right now it's a drop-in replacement.
I would like to have liburing's repo itself to host the header-only version of this as well so both header-only and future versions of liburing can be packages in one repo and grow together; but there are non-compatible changes in the header-only version which CAN be managed but not merged directly.
It's
- Header Only
- No Undefined Behaviors
- Standard compliant (No compiler-specific features)
- pedantic friendly
- C and C++ compatibility without any
Some of the changes so far:
- removing of all
- moving the implementations into
- removing
- doing `
- using
- adding
- adding
- Casting
- added
- using
- Using
- Provide missing values on construction on initialization
- Adding some
- Assembly changes:
- C++ can't do the return technique used for calling the assembly codes, so I changed the assembly macros in a way that they fill a variable named
There are more small changes as well, and I have probably created a few problems as well, but I hope I can fix them.
Here's the link to the fork containing the changes said above.
Here's the issue link, that's me trying to see if I can merge this fork into the original repo.
There are still some UBs and Compiler-Specific stuff that I need to sort out, but right now it's a drop-in replacement.
I would like to have liburing's repo itself to host the header-only version of this as well so both header-only and future versions of liburing can be packages in one repo and grow together; but there are non-compatible changes in the header-only version which CAN be managed but not merged directly.
It's
- Header Only
- No Undefined Behaviors
- Standard compliant (No compiler-specific features)
- pedantic friendly
- C and C++ compatibility without any
extern "C" or extern "C++"esSome of the changes so far:
- removing of all
.c files- moving the implementations into
liburing.h
- adding static inline to their definition- removing
configure script- doing `
compat.h` manually without needing to be generated- using
KERNEL_VERSION and LINUX_VERSION_CODE for feature detection and fallback instead of relying on configure script- adding
liburing-hdr-only.h for clear distinction between header-only and original version if required by the user- adding
noexcept pretty much everywhere :smile: - Casting
- added
uring_static_cast and uring_reinterpret_cast
- trying to use io_uring_start_lifetime (not fully done yet)- using
io_uring_next_void_ptr in order to do void pointer arithmetic in an standard way- Using
nullptr instead of NULL (with fallback of course)- Provide missing values on construction on initialization
- Adding some
consts here and there, and moving declarations of variables from beginning of the functions to their first use.- Assembly changes:
- C++ can't do the return technique used for calling the assembly codes, so I changed the assembly macros in a way that they fill a variable named
ret and then we can use that while using the macros.There are more small changes as well, and I have probably created a few problems as well, but I hope I can fix them.
Here's the link to the fork containing the changes said above.
Here's the issue link, that's me trying to see if I can merge this fork into the original repo.
Media is too big
VIEW IN TELEGRAM
2023-10-14: Working on web++'s scheme parser of the URI parser.
๐ฅ3
Media is too big
VIEW IN TELEGRAM
2023-10-15: Continuing to work on the URI parser.
Recorded using asciinema, replay with 50x speed.
The whole thing is in terminal using neovim with SpaceVim installed on it.
Recorded using asciinema, replay with 50x speed.
The whole thing is in terminal using neovim with SpaceVim installed on it.
โค3
Did you know you couldn't use hex numbers as IPv4 octets, but you kinda can? In WHATWG compliant URL Parsers, it's a warning, not an error:
ยป
ยป
You already can use this in your browsers, you can write
Also
ยป
http://127.0.0x10.1
is same as:ยป
http://127.0.16.1
I don't agree with this decision though, and also it messes up my error handling ideas that I had in mind, but ...!You already can use this in your browsers, you can write
http://0x7F.0x0.0x0.0x1, you'll get http://127.0.0.1/.Also
http://0x7F000001 is going to be http://127.0.0.1 as well.๐ฅ3๐คฏ2
C++23's [[assume(...)]] fallback looks like this.
And it only took me something like 50+ browser tabs to figure this out ๐
Source on Github
And it only took me something like 50+ browser tabs to figure this out ๐
Source on Github
๐1
Web++: A C++ Web Framework
C++23's [[assume(...)]] fallback looks like this. And it only took me something like 50+ browser tabs to figure this out ๐
Source on Github
I updated this just a bit to add
P.S.: 30+ more tabs got opened as well to get this update ๐
New source code on Github
Test: Godbolt Link
constexpr support as well; I WENT OVERBOARD, I think ๐
.P.S.: 30+ more tabs got opened as well to get this update ๐
New source code on Github
Test: Godbolt Link
๐1
Updated my C++ implementation of the Javascript encodeURIComponent and decodeURIComponent functions; it's now faster.
๐ฅ1