A followup to a recent rant.
First an admission. At least one thing I complained about was not a feature of JSON per se but of the library (nlohman::json AKA JSON for Modern C++) that we're using. In particular the behavior of serializing a floating point IEEE-754 special to null, and then throwing when trying to deserialize a null into a floating-point variable is library specific. And they stand by it. Grrrr!
Second, by defining a strong-typing wrapper I was able to (de)serialize
those values from-and-to strings. I even provided multiple acceptable spellings
on the deserialize path. Then by writing explicit to_json
and from_json routines for my objects (rather than relying on the
handy-dandy macros in the library) I was able to apply the
strong-types only at the point of (de)serialization reducing what
initially looked like a major intrusion into the code. Yeah.
It's not a complete win, however, because I have
a std::variant in the code-base. The usual
advice for deserialize a variant with the library is to detect the json-type of
the value1 and use that to know which member type to set. Only the
number can give rise to a string value. So I had to explicitly (de)serialize the
current-type, too. Bletch!
Long story short. We're going ahead with this and I may replace ny custom interchange format after all. Just because other users will stand a better chance of decoding the JSON.
But the lack of infinity and not-a-number is still a bug and still renders the format poorly suited for use in numeric computing.
1 JSON for Modern C++ uses a domain-model object as an intermediary, so this is relatively easy.
No comments:
Post a Comment