embedded deployments review

[vinniefalco]

The library needs to be reviewed for resource usage with an eye to embedded environments. The documentation should state what steps need to be taken to ensure that the resulting library consumes as little as possible. For example they might disable source locations in error codes and exceptions. And any implementation-defined internal stack buffers might be tuned downwards in size (see Boost.JSON for an example of this).

[alandefreitas]

library consumes as little as possible

So the criteria are

• Included headers
• Binary size
• Size of stack buffers
• Dynamic allocations

Any other criteria?

About the headers:

For example merely including or or <system_error> is a problem for some users.

This seems to be the biggest constraint. Once the API is stable, it's hard to remove some of these headers (with the exception of <algorithm>). Unless we have some macros that would make functionality related to some types (e.g. string_view) unavailable?

[vinniefalco]

No, included headers don't count. This issue regards how the library performs when it is deployed on embedded systems, not when it is compiled on embedded systems.

[alandefreitas]

OK. So the issue converges to

• Macro to disable source locations in error codes and exceptions
• Macro to tune the size of internal stack buffers

[vinniefalco]

Yes and maybe something for the length of error code strings, if they take up a lot of space. But remember this is not something we need to address right now, the issue just serves as a reminder to review it before the first official release (post-acceptance).

[vinniefalco]

I thought source locations already had a toggle (from the original lib) ?

[alandefreitas]

The toggle is there, but it wasn't being used to disable the location at some points.