You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An object is an unordered collection of zero or more name/value pairs
JSON parsers shouldn't assume the order of fields in the most of the use-cases (surely, it's possible to have the exceptions when the both JSON and its parser are in the controlled environment). As this project is not about micro-optimizations, but rather the usual code, it could be quite confusing for the average software developer that their code is broken when they parse totally valid JSON.
Therefore, it would be nice to improve tests to verify that the parser is order-insensitive. The following example demonstrates the approach:
for (const padded_string &v : {
"{\"coordinates\":[{\"x\":1.1,\"y\":2.2,\"z\":3.3}]}"_padded,
"{\"coordinates\":[{\"y\":2.2,\"x\":1.1,\"z\":3.3}]}"_padded}) {
auto left = calc(v);
auto right = coordinate_t(1.1, 2.2, 3.3);
if (left != right) {
cerr << left << " != " << right << endl;
exit(EXIT_FAILURE);
}
}
The text was updated successfully, but these errors were encountered:
Per RFC 7159:
JSON parsers shouldn't assume the order of fields in the most of the use-cases (surely, it's possible to have the exceptions when the both JSON and its parser are in the controlled environment). As this project is not about micro-optimizations, but rather the usual code, it could be quite confusing for the average software developer that their code is broken when they parse totally valid JSON.
Therefore, it would be nice to improve tests to verify that the parser is order-insensitive. The following example demonstrates the approach:
The text was updated successfully, but these errors were encountered: