220 32865 article Path: news.gmane.org!.POSTED!not-for-mail From: Victor Zverovich Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: C++ formatting library proposal Date: Sat, 24 Jun 2017 18:52:37 +0000 Lines: 474 Approved: news@gmane.org Message-ID: References: <4777755b-5984-4ef3-8fc5-a3e17aa94469@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1959fe5106260552b939b5" X-Trace: blaine.gmane.org 1498330370 27480 195.159.176.226 (24 Jun 2017 18:52:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Jun 2017 18:52:50 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCV6RYWKYEHBBAHKXLFAKGQEPF7BJ5Q@isocpp.org Sat Jun 24 20:52:45 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOqAm-0006vv-Vg for gclcip-std-proposals@m.gmane.org; Sat, 24 Jun 2017 20:52:45 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id y194sf17446314lfd.11 for ; Sat, 24 Jun 2017 11:52:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1498330370; cv=pass; d=google.com; s=arc-20160816; b=00nRksN6YJPrqlwt59hpH/kW5CzIgCXHPSzt9eO3YMykxWkIHcAlpfcB7Dc0hElQ4v VdW4r4BDG9JJ+X9NOdDCfiTCx7EyDqdSGUxinettgjXusZoQK7/gjivwKo5CrBc/uhZC uYTE23QperBB01dyo825I467/hpAY9UmIb0/Pkm6OqpgMBaOC7Y3BdHM3u9SmHys/1Wh vKjU5n+J6zgfiALHlrGDXTqmBMlA+afkRp0PO/d09NxMLWXS9umKXwXOAilaUZpWKdR4 9c7WMAae2CQ+gva0Gm+odcF67bPdYs/ySRZM26RtyLftaFfeu/m8b5LG38Ap7NmKK89L DZZA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=+/6PkkYmaDZvsFyOwQu6DIun71293VMvSbuZEzFA6Xg=; b=h/vgDFTbzjbiOGQBoAVKuDAUl5k8kl9GldTacQRSW2IDKJPMlBkFHcL827cxdTf4FD wsT0sUOJxnIx1llLhMxqata3L7Xl+k65hGzXJk92s/Uolta72qPIWYaRXM7leOm2QVBM 5ZhD9xRqB/GlCAvnmv23Y9hLl/Wo3fm2Qal2mj9xu7j03iHx1By6wEm3UO35+mVPtXHk 7+MK7H8dl+Hw7W50M0PQZbjNWsMPCy+cn9t/nB+uFUpeMrlYOtd3GgSqPyjDrMKOkBeZ p1tTbiN2gqBuCAAsdgkxAEv1yt0XJQ55w5zunCg5UhxWOLlovffJuH3HoV2/cR4jaGey 6Q1A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.b=oxrL+2Vy; spf=pass (google.com: domain of victor.zverovich@gmail.com designates 2a00:1450:400c:c0c::232 as permitted sender) smtp.mailfrom=victor.zverovich@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+/6PkkYmaDZvsFyOwQu6DIun71293VMvSbuZEzFA6Xg=; b=G2einXmBw6rUdNv58PvGwct0mmqxxvowowk0/cCBdmnoc0XuXjMAzAUIOBPjS8mLef eRoMfTVAZcQlHzJa5/e3RhPIHjpwOLG4gSn9wWVxoDqOGdkxXAwfwCKO608p7gx8TKKy 0VGLabg8yy4Y7+gW+WAWix8UtyDwZxxHuLIsjPlCtzIDtft5qlvChwUL8hRmWetZZOVu 9y8WrfA4hIkG50I21Xu6tZGymY9iTl+bHcL2Lq4v1tb22ynxnmjo0JjDQS/SJ70O3TVX d1FXjtVpRgdDaGh0kncZer+0drHVAQ8+JMo+nTtkLC+ZZs2ZezXJOltBv2vHM61kAvPH XYPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+/6PkkYmaDZvsFyOwQu6DIun71293VMvSbuZEzFA6Xg=; b=IJfbfrzirHp1qp6tQIv9+2Ldz4Epy8DCvNRCoTa0kLFzA1/+OqzTkS2jCsi3HF4fCH zQP2T0c87BsF4EJJ4q5Gc6imbdjAf8CLsK9xETMVkTMXjnj20DZN8nX2JheGxguJQHa1 tGm6kIRonn5dsZ2IuTiyxyMTaN37F7XMzYx2E4Z2Exp0bUVO58/jV0uqTmmhA5k6t7o6 gVO0R/GJdGwvNenSibJPBXoPDh9+4rcixMDFk8yN/St+U7TN9ah2SDvu8HQE6OPsyJyx N3kVI5M/PoTQNyAqBR1c/sfdxEsNRtilaHAz8BHl/p+fzt0ZBHqKZmmssLtTzdBN480x AkMA== X-Gm-Message-State: AKS2vOzNxOwifIIU+BgHU6XgEQVKd5luSOQz/TPWTfqslVK07zM/J0xm vCKJh9gnZmgOQugv X-Received: by 10.25.145.73 with SMTP id y9mr2249185lfj.22.1498330370355; Sat, 24 Jun 2017 11:52:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.136.136 with SMTP id k130ls239472wmd.25.canary-gmail; Sat, 24 Jun 2017 11:52:48 -0700 (PDT) X-Received: by 10.223.171.83 with SMTP id r19mr9607006wrc.173.1498330368281; Sat, 24 Jun 2017 11:52:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498330368; cv=none; d=google.com; s=arc-20160816; b=OtV0ROv59CxRAlhv9GcSSYg2nPN/Tku/0gUqZod2YG7HEohU3VxpgMA3ciWMkqDhcn DtxPAogfP7tLe9o2BMJOOtCplz1gBD7mbTlnPZdR61LMBBIYnlMLNFiNxetHWsdsqN90 ptoesz+xrSqP3tjh8sQpLulGAG/JHMsxqXLlbInK+jJyBp3Fv0NzX6f66S10Y3PFdxJH jJmCDH+c7a0oYhjpv9w1hIUxg1DEqV7GUEGhUC08lBUiO4v2qIc03Dbt5hatpcakAXB1 fHr7Y3JAKA8BBs2aL0GxkhVn9u7mZIooBin3m5gIXNeRP2RPx29+1yHTiXYrokv4jh40 p7JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=/aEhiUNqKt1Bhc52LByFHjD5gT+ecwEyuld3XrqgFTE=; b=nGMlGdGjjIpJjzT9/eZJEDS0bvV6DVIPtxkuBRsgt92mu4OuN7PiiBXn5jiBQpjh5a SUoRSpdRRPKaYeUK4vJ3rXIgaaixbF6ct7fPyEHSwFs6GPPUldeauAXowD3PCfit73Ie AIXPVG5Saa+at1q9ryD8Q2OB4PUzh/gxzMEpBFV++XaPjDHJJbvzzEtFPvP5HSXK0kC1 tCJGaeTod3ry4N0Dm5IIr4Hj4Zwva+5pTyEr4vbFrrCtQQxWomvwmyCXTrITzRVT7dh1 sdG5ZKy1jIWZSOuuDYr4YstkHP9MGdpAia6f6UuCnEKlk3kNTyzv32E5xIPb1sp8ouUg yqDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.b=oxrL+2Vy; spf=pass (google.com: domain of victor.zverovich@gmail.com designates 2a00:1450:400c:c0c::232 as permitted sender) smtp.mailfrom=victor.zverovich@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com. [2a00:1450:400c:c0c::232]) by mx.google.com with ESMTPS id z199si6807154wmc.58.2017.06.24.11.52.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 11:52:48 -0700 (PDT) Received-SPF: pass (google.com: domain of victor.zverovich@gmail.com designates 2a00:1450:400c:c0c::232 as permitted sender) client-ip=2a00:1450:400c:c0c::232; Original-Received: by mail-wr0-x232.google.com with SMTP id c11so104179237wrc.3 for ; Sat, 24 Jun 2017 11:52:48 -0700 (PDT) X-Received: by 10.80.140.2 with SMTP id p2mr10235354edp.129.1498330367589; Sat, 24 Jun 2017 11:52:47 -0700 (PDT) In-Reply-To: <4777755b-5984-4ef3-8fc5-a3e17aa94469@isocpp.org> X-Original-Sender: victor.zverovich@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.b=oxrL+2Vy; spf=pass (google.com: domain of victor.zverovich@gmail.com designates 2a00:1450:400c:c0c::232 as permitted sender) smtp.mailfrom=victor.zverovich@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:32865 Archived-At: --94eb2c1959fe5106260552b939b5 Content-Type: text/plain; charset="UTF-8" > It would be nice if it was easy to create a formatting object from a format specification string. I think this is a great idea and I finally got a chance to experiment with it. The main drawback of having a separate formatting object is that it makes writing a formatter for a user-defined type more complicated, because you need to define 3 things: a formatter class, a parsing function and a formatting function. In the current proposal everything is combined in format_value which, on one hand, leads to less boilerplate but, on the other hand, is more restrictive. template <> class formatter { public: explicit formatter(context &ctx) { // Parse the format string. } void format(buffer &buf, MyClass &value) { // Format value. } private: // Formatting state. }; One way to reduce boilerplate is by returning the formatter object as a lambda from the parsing function, e.g. auto parse_format(context &ctx) { // Parse the format string. return [/* Formatting state */](buffer &buf, MyClass &value) { // Format value. }; } Unfortunately this doesn't work if parse_format has to take additional template arguments such as a char type: // Doesn't compile template auto parse_format(basic_context &ctx) { // Parse the format string. return [/* Formatting state */](basic_buffer &buf, MyClass &value) { // Format value. }; } A possible workaround is to use enable_if: template using enable_format = typename std::enable_if::value>::type; template > auto parse_format(basic_context &ctx) { // Parse the format string. return [/* Formatting state */](basic_buffer &buf, MyClass &value) { // Format value. }; } This workaround does the job (implemented in experimental branch: https://github.com/fmtlib/fmt/tree/ext) but I am not super happy about it. Any ideas on how to improve this are appreciated. Best regards, Victor On Tue, Jun 6, 2017 at 3:12 PM Bengt Gustafsson < bengt.gustafsson@beamways.com> wrote: > I like this functionality a lot, it has been sorely lacking in C++ and is > becoming more and more a standard in many other languages. > > Some comments: > > - I would like the part before the : inside {} to allow any text. This > allows translators to understand better the meaning of the inserted value > and thus produce better translations. Not writing anything before the : > would still > be equivalent to writing the next consecutive number. I think you removed > this capability from the python implementation as C++ does not have named > arguments but it still has value in conveying information between > programmer and the person doing translation. > > - Some kind of standard interface to internationalization string > replacement could be incorporated in format(), so that we don't have to > write _() or something around the literal. > > - How to specify using . for decimal char in a country where , is standard > and vice versa. n only seems to relate to thousand separator handling, but > the usual problem is to get the right decimal character in float number > output. Many file formats (JSON for instance) require a dot even in > countries where comma is standard. This is a recurring problem as "someone > else" may set your locale on a global level. I have a similar library > where I use comma or dot (in the dot position in the format string) to > denote themselves as decimal char while semicolon denotes "the locale > decimal char". While creating your own buffer type which overrides the > locale() method is possible it is much more work than defining the decimal > char in the format string. > > - I don't particularly like the partial reuse of the C formatting > conventions with a specified order of the parts of the format string, as it > is hard to learn. Sure, it is rather easy whern you have learned printf, > but do we want future generations of programmers have to go through that > detour? Better start from scratch with something logical, where the order > of characters is not crucial. > > - It may be better to send the formatting string snippet to format_value() > as a basic_string_view rather than relying on all the function overloads to > remember to bump the ptr correctly. At least provide a method in ctx to > forward the ptr and return the basic_string_view containing the format part > in case you want to preserve the possibility to nest {} inside the > formatting string. This simplifies for the fairly large share of > format_value functions which are implemented but don't care about any > formatting details. > > - A maximum inserted length is often useful to limit the output. One case > is when formatting large doubles in the f format. This can get ridiculous > in printf. Another is potentially long file names, where you may want to > limit the string length. > > - It is hard to understand the "arg store" idea and how this goes together > with calling format_value on each parameter. It may be that the fmt::args > and basic_args are actually the same. There is also arg_store and basic_arg > and the visit() function which seem more like internal details of the > implementation. Even as an implementation it seems overly complex, and I > for one can't understand how visit can call separate user defined > format_value functions if arg_store is not templated on the argument types. > > - It would be nice if it was easy to create a formatting object from a > format specification string. This object should have methods to format the > standard types that fomat() works for "out of the box". In this way you can > easily override format_value for instance for std::vector, passing each > element to a formatting object you have created. Of course you can also > call format_value() for each T provided it exists, but this incurs quite an > overhead as the same format specification string is parsed over and over > again for each array element. Taking this thought to the logical conclusion > means that the customization point for a user defined type should be a > function create_formatter(string_view format_specification_string) > rather than format_value. The formatter returned from create_formatter then > has a method format(const T& value) which does the formatting job. This > allows the vector optimization to be taken to vectors of vectors etc. > Continuing on this tangent I think it may make sense to allow pre-creating > a formatting object for an entire format string, so that the parsing of > that string occurs only once. Lets call this class formatter. > Example: > > template class formatter { > public: > formatter(string_view format_string); // This parses the > format_string and stores the objects returned from create_formatter for > each of the Ts. > > void run(buffer& buf, const Ts&.. args); // Perform the formatting > to a buffer > string run(buffer& buf, const Ts&... args); // Perform the formatting > and return a string > }; > > // The format function is then defined as: > template string format(string_view format_string, const > Ts& values) > { > formatter fmt(format_string); > return fmt.run(values...); > } > // A good compiler hopefully generates the same code as in the current > implementation. > // A loop for printing many lines would be more effective if written: > > formatter fmt("#{IX}: {NAME}, {PRICE:.2"); // > Preparse format > for (item : inventory) > cout << fmt.run(item.ix, item.name, item.price); > > > > > > > > > > Den tisdag 6 juni 2017 kl. 16:04:37 UTC+2 skrev Nicol Bolas: >> >> On Tuesday, June 6, 2017 at 9:41:26 AM UTC-4, Victor Zverovich wrote: >>> >>> I'm working on a proposal for a new formatting functionality for the C++ >>> standard library based on the fmt library (https://github.com/fmtlib/fmt >>> ). >>> >>> The first draft of the proposal is available at >>> http://fmtlib.net/Text%20Formatting.html and I would appreciate any >>> comments. >>> >>> - Victor >>> >> >> I'm concerned about this: >> >> The formatting library uses a null-terminated string view >>> basic_cstring_view instead of basic_string_view. This results in >>> somewhat smaller and faster code because the string size, which is not >>> used, doesn't have to be computed and passed. Also having a termination >>> character makes parsing easier. >>> >> >> This really hurts users of `basic_string_view`, since their views are >> *not* NUL-terminated. Such users don't necessarily have to calculate the >> string size either; the `sv` user-defined literal will generate the size >> based on the input literal. >> >> Your insistence on `basic_cstring_view` only aids scenarios where the >> user has an unsized, NUL-terminated string. So they would have to not be >> using `basic_string` or similar types (which are sized). >> > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4777755b-5984-4ef3-8fc5-a3e17aa94469%40isocpp.org > > . > -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANawtxZQEpgN7Uf_1%2BdCLDAtFT0DHKwfeAZjOwe8Y1jUdRKR2Q%40mail.gmail.com. --94eb2c1959fe5106260552b939b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0It would be nice if it was easy to create a formatting object from a for= mat specification string.

