|
Boost : |
Subject: Re: [boost] request for comments in a new format library
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-02-23 00:49:40
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_string.html
:
{/ 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_encoding_convertion.html
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk