iostream support blows up binary size and RAM requirements

[pvaibhav]

Currently iostream support is unconditionally enabled. This is fine for desktop targets but not for small embedded targets with limited flash storage and RAM. For instance on the Nordic nRF51 based on ARM Cortex-M0+, approx 150kB flash and 6.5kB of extra RAM is used, on a device which only has 256kB flash and 8kB RAM.

Disabling iostream support will go a long way in supporting embedded targets.

The following patch (against v2.2.x branch) adds a #define to enable/disable iostream:
https://gist.github.com/pvaibhav/c3703bf23c8513f4a8160eed524a415d

I've verified disabling iostream results in zero impact on the compiled binary size or RAM usage.

I'll create a pull request from this patch if there is any interest. My only concern is the duplication of UNIT_ADD definition, once with and once without iostream. An intermediate macro could perhaps help here.

[nholthaus]

I'm all about supporting embedded. I'd tacitly assumed that the template meta-programming would blow up small microprocessors, so I originally wasn't worried about iostream or includes in general. If that's not (always) the case, then I'm definitely interested.

---

In terms of the implementation I think I'd prefer to see UNITS_LIB_ENABLE_IOSTREAM be UNITS_LIB_DISABLE_IOSTREAM, and have it not be defined by default in the library, that way it can be defined in user code (or on the cmake command line) rather than having to patch the library for embedded use.

I also agree about the macros. I think they need to be refactored such that UNITS_ADD becomes a macro-of-macros depending on which features are enabled (iostream/literals/etc). This would also allow the duplication in the VS 2013 macros to be removed (probably by defining UNITS_LIB_DISABLE_LITERALS or something).

I can work on this and get it into v2.2, unless you'd prefer to make the changes.

[pvaibhav]

No problem, I'll refactor a bit based on your suggestions and send a patch tomorrow!

[nholthaus]

This is being tackled in PR #42 now.