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