Some serialization formats supported by reflect-cpp, such as CBOR and
MessagePack, allow map keys to be types other than strings.
Currently, reflect-cpp's generic object/map abstraction uses string keys,
so integral keys are converted to strings. For example:
std::map<int, int> value{{1, 2}};is represented as:
even when the target format can preserve it as:
A practical use case is COSE_Key, whose fields are identified by integer
labels:
{
1: 2, // kty: EC2
3: -7, // alg: ES256
-1: 1, // crv: P-256
-2: h'...', // x
-3: h'...' // y
}
Converting these labels to strings changes the encoded data and produces an
invalid COSE_Key.
Could reflect-cpp preserve native map key types for formats that support them,
while keeping the existing string-key behavior for formats such as JSON?
This could apply both to associative containers and, if feasible, reflected
types with non-string field labels.
Some serialization formats supported by reflect-cpp, such as CBOR and
MessagePack, allow map keys to be types other than strings.
Currently, reflect-cpp's generic object/map abstraction uses string keys,
so integral keys are converted to strings. For example:
is represented as:
even when the target format can preserve it as:
A practical use case is
COSE_Key, whose fields are identified by integerlabels:
Converting these labels to strings changes the encoded data and produces an
invalid
COSE_Key.Could reflect-cpp preserve native map key types for formats that support them,
while keeping the existing string-key behavior for formats such as JSON?
This could apply both to associative containers and, if feasible, reflected
types with non-string field labels.