limiting print decimal point

[ajaybhargav]

Currently JSON number is printed with upto 15 decimal places (e.g. 21.379983333333332) most of the time such long number is not needed and is a wastage of space in embedded system. Can we have a provision where in we can pass number of decimal places needed.

for instance:
cJSON_CreateNumber(double num, int digits)

This will save lot of space when complete decimal number is not needed.

[FSMaxB]

From what I understand it's not possible to do this via a special cJSON_CreateNumber function in a good way. In theory an additional number type could be added or an additional flag, but that doesn't lie in the scope of the library.

So this woul have to be either an additional cJSON_Print function or a compile time flag. I'm not sure how to use a precision from a variable in a sprintf format string though.

Another potential idea would be to find out if the number can be truncated in such a way that is is printed as a shorter number.

But in any case I'm quite reluctant to add such functionality because it increases complexity and configurable knobs again.

If such functionality were to be added, it would probably be set at compile time.

[ajaybhargav]

I think we already have a good complex logic where we first try one format and then try to check if retrieval is same or not and then try another format.
A simplest implementation could be to have a dynamic format. e.g.

char format[10];
/* create a format */
sprintf(format, "%%1.%dg", decimal_places);
/* Then convert it to string */
sprintf((char*)number_buffer, format, d);

[FSMaxB]

In general I would be ok with this. (better at runtime than compile time since this means that I can unit test it more easily, I've come around on that one!)

To keep the overhead low this format string should be created once and then passed through via e.g. the printbuffer.

The problem is though that I don't really want to add more and more functions to the API for every possible configuration option, and I don't want it to be stored in a global variable either because the goal for cJSON v2 is thread safety. (or reentrancy in general)

There won't be less configuration options in the future, so I would like to have a way to only have one Function for custom parsing, one function for custom printing etc and passing a configuration "object" to them via a pointer.

Problem: If I use a struct, I would break ABI and API compatibility every time I add a new option. The API compatibility can be dealt with using a default settings struct that can be assigned, but the ABI would still break.

Maybe it's ok to store it in a global variable for the time being and having another configuration method ready for v2.

[ajaybhargav]

I don't think this is needed to be stored as an option since its not always needed to be the same. For instance, If I am putting temperature value in JSON Number format then 2 decimal places are enough however I will need atleast 6 or 7 decimal places if I want to put a GPS coordinate in JSON. So a per call decimal place control will be the best choice.

I know you do not want to add too many functions and maintain ABI compatibility, Can we do something like say.. cJSON_Print calls internally (with maybe -1 as decimal place to indicate default format) cJSON_PrintEx (extended function) which takes decimal places as input can be used if user wants to change number format.

Edit: I am thinking more from usage prospective in real scenarios.

[FSMaxB]

It can be stored as an option, the idea of #177 is to create as many configuration objects as you need and store them for later use. Then you just pass the appropriate one in when you need it.

I am not willing to add another cJSON_Print function. For now I am only willing to add a function that accesses a global variable, similar to cJSON_InitHooks. As long as you don't do threading you can just call that every time you need to change the precision.

What do you think?

[Tangerino]

Would not be better if we find somewhere in the wild a 'number beautifier' function?