Integrate and support {fmt} for c++20 std::format-style formatting in gecko
Categories
(Core :: XPCOM, enhancement, P3)
Tracking
()
People
(Reporter: nika, Assigned: nika)
References
Details
In C++20, a new formatting library was defined which uses rust/python style {}
format indicators for formatting strings etc. std::format
also supports formatting custom types in various manners and will be expanded on in future c++ versions.
In general, gecko has continued to use printf
-style formatting over stream style formatting for various reasons, including code size and style. This new format string type has improved flexibility and type safety like operator<<
stream formatting, while also being performant and codesize efficient like printf
.
While we cannot directly adapt c++20's implementation, as we are still using c++17 and no standard library supports the full spec yet, there is a community implementation of the syntax in the {fmt}
library, which also provides extra flexibility allowing us to integrate into ns[C]String
more efficiently.
This bug tracks potentially vendoring {fmt} into the tree and adding basic support to core xpcom features like MOZ_LOG
and ns[C]String
for the library.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
One thing to look out for: how it formats floats (specifically, the rounding for floats)
Assignee | ||
Comment 2•3 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #1)
One thing to look out for: how it formats floats (specifically, the rounding for floats)
I looked into this a while back, and the {fmt}
library appears to take glibc's approach to float rounding rather than our approach with double-conversion
and ecmascript rules (from that testing I also noticed that their printf
implementation appears to have some issues around padding/sign digits, however it's unclear whether this impacts their normal format strings).
If we import the crate, we'll probably want to apply some patches on the source to replace the floating point formatting infrastructure with our existing infrastructure in order to use the ecmascript rules and double-conversion
under the hood, as it seems somewhat unlikely to me that they'd be interested in upstreaming ecmascript rounding support.
Assignee | ||
Comment 3•3 years ago
|
||
This proposal uses an third-party library, rather than c++20's format implementation, so doesn't depend on c++20.
Description
•