On Sat, Jun 24, 2017 at 4:28 AM, Frédéric Bron via Boost < boost@lists.boost.org> wrote:

...

...

Is there space for another formatting library in Boost? Anyone interest in this one?

I'd be interested in one. I looked at the documentation, you might want to outline how it does compare to boost.format. But besides that, it looks quite interesting.

Also, how does it compare to fmt? https://github.com/fmtlib/fmt Thanks, Frédéric

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Hi, happy you two are interest. I confess that I never used fmt, hence I don't know it deeply. So I will just list some things boost.stringify provides that I think fmt and boost.format do not: (1) When adding new input types, the user will be able to create new facets and facets categories and formatting options specific to this new input type. (2) boost.stringify (will) support many destination types and it is easy to add user-defined types. Qt users, for example, might want to use it to write to QString. (3) It is able to append directly to std::basic_string. You don't have to write to an intermediate string to then append it. boost.stringify calculates the required amount of characters and set an adequate capacity, so that only one memory allocation happens at most. The desire of such ability was expressed some time ago. ( http://boost.2283326.n4.nabble.com/Variadic-append-for-std-string-tt4690743.... ). (4) char32_t is used in facets that specify characters ( like the fill character, and, in future, the punctuation and digits caracters ). So that you are not limited to the ascci characers when the destination character type is char. ( By default it is converted to utf-8, but in future the user will able be customize this translation. ) There is a another and more subtle rationale for this: the same facet should work regardless of the destination character type, which, for example, in Windows usually wchar_t, while in others OS its usually char. This this helps to reduce the duplication of code and the use of #if/#else. (5) boost.stringify aims (todo) to support translation from utf-8 to utf-16 and vice-versa, and other encodings. For example: boost::stringify::write_to(destination) ("aaa", u"bbb", U"ccc", L"ddd"); will work regardless of the destination character type. This also has to do the previous rationale. (6) boost.stringify support joins <https://robhz786.github.io/stringify/doc/html/input_types/input_types.html#input_types.input_types.special_input_types.joins> . kind regards Roberto

On Sun, Jun 25, 2017 at 1:43 AM, degski via Boost <boost@lists.boost.org> wrote:

On 24 June 2017 at 17:42, Roberto Hinz via Boost <boost@lists.boost.org> wrote:

...

(5) boost.stringify aims (todo) to support translation from utf-8 to utf-16 and vice-versa, and other encodings. For example:

boost::stringify::write_to(destination) ("aaa", u"bbb", U"ccc", L"ddd");

will work regardless of the destination character type.

You might want to hold of on doing this untill Boost.Nowide has crystalised completely and depend on that, as there are a number of thorny issues (see recent mailing list postings, (warning: many!)) regarding this on Windows. Boost.Nowide should/will provide the concensus solution to this conversion/problem.

Thanks for the advice. I will wait and follow the consensus to Boost.Nowide, and study this subject carefully. Robhz

On Mon, Jun 26, 2017 at 1:38 PM, Tim Blechmann via Boost < boost@lists.boost.org> wrote:

hi!

interesting library ...

Thanks

...

(2) boost.stringify (will) support many destination types and it is easy to add user-defined types. Qt users, for example, might want to use it to write to QString.

i wonder: how much of the flexibility to the users have to pay for with compile times and code bloat?

I believe this is indeed the biggest drawback of library, though I haven't made any compilation performance test yet. Added to the todo list.

On Sat, Jun 24, 2017 at 2:39 PM, Frédéric Bron <frederic.bron@m4x.org> wrote:

Hi,

...

Is there space for another formatting library in Boost? Anyone interest in this one?

What is the difference between 2 and 7 here? https://robhz786.github.io/stringify/doc/html/usage/usage.html

Frédéric

That´s an error in the documentation. Expression 7 should be: make_basic_string<C, T> .with(facets...) (args ...) robhz

( I answered this message in private by accident. I´m resending it to list now) On Sun, Jun 25, 2017 at 3:26 PM, Frédéric Bron <frederic.bron@m4x.org> wrote:

...

But what if we just add new input type that applies the formatting string to a sublist of arguments:

strf::make_string ( "\n--------------------------------------------------\n" , { strf::join_center(50) , { { strf::fmt("Table {}.{} - Configuration files") , {chapterId, tableId}}}} , "\n--------------------------------------------------\n" );

I think that it would work. However, we need to be able to have any format for chapterId and tableId, not only the standard operator<<. If it is a floating point for example, we need to be able to change the precision...

Frédéric

The formatting can then be specified as usual, either by a braced-init-list around the argument ( as below ) or by facets double x = 0.0; double y = 0.0; int precision = 6; strf::make_string ( { strf::fmt("x = {0}, and y = {1}") , { {x, {"", precision}} , {y, {"", precision}}}} ); Positional parameters as above can be implemented easily. But I'm against any formatting inside the parsed string, unless there is a really good reason. It would bring to much complication, since the formatting characters may change according to the input type. User-defined types, in particular, will not be required to follow any formatting convention robhz On Sun, Jun 25, 2017 at 2:32 AM, Frédéric Bron <frederic.bron@m4x.org> wrote:

...

Is there space for another formatting library in Boost? doc: https://robhz786.github.io/stringify/doc/html/index.html

I find strf::make_string(value, " in hexadecimal is ", {value, "#x"}) not easy to translate.

This would be written like this: strf::make_string(value, gettext(" in hexadecimal is "), {value, "#x"}) but it works much better for translators to have the full sentence gettext("{0} in hexadecimal is {1}")

I understand that what you save the time to parse the string doing so.

Could have something like make_string("{0} in hexadecimal is {1}").with({value0, fmt0}, {value1, fmt1})?

This would keep the parsing very simple and quick and still allow for compile time parsing of the format (with template facets).

Frédéric