I think this is a great idea and I finally = got a chance to experiment with it.=C2=A0

The main drawback of = having a separate formatting object is that it makes writing a formatter fo= r a user-defined type more complicated, because you need to define 3 things= : a formatter class, a parsing function and a formatting function.=C2=A0In the current proposal everything = is combined in format_value which, on one hand, leads to less boilerplate b= ut, on the other hand, is more restrictive.

template <>
class forma= tter<MyClass> {
=C2=A0public= :
=C2=A0 explicit formatter(contex= t &ctx) {
=C2=A0 =C2=A0 // Par= se the format string.
=C2=A0 }

=C2=A0 void format(buff= er &buf, MyClass &value) {
=C2=A0 =C2=A0=C2=A0= // Format value.
=C2= =A0 }

=C2=A0private:
= =C2=A0 // Formatting state.
};

One way to reduce boilerplate is by returning the formatter object= as a lambda from the parsing function, e.g.

auto parse_format<MyClass>(context &ctx= ) {
=C2=A0 // Parse the format str= ing.
=C2=A0 return [/* Formatting = state */](buffer &buf, MyClass &value) {
=C2=A0 =C2=A0 // Format value.
=C2=A0 };
}

Unfortunately this doesn'= ;t work if=C2=A0parse_format has= to take additional template arguments such as a char type:

