On Thu, Feb 22, 2018 at 9:49 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
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.
by default it is utf-8, but this is customizable through facets. However if one wants another encoding, one needs to implement ones own encoder and decoder as explained at: https://robhz786.github.io/stringify/doc/html/encoding_ facets/facets_for_encoding_convertion.html#encoding_ facets.facets_for_encoding_convertion.how_to_implement_your_own_decode https://robhz786.github.io/stringify/doc/html/encoding_facet s/facets_for_encoding_convertion.html#encoding_facets. facets_for_encoding_convertion.how_to_implement_your_own_encode
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?
Perhaps we could do something like: auto s = make_string .error_code("blah blah {} blah {}") = {arg1, arg2};
https://robhz786.github.io/stringify/doc/html/assembly_strin g/the_assembly_string.html :
{/ as an escape is highly peculiar. \{ or {{ would be more typical.
I'm against \{ because using an escape character before the '{' instead of after would force the parser to be less efficient. And also because the user would actually need to type "\\{". My only reluctance against {{ is that it may wrongly suggest that there must be an enclosing }}, especially to users coming from fmtlib, since this is how is done there. And I really don't want to require an enclosing }}, because the user may want to print a { without an enclosing }. Let's see what others think about.
"destinated" => "intended"
https://robhz786.github.io/stringify/doc/html/facets/facets.html
"octadecimal" != "octal". The latter is correct.
I really appreciate these little advices. thanks. Being a non-native English speaker, I'm aways afraid of making some linguistic gaffe. By the way, is it better "format library" or "fomatting library" ? "format functions" or "formatting functions" ?
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.
I can't avoid this. The std facets just don't combine well with this library. Facets of boost.stringify are designed to be used with the ftuple class template, while the facets from std are designed to be used with std::locate. And we can't use std::locale here, because we need a really fast getter, since it is called several times for each input argument. ( get_facet of ftuple is very fast, while std::use_facet is not ). ( Btw, I thinking about renaming the ftuple class template. Perhaps facets_pack or facets_bundle ). Another reason is that each facet category is designed to work well specifically in this library. Using for instance std::codecvt instead of the decode and encode facets would be too cumbersome and inefficient. It is too oriented toward std streams. There is also some design philosophy differences. For example, note that numpunct facet is based in char32_t, so that the same facet object works for different encodings. he std::numpunct on the other hand is a class template parametrized to CharT. And anyway, creating a format library is already reinventing wheel. I also needed to reinvent the formatting functions ( hex, oct, right, left, etc ).
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.
I need to think about that. I will come to an answer later. I can see you really spent some time reading the documentations And I much appreciate your effort. Thanks and best regards. Robz