Why not fmtlib compile-time formatting?

[bryceschober]

@lukevalenty At a superficial glance, it looks like fmtlib v9.0 supports compile-time formatting for even floating-point numbers... So why not use that instead of inventing your own thing? I'm sure you've already looked and have an answer, and my understanding of fmtlib is very superficial, so my assumptions are probably completely wrong... So can you explain?

[lukevalenty]

fmtlib v9.0 supports compile-time formatting for even floating-point numbers... So why not use that instead of inventing your own thing?

Mostly because the string_constant library was originally written about two years ago. I would welcome a pull-request to replace the compile-time formatting with fmtlib under the hood, but retain string_constant input and output.

[elbeno]

#338 switches to compile-time formatting with fmtlib.

[antonysigma]

We avoid loading fmtlib simply because of -fno-exceptions and -fno-rtti compiler arguments required by baremetal MCUs, e.g. ATTiny85. The current fmtlib version (9.0) requires #include <stdexcept>. This header file is likely deliberately removed in the tool chain, so including fmtlib limits the adoption of Intel CIB to these chipset.

@elbeno , do you customize your own version of fmtlib? How do you compile fmtlib and Intel cib with -fno-exceptions and -fno-rtti? Can you please direct me to your PR?

[elbeno]

We don't have a custom version of fmtlib. A quick test shows that all the tests work with -fno-rtti and -fno-exceptions. So there is no problem with fmtlib use per se - I think it is the embedded toolchain that is in error here.

(The current fmtlib version is 10.2.0 - are you referring to the cpp17 branch? But then #338 isn't on that branch...)

Exception handling is actually required for freestanding implementations, as is the <exception> header (https://en.cppreference.com/w/cpp/freestanding). Although the <stdexcept> header is not required, there's no reason to delete it since it just defines vocabulary types - which is how fmtlib uses it.

A strictly minimal freestanding implementation would not currently support CIB anyway (likely until https://wg21.link/p2407 lands in C++26?). If there is a toolchain issue here, I think the right solution is either an appeal to the toolchain vendor or a PR to fmtlib?

[elbeno]

@lukevalenty FYI

[lukevalenty]

@elbeno, I wonder if we could make a PR to libfmt that would make that header optional.

Otherwise a PR to the mentioned AVR library with a minimal header could be added.

[elbeno]

I'd recommend that AVR lib should have <exception> and <stdexcept> headers: notwithstanding turning off exceptions, these headers just define vocab types that can be used anyway.

Making libfmt technically freestanding-friendly is probably not going to happen until the aforementioned P2407 lands. I don't know about removing the use of std::runtime_error, but maybe.

For now using a version pre-#338 is the most expedient option.

[mjcaisse]

<exception> and <stdexcept> are not required headers for freestanding: https://en.cppreference.com/w/cpp/freestanding

[mjcaisse]

My mistake.... <exception> is listed as "all"

[antonysigma]

Thanks. I guess I will roll back CIB to pre-#338 for the time being to finish my study. I have a working draft here evaluating cib::log, avr-stdlib, and meson build integration.