Closed gladijos closed 3 years ago
Possible this issue come from using uint8_t type, with int type compiles fine
There is no support for char or uint8_t, so that is probably the issue. I did add some customizations to my code that support uint8_t as an int and the array of uint8_t does work.
The supported basic types are defined here:
https://github.com/Loki-Astari/ThorsSerializer/blob/master/src/Serialize/Traits.h#L436
Not sure how to support type aliases. Or if using traits on type alieases would work consistently that is something I would need to test a bit.
Since I would never use char, only uint8, I added all of the appropriate functions to treat it like an int. You can just search for one of the other types like 'short' to find all the places to add support.
It worked like any other type, except I had to cast it when putting it into the stream to make sure it wasn't treated as a char in the Printer override:
HEADER_ONLY_INCLUDE void JsonPrinter::addValue(uint8_t value)
{ output << PrefixValue(config.characteristics, state.size(), state.back()) << (unsigned int) value;}
I also did the same for int8_t, and I expected problems with the signedness casting to int, but it worked, but that may be implementation specific
@ripe909 The only issue here are:
uint8
is not a C++ type. uint8_t
is but only in the std
namespace (so std::uint8_t
).I am more than happy to accept a pull request with these modifications (and appropriate unit tests).
I will try and create a clean PR.
It would probably make more sense to use char type rather than the uint8_t alias. I just use uint8_t to make the intention clear, but it is just an alias for unsigned char in my toolchain.
Maybe a directive that must be set to enable the use of chars as ints would make it clearer?
Describe the bug
Expected behavior
Environment:
OS:
Compiler and Version
Additional context