This is still all unvalidated work.
For all I know it might cause your computer to burst into flames,
grow an arm and a leg and an eye, and attack you with a sword.
But probably, it will just not work and I will realize that sleepy
past me was a fucking idiot (as always).
The former is finally some progress on getting NBT going,
though at this point it is all unvalidated work.
For all I know it might cause your computer to burst into flames,
grow an arm and a leg and an eye, and attack you with a sword.
But probably, it won’t do that and instead start working after I
have debugged it so much that I wish I could attack my PC with a sword.
The latter is the implementation of a change I prepared in a previous commit
when i added ErrorOrVoid.
Doesn’t compile on Void x86_32 glibc. This will need to be investigated.
I just wanted to get rid of the errors while working on other issues.
Compile command:
ccache g++ -std=c++20 -Wall -Wextra src/tools/hexnet.cpp -I./include -Lbin/lib -l:cli.so -l:libsockpp.so -o bin/tools/hexnet
I stumbled over this when writing the unit test. Previously, it would return
an error code but explicitly mark it as not being an error. This was intended
behavior but I decided to change it because I didn’t anticipate it when writing
the test.
Technically `ErrorOr<T>` can be used to pass any message alongside `T`,
but practically, it is reasonable to assume that the error code is
`ErrorCodes::SUCCESS` when `isError` is false. Therefore, this feature
should be really only used in the weirdest edge cases - if at all.
Even then, it is most likely still preferable to flag it as an error and
just hand the resulting `T` back using the long constructor
`ErrorOr<T>(bool, uint8_t, T)`.
I tried dealing with lists in the same way as with other more basic tags
but came to the conclusion that this is most likely not feasible in the same
way that it is not feasible for compounds. It would require a mini-parser
that can deal with all sorts of tags (including nested lists and compounds).
Instead, an approach more similar to the recursion for compound tags will
be used (using its own function to deal with the missing tag headers ofc).
The prefixes were part of a planned feature but since a connection is
either IPv4 or IPv6 but never both, it would have been completely useless
to specify which to use. Instead, only TCP and UDP will need to be specified.
Idk why I did that in the first place. Probably bc hpp looks stupid.
But having a + in a file name bugs me just as much. And other ppl as well.
So I changed it.
I renamed "unpositional arguments" to "options" and "positional arguments" to "arguments".
This is intended to make the code more readable and easier to type out.
Multithreading will be needed to simultaneously receive and send data.
The preparations include:
- move all the settings of the program into global scope
- add mutexes
- move the code that reads from the TCP socket into a dedicated function
The parser used to rely on the next iteration of the loop to detect
if an unpositional argument was missing its value, this has now been
fixed by adding an additional check on unpositional arguments waiting
for a value that detects if the end of the loop has been reached
This is the entire reason I build lib/cli in the first place:
Parsing arguments directly in a given program tends to get really messy,
not to mention all the different ways that arguments can be specified
and the redundant work required to do that on multiple programs.
- argumentWaitingForValue was never reset after the value had been retrieved
- made it so the ArgumentsParser constructor can accept const char**
- correct usage of substr() and actually use the correct position in the first place
- fix a typo where I tried to dereference `this` with `-` instead of `->`
test/nbt_helpers: add a headline to output
Build system: remove comma from array that I added bc I thought it was correct sytax, it wasn't
lib/cli: change argument order of PositionalArgument constructor to fit in with Flag and UnpositionalArgument
lib/cli: properly define what is private and what is public in the ArgumentsParser class
This should be all functionality that is needed for now.
The next step is building unit tests to check that everything works correctly.
Who am I kidding? There will most certainly be bugs in there given that this
code has been typed out without ever being run.
This allows ErrorOr<T> to be used for bool, as there would be conflicting
constructors otherwise.
Also, we have ErrorCodes::UNKNOWN now so, instead of `ErrorOr<T>(true)`,
`ErrorOr<T>(true, ErrorCodes::UNKNOWN)` can be used.
Shwoomple