Date: Sun, 08 Sep 2019 13:34:18 -0700
On Sunday, 8 September 2019 11:37:00 PDT Lyberta wrote:
> Thiago Macieira:
> > So you're going to do all of this just to produce a simple JSON payload
> > with the result of an operation?
>
> That depends on the specifics of the job. I prefer to code general
> solution if I can afford to write it. Right now I need general JSON
> reader/writer and I'm gonna write everything I mentioned.
>
> In a perfect world binary IO and Unicode would be in standard library
> while JSON can be downloaded via a standard package manager. But we
> don't live in a perfect world.
Agreed. Using a library that implements JSON properly is the correct solution.
That library will likely have had at least one bug reported against it if it
didn't account for locale. I looked into both nlohman's json.hpp and RapidJSON
just to see how they managed it and they both implement encoding of doubles
directly, not using sprintf. Or, when they use sprintf, they go around and
correct by removing group separators and replace the decimal separator.
The implementation for long double, however, seems wrong.
> > I'm not mixing them. They are in different channels.
> >
> > The error message goes to the user. The JSON payload goes to a file.
>
> The original example was using LC_ALL and pipes so I assumed interchange
> via stdin/stdout.
True, but even if stdout was the channel for JSON, the error message is
stderr, so still different channels.
> You know... why does POSIX have the same file descriptor for both text
> and binary? There should be std_text_in, std_text_out, std_binary_in and
> std_binary_out. That's the only sane way if you think about it.
>
> Well, just gotta wait another 30 years until OSes become more sane.
Often, when need machine-parseable data, you ask for it, instead of scraping
from the operator-intended output. But even in those modes, it's quite
possible that floating point data would be mis-represented, as application
writers will simply use printf() or std::cout, failing to realise their
mistakes.
I just can't think of a good example right now.
> Thiago Macieira:
> > So you're going to do all of this just to produce a simple JSON payload
> > with the result of an operation?
>
> That depends on the specifics of the job. I prefer to code general
> solution if I can afford to write it. Right now I need general JSON
> reader/writer and I'm gonna write everything I mentioned.
>
> In a perfect world binary IO and Unicode would be in standard library
> while JSON can be downloaded via a standard package manager. But we
> don't live in a perfect world.
Agreed. Using a library that implements JSON properly is the correct solution.
That library will likely have had at least one bug reported against it if it
didn't account for locale. I looked into both nlohman's json.hpp and RapidJSON
just to see how they managed it and they both implement encoding of doubles
directly, not using sprintf. Or, when they use sprintf, they go around and
correct by removing group separators and replace the decimal separator.
The implementation for long double, however, seems wrong.
> > I'm not mixing them. They are in different channels.
> >
> > The error message goes to the user. The JSON payload goes to a file.
>
> The original example was using LC_ALL and pipes so I assumed interchange
> via stdin/stdout.
True, but even if stdout was the channel for JSON, the error message is
stderr, so still different channels.
> You know... why does POSIX have the same file descriptor for both text
> and binary? There should be std_text_in, std_text_out, std_binary_in and
> std_binary_out. That's the only sane way if you think about it.
>
> Well, just gotta wait another 30 years until OSes become more sane.
Often, when need machine-parseable data, you ask for it, instead of scraping
from the operator-intended output. But even in those modes, it's quite
possible that floating point data would be mis-represented, as application
writers will simply use printf() or std::cout, failing to realise their
mistakes.
I just can't think of a good example right now.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products
Received on 2019-09-08 22:34:25