👉 Life advises from the creator of C++:

1. Don't over specialize
2. Don't be too sure that you know the future
3. Be flexible
4. Remember that careers and jobs are a long-term thing: Too many young people think they can optimize something and they find they've spent a couple of years or more specializing in something that may not have been the right thing and in the process they burn out because they haven't
5. spent enough time building up friendships and having a life outside computing: I meet a lot of "junior geeks" that just think that the only thing that matters is the specialty of computing, programming, or AI, or graphics, or something like that and, well, it isn't and, the rug might be pulled under them for that; and if they do nothing else, well
6. if you don't communicate your ideas you can just as well do Sudoku: You have to communicate and a lot of sort of caricature nerds forget that. They think that if they can just write the best code the can change the world; but you have to be able to listen, you have to be able to communicate with your would-be users and learn from them, and you have to be able to communicate your ideas to them. So you can't just do code you have to do something about culture and how to express ideas and I mean I never regret the time I spent on history and on math; math sharpens your mind, history gives you some idea of your limitations, and on what's going on in the world, and so,
7. Don't be too sure.
8. Take time to have a balanced life.
9. Be ready for the opportunity: I mean a broad-based education of odd-based skill-set, which is what you build up when you educate, you're patiently building a portfolio of skills, means that you can take advantage of an opportunity when it comes along; you can recognize it sometimes, we have lots of opportunities but a lot of them we either can't take advantage of or we don't notice. It was my fairly broad education, I've done standard computer science, I've done compilers, I've done multiple languages, I think I knew two dozen at the time, and I have done machine architecture, I've done operating systems, and that skill set turned out to be useful.

constexpr is the most used keyword in this project! 😅

For every piece of code I write for this project, I have to read a bunch of half-written article, read a bunch of open source projects' sources, watch probably watch a bunch of youtube videos which end up being useless most of the time!

For every step forward I take in this project, 10 new rabbit holes show up that need enormous amount of research.

But I do learn a lot doing this.

io_uring is the new way of doing async I/O in Linux, it supports linking requests, meaning you can put a flag on each IO request so it would do them in the same order instead of, you know, asynchronously.

Imagine you have one file and you want to open, write, read, and finally close it; in io_uring if you do it without the flag, it would do them in random order, meaning you might close the file first, then read it, then write to it, which it's errors all over.

So, the question is this: WHAT WOULD BE THE BEST API FOR DOING THIS CLEANLY IN C++?

1. I could do a flag, which is what liburing already does.
2. I would be great if I could automatically sync IO operations on the same file but io_uring's API (the flag) is required to be placed on the previous request not the request that supposed to be synchronized.
3. Functions with "sync/linked/..." in the name?
4. ...???

An article about io_uring's Linked Requests

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!

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.

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.

Oh God, I'm making a WEB FRAMEWORK; I SHOULD NOT be doing assembly! 😩

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!

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 extern "C" or extern "C++"es



Some 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.

I like bit manipulating!

2023-10-14: Working on web++'s scheme parser of the URI parser.

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.

I like my bits manipulated 😁

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:

» 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.

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