Re: [boost] request for comments in a new format library

Subject: Re: [boost] request for comments in a new format library
From: Roberto Hinz (robhz786_at_[hidden])
Date: 2018-02-23 07:14:59

On Thu, Feb 22, 2018 at 9:49 PM, Gavin Lambert via Boost <
boost_at_[hidden]> 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