Encoding of double variables that happen to be integral

[dwaydwaydway]

Hi,

I'm trying to assess if I can make my application migrate from using Rapid Json to using Glaze. And I'm noticing a behavioral difference:

Let's say I have a double variable of value 10.0

double var{10.0};

If I encode var with Rapid Json, I'll get {"var": 10.0}

Whereas if I encode the following with Glaze:

struct test {
    double var{10.0};
};

I'll get {"var": 10}

Is it possible to have a compile-time option where I can get the .0 with Glaze?

[stephenberry]

Glaze, like std::to_chars, will write out doubles with the least amount of characters necessary for round-tripping. Hence 10.0 is dumped as 10.

Are you wanting to dump floating point numbers with a decimal place so that you can determine if they are integers or floating point numbers? I'm curious what is your motivation?

We could add an option that allows you to add a std::format template for how numbers are printed out. E.g. .number_format = "{:15d}". Would you want this behavior for all doubles you are serializing?

[dwaydwaydway]

Hi @stephenberry , thanks for the reply.

The motivation is that the client side of my application is doing schema validation on the json string received. And this is causing error on the client-side checker because it assumes that the var is encoded as an integer, which is not the expected type of double.

Yes it would be useful, or rather critical in my case, to have the formatting option for floating point numbers!

If you agree that this is useful and decide to implement this, would you mind sharing when can we expect this feature roughy?

Much apreciation!

[stephenberry]

I can understand your motivation and why it may be a requirement. But, I am leery of this approach, because you are relying on specific format that is outside the scope of JSON, so your program will then fail with perfectly valid JSON.

If you only needed this support in a few places then using the glz::custom wrapper would be my recommendation right now. But, if this feature is required all over your code then I would recommend sticking with Rapid Json for a while.

I don't think I'm going to do this immediately, because I'm currently trying to finalize a new approach for handling compile time options, and this will need to be another compile time option that is a little more complex because it requires a flexible string input.

It will probably be a few months before this is implemented.