Making some features compile time optional to reduce the code size.

[Tangerino]

I do have a use case where I don't need to encode JSON so I'd like to remove that code from the library. I've installed (quick & dirty) some ifdef and reduced by 60% the code size. A huge difference when using micro controllers.
Thanks

[FSMaxB]

My discussions with @ajaybhargav in #177 have led me to reconsider using compile configuration of the feature set.

The only thing that I am still unsure about is how fine the granularity should be.

Also I don't think I will be able to test all possible combinations if the test matrix gets too big.

[Tangerino]

Thanks. I would say at least implement encode/decode options

[FSMaxB]

So my current plan is to do the following options:

• parsing
• printing
• cJSON_Minify
• cJSON_Duplicate
• cJSON_Compare

In the future cJSON_Utils could then be included into cJSON guarded by feature flags.

I also though about making profiles. Like minimal and full.

[FSMaxB]

This would then already be too much to test all configurations, at least in continuous integration, since 2^5=32. But it might be doable to build them all once before a release.

[Tangerino]

Support only integer and not double would reduce too? What about UTF-X, embedded systems can live without it. Carlos

…

On Sun, Feb 25, 2018 at 2:41 PM, Max Bruckner ***@***.***> wrote: So my current plan is to do the following options: - parsing - printing - cJSON_Minify - cJSON_Duplicate - cJSON_Compare In the future cJSON_Utils could then be included into cJSON guarded by feature flags. I also though about making profiles. Like minimal and full. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#245 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADBHxIYP_YeUatRVcK2xvUWWGLjN1sZ1ks5tYWMZgaJpZM4SR1Hf> .

-- *Merci beaucoup, Muito obrigado, Thanks* *Carlos TangerinoMobile: +33 6 82 05 55 18*

[FSMaxB]

I don't really want to go lower than per function level with the compile time configuration.

UTF-16 to UTF-8 conversion is here to stay.

I have though of making the use of double runtime optional in the future in v2, see the newest idea on how the struct should look in the future #63 (comment). That can be combined with #186 by adding a new option to only parse all numbers as integers. When I get to that point, I have to think if it is possible to optionally get rid of the double related code altogether. This requires the code paths to be separate enough to make this possible.