On 22/02/2018 03:24, Roberto Hinz wrote:
some time ago I announced a format library I'm working on. I think at that time it was still too incipient for one to evaluate whether it looked promising, thought some few but very useful observation were made ( one regarding i18n and other code bloat ) that made me change many things.
https://robhz786.github.io/stringify/doc/html/ Do you assume that "char" is UTF-8 or is it encoding-agnostic? I suspect the former given use of char32_t elsewhere. While this might be typical on Posix it is not universal, and on Windows it is rarely the case. https://robhz786.github.io/stringify/doc/html/general_syntax/syntax.html = vs. &= to denote exception throwing or not seems a bit opaque. Have you considered overloads taking nothrow_t or error_code& instead? https://robhz786.github.io/stringify/doc/html/assembly_string/the_assembly_s... : {/ as an escape is highly peculiar. \{ or {{ would be more typical. "destinated" => "intended" https://robhz786.github.io/stringify/doc/html/facets/facets.html "octadecimal" != "octal". The latter is correct. Also, while I've never particularly been a fan of the STL formatting facets, it does bother me a bit that you're trying to reinvent the wheel here. https://robhz786.github.io/stringify/doc/html/encoding_facets/facets_for_enc... I guess this confirms the "char == UTF-8" assumption. Admittedly the STL seems to have poor support in this area too. Regarding the BOOST_STRINGIFY_DONT_ASSUME_WCHAR_ENCODING macro definition, you should try to avoid having these break ABI in different compilation units -- have it select in the headers which of two unique implementations in different namespaces is used, such that both can coexist in different translation units without conflict. The compiled library, if there is one, would always provide both.