// Doesn't compile
template <typename Char>
= auto parse_format<MyClass>(basic_context<C= har> &ctx) {
=C2=A0 // Pars= e the format string.
=C2=A0 return= [/*=C2=A0Formatting state=C2=A0*/](basic_buffer<Char> &buf, MyCla= ss &value) {
=C2=A0 =C2=A0 // = Format value.
=C2=A0 };
}

A possible workaround is= to use enable_if:

template <typename T, typename U>=
using enable_format =3D typename std::enable_if<std::is_same&= lt;T, U>::value>::type;

template <typename T, ty= pename Char, typename =3D enable_format<T, MyClass>>
<= div style=3D"color:rgb(0,0,0)">
auto parse_form= at(basic_context<Char> &ctx) {
=C2=A0 // Parse the format string.
=C2=A0 return [/*=C2=A0F= ormatting state=C2=A0*/](basic_buffer<Cha= r> &buf, MyClass &value) {
=C2=A0 =C2=A0 // Format value.
=C2=A0 };
}

This work= around does the job (implemented in experimental branch:=C2=A0https://github.com/fmtlib/fmt/= tree/ext)=C2=A0but I am not super happy about it. Any ideas on how = to improve this are appreciated.

Best r= egards,
Victor<= /div>

On Tue, Jun 6, 2017 at 3:12 PM Bengt Gustafsson <bengt.gustafsson@beamways.com> wr= ote:
I like t= his functionality a lot, it has been sorely lacking in C++ and is becoming = more and more a standard in many other languages.

= Some comments:

- I would like the part before = the : inside {} to allow any text. This allows translators to understand be= tter the meaning of the inserted value and thus produce better translations= .. Not writing anything before the : would still
be equivalent to = writing the next consecutive number. I think you removed this capability fr= om the python implementation as C++ does not have named arguments but it st= ill has value in conveying information between programmer and the person do= ing translation.

- Some kind of standard interface= to internationalization string replacement could be incorporated in format= (), so that we don't have to write _() or something around the literal.=

- How to specify using . for decimal char in a co= untry where , is standard and vice versa. n only seems to relate to thousan= d separator handling, but the usual problem is to get the right decimal cha= racter in float number output. Many file formats (JSON for instance) requir= e a dot even in countries where comma is standard. This is a recurring prob= lem as "someone else" may set your locale on a =C2=A0global level= .. I have a similar library where I use comma or dot (in the dot position in= the format string) to denote themselves as decimal char while semicolon de= notes "the locale decimal char". While creating your own buffer t= ype which overrides the locale() method is possible it is much more work th= an defining the decimal char in the format string.

- I don't particularly like the partial reuse of the C formatting conv= entions with a specified order of the parts of the format string, as it is = hard to learn. Sure, it is rather easy whern you have learned printf, but d= o we want future generations of programmers have to go through that detour?= Better start from scratch with something logical, where the order of chara= cters is not crucial.

- It may be better to send t= he formatting string snippet to format_value() as a basic_string_view rathe= r than relying on all the function overloads to remember to bump the ptr co= rrectly. At least provide a method in ctx to forward the ptr and return the= basic_string_view containing the format part in case you want to preserve = the possibility to nest {} inside the formatting string. This simplifies fo= r the fairly large share of format_value functions which are implemented bu= t don't care about any formatting details.

- A= maximum inserted length is often useful to limit the output. One case is w= hen formatting large doubles in the f format. This can get ridiculous in pr= intf. Another is potentially long file names, where you may want to limit t= he string length.

- It is hard to understand the &= quot;arg store" idea and how this goes together with calling format_va= lue on each parameter. It may be that the fmt::args and basic_args are actu= ally the same. There is also arg_store and basic_arg and the visit() functi= on which seem more like internal details of the implementation. Even as an = implementation it seems overly complex, and I for one can't understand = how visit can call separate user defined format_value functions if arg_stor= e is not templated on the argument types.

- It wou= ld be nice if it was easy to create a formatting object from a format speci= fication string. This object should have methods to format the standard typ= es that fomat() works for "out of the box". In this way you can e= asily override format_value for instance for std::vector<T>, passing = each element to a formatting object you have created. Of course you can als= o call format_value() for each T provided it exists, but this incurs quite = an overhead as the same format specification string is parsed over and over= again for each array element. Taking this thought to the logical conclusio= n means that the customization point for a user defined type should be a fu= nction create_formatter<T>(string_view format_specification_string) r= ather than format_value. The formatter returned from create_formatter then = has a method format(const T& value) which does the formatting job. This= allows the vector optimization to be taken to vectors of vectors etc. Cont= inuing on this tangent I think it may make sense to allow pre-creating a fo= rmatting object for an entire format string, so that the parsing of that st= ring occurs only once. Lets call this class formatter<Ts...>. Example= :

template<typename... Ts> class formatter {=
public:
=C2=A0 =C2=A0 formatter(string_view format_str= ing); =C2=A0// This parses the format_string and stores the objects returne= d from create_formatter<T> for each of the Ts.

=C2=A0 =C2=A0 void run(buffer& buf, const Ts&.. args); =C2=A0 = =C2=A0// Perform the formatting to a buffer
=C2=A0 =C2=A0 string = run(buffer& buf, const Ts&... args); // Perform the formatting and = return a string
};

// The format functio= n is then defined as:
template<typename... Ts> string forma= t(string_view format_string, const Ts& values)
{
= =C2=A0 =C2=A0 =C2=A0formatter<Ts...> fmt(format_string);
= =C2=A0 =C2=A0 =C2=A0return fmt.run(values...);
}
// A g= ood compiler hopefully generates the same code as in the current implementa= tion.
// A loop for printing many lines would be more effective i= f written:

formatter<int, string, double> fm= t("#{IX}: {NAME}, {PRICE:.2"); =C2=A0 // Preparse format
for (item : inventory)
=C2=A0 =C2=A0 cout << fmt.run(item= ..ix, item.name, item.pri= ce);








Den tisdag 6 juni 2017 kl. 16:04:37 UTC+2 skrev Nicol Bolas:
On Tuesday, June 6, 2017 at 9:41= :26 AM UTC-4, Victor Zverovich wrote:
= I'm working on a proposal for a new formatting functionality for the C+= + standard library based o= n the fmt library (https://github.c= om/fmtlib/fmt).

The first draft of the proposal is availa= ble at=C2=A0http://fmtl= ib.net/Text%20Formatting.html=C2=A0and I would = appreciate any comments.

- Victor

I'm concerned about this:

The formatting library uses a null-terminated string= view basic_cstring_view instead of basic_string_view. This results in somewhat smaller and faster code because the string size, which is not used, doesn't have to be computed and passed. Also having a termination character makes parsing easier.

Thi= s really hurts users of `basic_string_view`, since their views are not NUL-terminated. Such users don't necessarily have to calculate the s= tring size either; the `sv` user-defined literal will generate the size bas= ed on the input literal.

Your insistence on `basic_cstring_view` onl= y aids scenarios where the user has an unsized, NUL-terminated string. So t= hey would have to not be using `basic_string` or similar types (which are s= ized).

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit = https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4777755b-5984-= 4ef3-8fc5-a3e17aa94469%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANawtxZQEpgN7U= f_1%2BdCLDAtFT0DHKwfeAZjOwe8Y1jUdRKR2Q%40mail.gmail.com.
--94eb2c1959fe5106260552b939b5-- .