The existing timestamp parsers already internally keep track what parts
have been parsed via an index variable. This change exposes this
information as it can sometimes be useful to know what parts were actually
present in the timestamp.
See note in comment; concrete example of build error (when building
syncthingtray against qtforkawesome built with CMake 3.24.0):
```
CMake Error at plasmoid/lib/CMakeLists.txt:15 (find_package):
Found package configuration file:
/usr/share/qtquickforkawesome-git/cmake/qtquickforkawesome-gitConfig.cmake
but it set qtquickforkawesome-git_FOUND to FALSE so package
"qtquickforkawesome-git" is considered to be NOT FOUND. Reason given by
package:
The following imported targets are referenced, but are missing:
qtforkawesome-git
```
On 32-bit platforms `std::size_t` is just 4 bytes big which is not enough
to handle large data sizes. Using `std::streamsize` would likely be most
appropriate but switching signdness is likely not the best idea for
compatibility and it would mean a comparison with different signdness
because the buffer size is still `std::size_t`. So using `std::uint64_t`
now.
* Use auto
* Use `CPPUNIT_ASSERT_EQUAL` with `std::string_view` instead of `strcmp`
for better error messages in case of a failure
* Avoid instantiating an `std::string` in checks using `std::string_view`
instead
Fix
```
pragma diagnostic pop could not pop, no matching push
```
The GCC documentation says "If a pop has no matching push, the
command-line options are restored." but that's apparently not working here.
This might avoid
```
/Users/oldfaithful/Local/tageditor/cpp-utilities/tests/conversiontests.cpp:29:15: error: call to 'swapOrder' is ambiguous static_assert(swapOrder(0xABCDEF1234567890ul) == 0x9078563412EFCDABul, "swapOrder(uint64)");
```
reported by https://github.com/Martchus/cpp-utilities/issues/22
Building shared and static libraries at the same time has been removed as
of version 5 so this message would never be printed and it is not clear
anymore what the actual problem was.
This variable was never actually used. I suppose I've been adding it for
places where the config should be added as a prefix. However, this would be
inconsistent and now would also mean a confusing overlap with the
namespacing feature. So let's just remove it.
Martchus
Hannah Rittich